From noreply@sourceforge.net  Sun Oct  1 01:13:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Sep 2000 17:13:28 -0700
Subject: [Python-bugs-list] [Bug #115714] Module 'turtle' exports name 'Tk'...
Message-ID: <200010010013.RAA03515@delerium.i.sourceforge.net>

Bug #115714, was updated on 2000-Sep-30 06:03
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Module 'turtle' exports name 'Tk'...

Details: 
...and this produce error in the following code:

from Tkinter import *
from turtle import *

root = Tk()  # Oops! TypeError: call of non-function.
...



Follow-Ups:

Date: 2000-Sep-30 09:38
By: loewis

Comment:
A patch for that is in
http://sourceforge.net/patch/?func=detailpatch&patch_id=101724&group_id=5470
-------------------------------------------------------

Date: 2000-Sep-30 17:13
By: fdrake

Comment:
I've approved the patch that fixes this; when it gets checked in this bug should be closed.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115714&group_id=5470


From noreply@sourceforge.net  Sun Oct  1 01:15:49 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Sep 2000 17:15:49 -0700
Subject: [Python-bugs-list] [Bug #115731] Linking with old versions of readline
Message-ID: <200010010015.RAA03555@delerium.i.sourceforge.net>

Bug #115731, was updated on 2000-Sep-30 11:29
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Duplicate
Bug Group: None
Priority: 5
Summary: Linking with old versions of readline

Details: Python 2.0b2 introduced a new variable into the readline module 'library_version'. This relies on a feature not present in all versions of readline - 'rl_library_version' -  such as the one shipped with OpenBSD 2.7. The latest CVS version fails to link correctly against readlines that don't contain this variable:

[laurie /usr/local/src/Python-2.0b2]$ uname -a
OpenBSD droptop 2.7 GENERIC#25 i386
[laurie /usr/local/src/Python-2.0b2]$ make
<standard make output ... >
gcc   python.o  ../libpython2.0.a -lreadline -ltermcap  -lc_r -lutil -lm  -o python 
./posixmodule.c:2910: warning: this program uses setreuid(), which is deprecated.
./posixmodule.c:2929: warning: this program uses setregid(), which is deprecated.
./posixmodule.c:4062: warning: tempnam() possibly used unsafely; consider using mkstemp()
./posixmodule.c:4108: warning: tmpnam() possibly used unsafely; consider using mkstemp()
./readline.c:504: Undefined symbol `_rl_library_version' referenced from text segment
collect2: ld returned 1 exit status

The only obvious fix to this is to test for the presence of the variable in the configure file and have a HAS_READLINE_VERSION #define or similar which doesn't reference the readline variable, although that doesn't suggest what the library_version should be set to in its absence... None?

This is effectively a followup to bug #11487 which reported compilation problems with the aforementioned variable. It seems likely that the original bug submitter didn't get as far as linking Python due to other compilation problems so the original fix would have appeared to work.

Follow-Ups:

Date: 2000-Sep-30 17:15
By: fdrake

Comment:
This duplicates bug #115732.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115731&group_id=5470


From noreply@sourceforge.net  Sun Oct  1 03:12:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Sep 2000 19:12:04 -0700
Subject: [Python-bugs-list] [Bug #115555] Parser crashes for deeply nested list displays
Message-ID: <200010010212.TAA07346@delerium.i.sourceforge.net>

Bug #115555, was updated on 2000-Sep-28 03:42
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Parser crashes for deeply nested list displays

Details: Compiling

s=[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]

gives an error message

s_push: parser stack overflow

Python 1.5.2 then reports a MemoryError, 2.0b2 a SyntaxError.

Follow-Ups:

Date: 2000-Sep-28 12:35
By: jhylton

Comment:
What is the desired outcome here?  Python is reporting a SyntaxError; it's not crashing.  Would you like to increase the max stack size for the parser?  What should it's limit be?

The current parser stack limit allows eval("["*x+"]"*x) for values of x up to and including 35.  I'm not sure why the limit is set this low.  I bumped the value of MAXSTACK in parser.c from 500 to 5000 and it accepted the nest list expression for values of x up to 357.

-------------------------------------------------------

Date: 2000-Sep-29 09:08
By: loewis

Comment:
It was confusing that Python would produce a SyntaxError for an obviously-correct script, and that such a small limit was found in the parser.

Since the limit is not due to recursion on the C stack:  Would a patch removing this limitation be accepted (certainly not for 2.0). The two alternatives I see are to make the array completely dynamic, or to allocate a dynamic array in the stack if the static one overflows.
-------------------------------------------------------

Date: 2000-Sep-29 21:48
By: jhylton

Comment:
There is a limit that is based on the C stack, because the parser is recursive descent.  If I set the max stack size to 100000, I get a seg fault.
I'm not sure if a patch for this would be accepted post 2.0 or not; I'll talk to Guido and see what he thinks.

I think we could safely increase the static limit before 2.0, though I'm not 100% certain.  What nesting level did your application come up with?
I would guess that max stack == 10000 (700 nested lists) should be safe on all reasonable platforms and much more useful.

-------------------------------------------------------

Date: 2000-Sep-30 19:12
By: bwarsaw

Comment:
BTW, JPython gets to 133 nestings (on my RH6.1 system) before a java.lang.StackOverflow gets thrown.

Ever heard the old joke "Doctor, it hurts when I do this?" ... 
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115555&group_id=5470


From noreply@sourceforge.net  Sun Oct  1 05:18:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Sep 2000 21:18:56 -0700
Subject: [Python-bugs-list] [Bug #112265] Impossible to get Win32 default font encoding in Tk widgets
Message-ID: <200010010418.VAA11307@delerium.i.sourceforge.net>

Bug #112265, was updated on 2000-Aug-18 13:37
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: Later
Bug Group: Platform-specific
Priority: 6
Summary: Impossible to get Win32 default font encoding in Tk widgets

Details: I did not managed to obtain correct font encoding in widgets on Win32 (NT Workstation, Polish version, default encoding cp1250). All cp1250 Polish characters were displayed incorrectly. I think, all characters that do not belong to Latin-1 will be displayed incorrectly. Regarding Python1.6b1, I checked the Tcl/Tk installation (8.3.2). The pure Tcl/Tk programs DO display characters in cp1250 correctly.
As far as I know, the Tcl interpreter woks with UTF-8 encoded strings. Does Python1.6b1 really know about it?

Follow-Ups:

Date: 2000-Aug-26 08:04
By: effbot

Comment:
this is really a "how do I", rather than a bug
report ;-)

:::

In 1.6 and beyond, Python's default 8-bit
encoding is plain ASCII.  this encoding is only
used when you're using 8-bit strings in "unicode
contexts" -- for example, if you compare an
8-bit string to a unicode string, or pass it to
a subsystem designed to use unicode strings.

If you pass an 8-bit string containing
characters outside the ASCII range to a function
expecting a unicode string, the result is
undefined (it's usually results in an exception,
but some subsystems may have other ideas).

Finally, Tkinter now supports Unicode.  In fact,
it assumes that all strings passed to it are
Unicode.  When using 8-bit strings, it's only
safe to use plain ASCII.

Tkinter currently doesn't raise exceptions for
8-bit strings with non-ASCII characters, but it
probably should.  Otherwise, Tk will attempt to
parse the string as an UTF-8 string, and if that
fails, it assumes ISO-8859-1.

:::

Anyway, to write portable code using characters
outside the ASCII character set, you should use
unicode strings.

in your case, you can use:

   s = unicode("<a cp1250 string>", "cp1250")

to get the platform's default encoding, you can do:

   import locale
   language, encoding = locale.getdefaultlocale()

where encoding should be cp1250 on your box.

:::

The reason this work under Tcl/Tk is that Tcl
assumes that your source code uses the
platform's default encoding, and converts things
to Unicode (not necessarily UTF-8) for you under
the hood.  Python 2.1 will hopefully support
*explicit* source encodings, but 1.6/2.0
doesn't.

-------------------------------------------------------

Date: 2000-Sep-30 21:18
By: gvanrossum

Comment:
If it's a howto, should the bug report be closed?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112265&group_id=5470


From noreply@sourceforge.net  Sun Oct  1 05:19:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Sep 2000 21:19:44 -0700
Subject: [Python-bugs-list] [Bug #115696] sre RuntimeError when .*? matches >16K string
Message-ID: <200010010419.VAA11311@delerium.i.sourceforge.net>

Bug #115696, was updated on 2000-Sep-29 19:47
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: sre RuntimeError when .*? matches >16K string

Details: The following code (run under WinNT):

    sre.search('x.*?z', 'x%sx' % ("y" * 16037,))

raises "RuntimeError: maximum recursion limit exceeded".

sre doesn't seem to be able to do a minimal match across more than ~16K characters. I think pcre can match something like 2**32 characters, so this is an area where the sre behavior deviates radically from pcre. I have lots of code that breaks with this limit. Yikes! Can something be done?

While trying to come up with the magic number of characters that cause a minimal match to fail, I ran this interactive session 
(I'm not sure if this means anything or if it's a quirk of the interactive interpreter.)

C:\>python
Python 2.0b2 (#6, Sep 26 2000, 14:59:21) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.

>>> import sre

>>> sre.search('x.*?x', 'x%sx' % ('@'*16035,))
<SRE_Match object at 009D7FC0>

>>> sre.search('x.*?x', 'x%sx' % ('@'*16036,))
<SRE_Match object at 009D7040>

>>> sre.search('x.*?x', 'x%sx' % ('@'*16037,))      <-- first failure
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "D:\Python20\lib\sre.py", line 47, in search
    return _compile(pattern, flags).search(string)
RuntimeError: maximum recursion limit exceeded

>>> sre.search('x.*?x', 'x%sx' % ('@'*16037,))      <-- now it works (?!)
<SRE_Match object at 009D7630>

>>> sre.search('x.*?x', 'x%sx' % ('@'*16038,))
<SRE_Match object at 009D7040>

>>>

>>> sre.search('x.*?x', 'x%sx' % ('@'*16166,))
<SRE_Match object at 009D7A60>

>>> sre.search('x.*?x', 'x%sx' % ('@'*16167,))  <-- here it fails again
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "D:\Python20\lib\sre.py", line 47, in search
    return _compile(pattern, flags).search(string)
RuntimeError: maximum recursion limit exceeded

>>> sre.search('x.*?x', 'x%sx' % ('@'*16167,))  <-- continues to fail
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "D:\Python20\lib\sre.py", line 47, in search
    return _compile(pattern, flags).search(string)
RuntimeError: maximum recursion limit exceeded



Follow-Ups:

Date: 2000-Sep-30 21:19
By: gvanrossum

Comment:
Any comments, Fredrik???
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115696&group_id=5470


From noreply@sourceforge.net  Sun Oct  1 05:20:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Sep 2000 21:20:44 -0700
Subject: [Python-bugs-list] [Bug #110671] Tk-based widgets misbehave with dead keys (PR#376)
Message-ID: <200010010420.VAA11325@delerium.i.sourceforge.net>

Bug #110671, was updated on 2000-Jul-31 14:12
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Closed
Resolution: Fixed
Bug Group: 3rd Party
Priority: 5
Summary: Tk-based widgets misbehave with dead keys (PR#376)

Details: Jitterbug-Id: 376
Submitted-By: fstajano@uk.research.att.com
Date: Thu, 29 Jun 2000 12:49:44 -0400 (EDT)
Version: 1.6a2
OS: Windows 98 and 2000


This is a problem of the underlying widget set and not of Idle itself, but Idle
is where I encountered it (I normally use Emacs), and since Python 1.6 is the
unicode version I suppose it's worth looking into anyway (what good is it to
have international chars if you can't input them ;-)).

If, on Windows, you use a keyboard layout with dead keys, such as "United States
- International", then Idle does not respond properly to dead keys. In
particular, double-quote comes out as single-quote; single-quote comes out as
space; and accented characters come out as non-accented.

The lack of support for the accented chars is a minor nuisance, but the problems
with quotes are a major one -- Idle is almost unusable under these
circumstances. Not as bad as Pythonwin, though, which just crashes.

[As you will know, the US-I keyboard defines things like single-quote and
double-quote as dead keys so that one can produce accents and umlauts
respectively by following the dead key with the appropriate vowel. To produce a
double-quote on its own, you have to press double-quote followed by space.]



====================================================================
Audit trail:
Tue Jul 11 08:24:21 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-28 00:37
By: effbot

Comment:
This is supposed to be fixed in Tk 8.3 and later; from the 8.3.0 changes document:

2000-02-08 (bug fix) fixed incorrect handling of CapsLock on Win9* and the use of dead keys on international keyboards (spjuth)

(haven't verified it yet, since 1.6's Tkinter causes my Win95 box to crash, no matter what Tk version I'm using)
-------------------------------------------------------

Date: 2000-Sep-19 10:19
By: loewis

Comment:
I can confirm that the problem occurs with 1.6a2 but is fixed in 2.0b1; likely due to the more recent Tk version.
-------------------------------------------------------

Date: 2000-Sep-30 21:20
By: gvanrossum

Comment:
Closing based on Martin's comment.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110671&group_id=5470


From noreply@sourceforge.net  Sun Oct  1 05:21:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Sep 2000 21:21:35 -0700
Subject: [Python-bugs-list] [Bug #110677] PRIVATE: various minor Tkinter things (PR#388)
Message-ID: <200010010421.VAA11353@delerium.i.sourceforge.net>

Bug #110677, was updated on 2000-Jul-31 14:13
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: PRIVATE: various minor Tkinter things (PR#388)

Details: Jitterbug-Id: 388
Submitted-By: markus.oberhumer@jk.uni-linz.ac.at
Date: Wed,  5 Jul 2000 09:38:11 -0400 (EDT)
Version: python CVS
OS: all


Tkinter.Wm.wm_state() lacks a missing "newstate=None" optional parameter.

Tkinter.Text lacks some important methods: [xy]view_moveto, [xy]view_scroll

Canvas.CanvasItem & Canvas.Group:
  - bind lacks an optional "add" param
  - unbind lacks an optional "funcid" param
  - tkraise/lower should call self.canvas.tag_XXXX
  - bbox() return value is inconsistent with Canvas.bbox()



====================================================================
Audit trail:
Tue Jul 11 08:24:23 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-09 12:17
By: effbot

Comment:
the first two items are fixed.  I'll look at the Canvas.py stuff later.
-------------------------------------------------------

Date: 2000-Sep-30 21:21
By: gvanrossum

Comment:
Later being when?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110677&group_id=5470


From noreply@sourceforge.net  Sun Oct  1 05:30:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Sep 2000 21:30:45 -0700
Subject: [Python-bugs-list] [Bug #110823] Tkinter missing button state symbols (PR#132)
Message-ID: <200010010430.VAA11625@delerium.i.sourceforge.net>

Bug #110823, was updated on 2000-Aug-01 14:10
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Tkinter missing button state symbols (PR#132)

Details: Jitterbug-Id: 132
Submitted-By: aa8vb@yahoo.com
Date: Thu, 18 Nov 1999 08:16:55 -0500 (EST)
Version: 1.5.2
OS: IRIX 6.5


I have:

  picture.bind( "<ButtonPress-1>"  , click_cb )
  picture.bind( "<ButtonRelease-1>", click_cb )

In click_cb(), event.state is 0 for ButtonPress and 256 for ButtonRelease.

Where are the Tkinter constants for these?  Or how should one distinguish
between a press and release in a callback?

(I want to avoid having a separate callback for each type of event.)



====================================================================
Audit trail:
Thu Nov 18 10:42:46 1999	guido	changed notes
Thu Nov 18 10:42:46 1999	guido	moved from incoming to notabug
Thu Nov 18 14:07:59 1999	guido	changed notes
Thu Nov 18 14:07:59 1999	guido	moved from notabug to request

Follow-Ups:

Date: 2000-Aug-01 14:10
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] Tkinter missing button state symbols (PR#132)
Date: Thu, 18 Nov 1999 10:41:31 -0500

> Full_Name: Randall Hopper
> Version: 1.5.2
> OS: IRIX 6.5
> Submission from: ethyl-f.rtpfddi.epa.gov (134.67.65.11)
> 
> 
> I have:
> 
>   picture.bind( "<ButtonPress-1>"  , click_cb )
>   picture.bind( "<ButtonRelease-1>", click_cb )
> 
> In click_cb(), event.state is 0 for ButtonPress and 256 for ButtonRelease.
> 
> Where are the Tkinter constants for these?  Or how should one distinguish
> between a press and release in a callback?
> 
> (I want to avoid having a separate callback for each type of event.)

This is not a question for the bugs list.

Write to help@python.org or use the newsgroup for help.  I don't know
offhand what the answer is to your question; I suspect that the answer
is in the Tcl/Tk man page for the bind command though.

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:10
By: none

Comment:
From: Randall Hopper <Hopper.Randall@epa.gov>
Subject: Re: [Python-bugs-list] Tkinter missing button state symbols (PR#132)
Date: Thu, 18 Nov 1999 14:04:13 -0500

Guido van Rossum:
 |> Full_Name: Randall Hopper
 |> Version: 1.5.2
 |> OS: IRIX 6.5
 |> Submission from: ethyl-f.rtpfddi.epa.gov (134.67.65.11)
 |> 
 |> 
 |> I have:
 |> 
 |>   picture.bind( "<ButtonPress-1>"  , click_cb )
 |>   picture.bind( "<ButtonRelease-1>", click_cb )
 |> 
 |> In click_cb(), event.state is 0 for ButtonPress and 256 for ButtonRelease.
 |> 
 |> Where are the Tkinter constants for these?  Or how should one distinguish
 |> between a press and release in a callback?
 |> 
 |> (I want to avoid having a separate callback for each type of event.)
 |
 |This is not a question for the bugs list.
 |
 |Write to help@python.org or use the newsgroup for help.  I don't know
 |offhand what the answer is to your question; I suspect that the answer
 |is in the Tcl/Tk man page for the bind command though.

My fault.  I should have rephrased the question into a statement.  Tkinter
does not provide symbol defines for event.state values (%s keyword in Tcl).
Tcl doesn't either, but it would be useful if Tkinter did.

This is a small enhancement request rather than a hard bug, but I thought
the submission form was for probably applicable for both.

Thanks,

Randall

-------------------------------------------------------

Date: 2000-Aug-01 14:10
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] Tkinter missing button state symbols (PR#132)
Date: Thu, 18 Nov 1999 14:05:57 -0500

Yes, requests are okay.  Sorry for the confusion.

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:10
By: none

Comment:
Should add a symbol as he suggests.
-------------------------------------------------------

Date: 2000-Aug-09 02:21
By: effbot

Comment:
IIRC, these constants are platform (X library) dependent (they have to be exported from _tkinter.c, not Tkconstants.py).

I'll investigate.  Feel free to assign the bug to me if you like.

</F>
-------------------------------------------------------

Date: 2000-Aug-10 11:43
By: gvanrossum

Comment:
/F, go for it!
-------------------------------------------------------

Date: 2000-Sep-24 07:01
By: none

Comment:
LOL.I DON'T UNDERSTAND THIS SHIT BUT SOUNDS REALLY INTERESTING.WHERE CAN I LEARN HOW TO DO THIS??? SOME-ONE HELP ME!!
-------------------------------------------------------

Date: 2000-Sep-30 21:30
By: gvanrossum

Comment:
Fredrik, you promised to do this...  Do you have time?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110823&group_id=5470


From noreply@sourceforge.net  Sun Oct  1 05:31:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Sep 2000 21:31:44 -0700
Subject: [Python-bugs-list] [Bug #110866] re group self-reference weird behavior (PR#2)
Message-ID: <200010010431.VAA11634@delerium.i.sourceforge.net>

Bug #110866, was updated on 2000-Aug-01 14:41
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 5
Summary: re group self-reference weird behavior (PR#2)

Details: Jitterbug-Id: 2
Submitted-By: guido@python.org
Date: Mon, 12 Jul 1999 15:03:24 -0400 (EDT)
Version: 1.5.2
OS: Unix, Windows


Try the following:

import re
re.search("((.)\\1+)","a")

This isn't proper syntax (you shouldn't reference a group
inside itself), but it seems to hang -- in fact it takes
several minutes to execute.

Possibly it runs out of some resource on its path to infinite
recursion and then backtracks?


====================================================================
Audit trail:
Mon Jul 12 15:33:07 1999	guido	moved from incoming to open
Mon Jul 12 19:02:35 1999	guido	changed notes
Thu Jul 13 20:28:48 2000	fdrake	changed notes
Thu Jul 13 20:28:48 2000	fdrake	changed notification
Thu Jul 13 20:28:48 2000	fdrake	moved from open to 3rdpartybug

Follow-Ups:

Date: 2000-Aug-01 14:41
By: none

Comment:
AMK: pcre bug that's been fixed in more recent releases, but that's no longer
relevant with SRE in the picture.
-------------------------------------------------------

Date: 2000-Aug-09 02:27
By: effbot

Comment:
on the other hand, SRE says "nothing to repeat" -- which isn't really what it should do.  Looks like the width calculation messes up on GROUPREF's...

I've reassigned it to myself!
-------------------------------------------------------

Date: 2000-Sep-30 21:31
By: gvanrossum

Comment:
Fredrik, this is almost 2 months old now. Did you ever fix this?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110866&group_id=5470


From noreply@sourceforge.net  Sun Oct  1 05:32:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Sep 2000 21:32:37 -0700
Subject: [Python-bugs-list] [Bug #113803] [2.0b1 NT4.0] printing non asci char causes idle to abort
Message-ID: <200010010432.VAA11734@delerium.i.sourceforge.net>

Bug #113803, was updated on 2000-Sep-07 08:33
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: [2.0b1 NT4.0] printing non asci char causes idle to abort

Details: try:

alef = u'\u05d0'
print alef.encode('utf-8')

any enter after the last statement will cause idle to abort

on 'bare' python this does not cause any problem.

[tebeka@lycosmail.com]

Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-12 15:13
By: gvanrossum

Comment:
Crash confirmed in IDLE on Win98SE.
Prints (expected) garbage and doesn't crash in command line on Win98SE.
No crash in IDLE or command line on Linux.

Tim, can you take a look with the VC debugger?

-------------------------------------------------------

Date: 2000-Sep-12 19:45
By: tim_one

Comment:
Changed group to platform-specific.

Note that this is a simpler test case w/ the same symptom:

print "\327\220"

Don't know why, do know that _tkinter.pyd and tk83.dll crap out w/ page faults at the end, assigned to Fredrik on the chance he's bumped into this before.  /F, bounce it back at me if it's unclear to you.
-------------------------------------------------------

Date: 2000-Sep-12 23:38
By: tim_one

Comment:
Bad news:  this doesn't always fail in the debugger (sometimes it just prints an alef glyph and nothing odd happens at all).

Better news:  it usually fails, and when it does it dies here (_tkinter.c):

static char *
AsString(PyObject *value, PyObject *tmp)
{
	if (PyString_Check(value))
		return PyString_AsString(value);
	else {
		PyObject *v = PyObject_Str(value);
		PyList_Append(tmp, v);
		Py_DECREF(v);
		return PyString_AsString(v);
	}
}

It's in the "else" branch, v is NULL, and the Py_DECREF expansion blows up with an access violation.  Py_ObjectStr certainly *can* return NULL, and I don't understand the intent of this code well enough to know why it believes that needn't be guarded against.

"value" at this point has type PyUnicode_Type.  For whatever reason, the debugger won't let me cast it to a PyUnicodeObject*.
-------------------------------------------------------

Date: 2000-Sep-20 00:30
By: micpro

Comment:
Crash confirmed for python 2.0 on Linux.
Segfault in _tkinter:267 when called from _tkinter.c:1260
Reason: string object expected, but unicode is given.
AsObj does treat this correctly, so this gets better after
changing line 1260
   Tcl_SetResult(Tkapp_Interp(self), AsString(res, tmp),
                 TCL_VOLATILE);

to
   Tcl_SetObjResult(Tkapp_Interp(self), AsObj(res));

After this change, idle does not segfault anymore and prints
alef correctly, but it still behaves strange after printing. it.
-------------------------------------------------------

Date: 2000-Sep-30 21:32
By: gvanrossum

Comment:
This looks kinda important, so I've raised the priority.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113803&group_id=5470


From noreply@sourceforge.net  Sun Oct  1 05:33:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Sep 2000 21:33:39 -0700
Subject: [Python-bugs-list] [Bug #114033] re incompatibility in sre
Message-ID: <200010010433.VAA11750@delerium.i.sourceforge.net>

Bug #114033, was updated on 2000-Sep-11 01:24
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: re incompatibility in sre

Details: [submitted by Adam Sampson]

Under Python 1.5.2, I had a script containing the following line:

m = re.match(r"[a-z0-9]*://[^/]+/.*\.([^.#\?/]*)([#\?]?.*)?", url)

Under 1.6, this fails with:

[...]
  File "/usr/local/lib/python1.6/sre.py", line 44, in match                                              
    return _compile(pattern, flags).match(string)                                                        
  File "/usr/local/lib/python1.6/sre.py", line 102, in _compile                                          
    raise error, v # invalid expression                                                                  
sre_constants.error: nothing to repeat

I can narrow it down to:

>>> m = re.match(r"(x?)?", url)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python1.6/sre.py", line 44, in match
    return _compile(pattern, flags).match(string)
  File "/usr/local/lib/python1.6/sre.py", line 102, in _compile
    raise error, v # invalid expression
sre_constants.error: nothing to repeat

whereas:

>>> m = re.match(r"(x?.)?", url)

works fine. Is this correct behaviour for SRE, or am I just being stupid?
"(x?)?" looks like a perfectly reasonable Perl-style regexp to me (and Perl
too)...


Follow-Ups:

Date: 2000-Sep-30 21:33
By: gvanrossum

Comment:
Martin, is this still broken in 2.0? Fredrik, any idea?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114033&group_id=5470


From noreply@sourceforge.net  Sun Oct  1 05:35:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Sep 2000 21:35:31 -0700
Subject: [Python-bugs-list] [Bug #114256] Python 2.0b1, Win2K - urllib failure
Message-ID: <200010010435.VAA11790@delerium.i.sourceforge.net>

Bug #114256, was updated on 2000-Sep-12 09:16
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Summary: Python 2.0b1, Win2K - urllib failure

Details: This might be related to bug #110692, since it seems to be related to proxies.

A program I have that works under older versions of Python now fails with this traceback:


Traceback (most recent call last):
  File "IGNRatings.py", line 289, in ?
    main(sys.argv[1:])
  File "IGNRatings.py", line 133, in main
    inStream = urllib.urlopen(url)
  File "E:\Python20\lib\urllib.py", line 61, in urlopen
    return _urlopener.open(url)
  File "E:\Python20\lib\urllib.py", line 163, in open
    return getattr(self, name)(url)
  File "E:\Python20\lib\urllib.py", line 259, in open_http
    h = httplib.HTTP(host)
  File "E:\Python20\lib\httplib.py", line 624, in __init__
    self._conn = self._connection_class(host, port)
  File "E:\Python20\lib\httplib.py", line 324, in __init__
    self._set_hostport(host, port)
  File "E:\Python20\lib\httplib.py", line 330, in _set_hostport
    port = int(host[i+1:])
ValueError: invalid literal for int():


My URL is nothing special:

    'http://dreamcast.ign.com/review_lists/a.html'


I have tracked the problem down a bit:

In urllib.py, line 147, the statement

    proxy = self.proxies[type]

assigns the string

    'http://http://proxy:8080'

to "proxy". My guess is that's not right. Anyway, the following line assigns

    type = 'http'
    proxy = '//http://proxy:8080'

and the next line assigns

    host = 'http:'
    selector = '//proxy:8080'

'http:' as a host name then goes on to cause trouble when an HTTPConnection is constructed.

Hope this info helps you track it down.

Bob Alexander
bobalex@home.com

Follow-Ups:

Date: 2000-Sep-24 11:51
By: effbot

Comment:
Fixed in 2.0b2.

The earlier code assumed "protocol=host;protocol=host;..." or "host", but Windows may also use "protocol=host" (just one entry), as well as "protocol://host".  This code needs some more work, so I'll leave the bug open for now.
-------------------------------------------------------

Date: 2000-Sep-30 21:35
By: gvanrossum

Comment:
Fredrik, can you fix the code right or assign it to someone else who can? Or decide to close the bug report after all.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114256&group_id=5470


From noreply@sourceforge.net  Sun Oct  1 05:38:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Sep 2000 21:38:03 -0700
Subject: [Python-bugs-list] [Bug #115040] sre behavior differes from pre
Message-ID: <200010010438.VAA11903@delerium.i.sourceforge.net>

Bug #115040, was updated on 2000-Sep-21 19:53
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: sre behavior differes from pre

Details: This may not be a bug, but it caused some regexes of mine that match under pre to fail under sre.

With pre, an embeded flag like "(?x)" can appear anywhere within a regex and it affects the entire regex. In sre, the position of "(?x)" is important; only after it appears does VERBOSE mode seem to be in effect and whitespace is ignored. If people haven't been careful to place the "(?x)" at the very beginning of the regex, VERBOSE regexes with this defect in existing code may fail to match when sre is used as a drop-in replacement for pre.

Also, and in contrast, "(?s)" doen't seem sensitive to position under sre; wherever it appears in the regex, DOTALL seems to affect the entire regex.


Follow-Ups:

Date: 2000-Sep-21 20:15
By: tim_one

Comment:
Assigned to Fredrik.  FWIW, years ago I never did figure out Perl did in all cases simply by trying stuff; e.g., it's easy to construct cases where whether (?x) is recognized as such depends on whether you're assuming verbose mode or not while you're parsing!
-------------------------------------------------------

Date: 2000-Sep-30 21:38
By: gvanrossum

Comment:
Fredrik, any chance of fixing this?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115040&group_id=5470


From noreply@sourceforge.net  Sun Oct  1 05:40:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Sep 2000 21:40:46 -0700
Subject: [Python-bugs-list] [Bug #115618] SRE lookbehind raises a RuntimeError
Message-ID: <200010010440.VAA11965@delerium.i.sourceforge.net>

Bug #115618, was updated on 2000-Sep-28 14:47
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: SRE lookbehind raises a RuntimeError

Details: Test program:

import re
p=re.compile('(?<!abc)(def)')
p.search('abcddef')    

This raises an exception in the search():
RuntimeError: internal error in regular expression engine                       


Follow-Ups:

Date: 2000-Sep-30 21:40
By: gvanrossum

Comment:
Confirmed in 2.0b2 on Linux (Red Hat 6.2).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115618&group_id=5470


From noreply@sourceforge.net  Sun Oct  1 17:34:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 1 Oct 2000 09:34:03 -0700
Subject: [Python-bugs-list] [Bug #113797] Build problems on Reliant Unix
Message-ID: <200010011634.JAA14181@bush.i.sourceforge.net>

Bug #113797, was updated on 2000-Sep-07 07:33
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: Build problems on Reliant Unix

Details: - the linker requires the options '-W1 -Blargedynsym', otherwise, Python's global functions and variables are not visible to external modules

- when building --with-threads, the linker requires the option -Kpthread

- mmapmodule.o requires a special library

Python version: 2.0b1

compiler version:CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000
CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000


Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 13:45
By: fdrake

Comment:
We need to know the output of "uname -s" and "uname -r" for this system.  (If "uname -r" reports an error, please try "uname -v".)

Are you willing to test a modified configure script on this platform?

What additional library is required for the mmap module?
-------------------------------------------------------

Date: 2000-Sep-12 21:59
By: fdrake

Comment:
Received the following response from Daniel Dittmar <ddittmar@users.sourceforge.net>:

> We need to know the output of "uname -s" and "uname -r" 
> for this system.  (If "uname -r" reports an error, please 
> try "uname -v".)

uname -s
ReliantUNIX-N

uname -r
5.45


> Are you willing to test a modified configure script on
> this platform?

sure.

> What additional library is required for the mmap module?

The man page states -lucb. This didn't work on my machine 
as the BSD compatibility layer is not active. I tell you 
more as soon as I know how to activate it.

***********

Another problem: to detect pthreads, the compiler must be 
called with -Kpthread. Otherwise, pthread.h goes into a 
branch where it tries to include a non existent header, 
fails, and configure reports 'no pthreads'.

Daniel

-------------------------------------------------------

Date: 2000-Sep-15 11:57
By: fdrake

Comment:
For the mmap issue, I've added a comment to Modules/Setup.in to let installers know that -lucb may be needed.  In revision 1.110.
-------------------------------------------------------

Date: 2000-Sep-15 13:37
By: fdrake

Comment:
I'm sending a modified version of  the configure script to Daniel Dittmar to test for the first two points in this bug report.
-------------------------------------------------------

Date: 2000-Sep-21 08:17
By: fdrake

Comment:
Sent query to Daniel Dittmar asking if he's had a chance to test the revised configure script I sent.
-------------------------------------------------------

Date: 2000-Sep-21 08:46
By: fdrake

Comment:
Received message from Daniel indicating he should get a chace to test the changes this weekend, so it should be available for 2.0b2.
-------------------------------------------------------

Date: 2000-Sep-24 05:46
By: ddittmar

Comment:
- configure --without-threads works with the configure patch Revision 1.158

- mmapmodule would work if it includes the lines

#include <unistd.h>

static int
getpagesize (void)
{
    return sysconf (_SC_PAGESIZE);
}

This would be the preferred way as using the BSD compatibility with -lucb is discouraged.

It requires chages to configure (has_pagesize, has_sysconf_sc_pagesize)

- configure --with-threads doesn't build yet, keeping contact with fdrake
-------------------------------------------------------

Date: 2000-Sep-25 08:10
By: fdrake

Comment:
Fix to make sure the public API properly exposed to extensions checked in as configure.in revision 1.155.  The rest of these issues can be dealt with in 2.0 final.
-------------------------------------------------------

Date: 2000-Sep-28 10:36
By: fdrake

Comment:
I've sent a patch for the mmap module to Daniel to test on Reliant UNIX; the patch should remove the need to link to libucb on that platform (the only platform that needed that as far as we know).
-------------------------------------------------------

Date: 2000-Oct-01 09:34
By: ddittmar

Comment:
The patch for the mmap module works on 2.0b2
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113797&group_id=5470


From noreply@sourceforge.net  Sun Oct  1 18:51:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 1 Oct 2000 10:51:32 -0700
Subject: [Python-bugs-list] [Bug #113797] Build problems on Reliant Unix
Message-ID: <200010011751.KAA07135@delerium.i.sourceforge.net>

Bug #113797, was updated on 2000-Sep-07 07:33
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: Build problems on Reliant Unix

Details: - the linker requires the options '-W1 -Blargedynsym', otherwise, Python's global functions and variables are not visible to external modules

- when building --with-threads, the linker requires the option -Kpthread

- mmapmodule.o requires a special library

Python version: 2.0b1

compiler version:CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000
CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000


Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 13:45
By: fdrake

Comment:
We need to know the output of "uname -s" and "uname -r" for this system.  (If "uname -r" reports an error, please try "uname -v".)

Are you willing to test a modified configure script on this platform?

What additional library is required for the mmap module?
-------------------------------------------------------

Date: 2000-Sep-12 21:59
By: fdrake

Comment:
Received the following response from Daniel Dittmar <ddittmar@users.sourceforge.net>:

> We need to know the output of "uname -s" and "uname -r" 
> for this system.  (If "uname -r" reports an error, please 
> try "uname -v".)

uname -s
ReliantUNIX-N

uname -r
5.45


> Are you willing to test a modified configure script on
> this platform?

sure.

> What additional library is required for the mmap module?

The man page states -lucb. This didn't work on my machine 
as the BSD compatibility layer is not active. I tell you 
more as soon as I know how to activate it.

***********

Another problem: to detect pthreads, the compiler must be 
called with -Kpthread. Otherwise, pthread.h goes into a 
branch where it tries to include a non existent header, 
fails, and configure reports 'no pthreads'.

Daniel

-------------------------------------------------------

Date: 2000-Sep-15 11:57
By: fdrake

Comment:
For the mmap issue, I've added a comment to Modules/Setup.in to let installers know that -lucb may be needed.  In revision 1.110.
-------------------------------------------------------

Date: 2000-Sep-15 13:37
By: fdrake

Comment:
I'm sending a modified version of  the configure script to Daniel Dittmar to test for the first two points in this bug report.
-------------------------------------------------------

Date: 2000-Sep-21 08:17
By: fdrake

Comment:
Sent query to Daniel Dittmar asking if he's had a chance to test the revised configure script I sent.
-------------------------------------------------------

Date: 2000-Sep-21 08:46
By: fdrake

Comment:
Received message from Daniel indicating he should get a chace to test the changes this weekend, so it should be available for 2.0b2.
-------------------------------------------------------

Date: 2000-Sep-24 05:46
By: ddittmar

Comment:
- configure --without-threads works with the configure patch Revision 1.158

- mmapmodule would work if it includes the lines

#include <unistd.h>

static int
getpagesize (void)
{
    return sysconf (_SC_PAGESIZE);
}

This would be the preferred way as using the BSD compatibility with -lucb is discouraged.

It requires chages to configure (has_pagesize, has_sysconf_sc_pagesize)

- configure --with-threads doesn't build yet, keeping contact with fdrake
-------------------------------------------------------

Date: 2000-Sep-25 08:10
By: fdrake

Comment:
Fix to make sure the public API properly exposed to extensions checked in as configure.in revision 1.155.  The rest of these issues can be dealt with in 2.0 final.
-------------------------------------------------------

Date: 2000-Sep-28 10:36
By: fdrake

Comment:
I've sent a patch for the mmap module to Daniel to test on Reliant UNIX; the patch should remove the need to link to libucb on that platform (the only platform that needed that as far as we know).
-------------------------------------------------------

Date: 2000-Oct-01 09:34
By: ddittmar

Comment:
The patch for the mmap module works on 2.0b2
-------------------------------------------------------

Date: 2000-Oct-01 10:51
By: fdrake

Comment:
mmap patch checked in as Modules/mmapmodule.c revision 2.24.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113797&group_id=5470


From noreply@sourceforge.net  Sun Oct  1 18:52:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 1 Oct 2000 10:52:51 -0700
Subject: [Python-bugs-list] [Bug #115714] Module 'turtle' exports name 'Tk'...
Message-ID: <200010011752.KAA07158@delerium.i.sourceforge.net>

Bug #115714, was updated on 2000-Sep-30 06:03
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: Module 'turtle' exports name 'Tk'...

Details: 
...and this produce error in the following code:

from Tkinter import *
from turtle import *

root = Tk()  # Oops! TypeError: call of non-function.
...



Follow-Ups:

Date: 2000-Sep-30 09:38
By: loewis

Comment:
A patch for that is in
http://sourceforge.net/patch/?func=detailpatch&patch_id=101724&group_id=5470
-------------------------------------------------------

Date: 2000-Sep-30 17:13
By: fdrake

Comment:
I've approved the patch that fixes this; when it gets checked in this bug should be closed.
-------------------------------------------------------

Date: 2000-Oct-01 10:52
By: loewis

Comment:
Fixed with version 1.2 of turtle.py
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115714&group_id=5470


From noreply@sourceforge.net  Sun Oct  1 19:13:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 1 Oct 2000 11:13:27 -0700
Subject: [Python-bugs-list] [Bug #114033] re incompatibility in sre
Message-ID: <200010011813.LAA08029@delerium.i.sourceforge.net>

Bug #114033, was updated on 2000-Sep-11 01:24
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: re incompatibility in sre

Details: [submitted by Adam Sampson]

Under Python 1.5.2, I had a script containing the following line:

m = re.match(r"[a-z0-9]*://[^/]+/.*\.([^.#\?/]*)([#\?]?.*)?", url)

Under 1.6, this fails with:

[...]
  File "/usr/local/lib/python1.6/sre.py", line 44, in match                                              
    return _compile(pattern, flags).match(string)                                                        
  File "/usr/local/lib/python1.6/sre.py", line 102, in _compile                                          
    raise error, v # invalid expression                                                                  
sre_constants.error: nothing to repeat

I can narrow it down to:

>>> m = re.match(r"(x?)?", url)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python1.6/sre.py", line 44, in match
    return _compile(pattern, flags).match(string)
  File "/usr/local/lib/python1.6/sre.py", line 102, in _compile
    raise error, v # invalid expression
sre_constants.error: nothing to repeat

whereas:

>>> m = re.match(r"(x?.)?", url)

works fine. Is this correct behaviour for SRE, or am I just being stupid?
"(x?)?" looks like a perfectly reasonable Perl-style regexp to me (and Perl
too)...


Follow-Ups:

Date: 2000-Sep-30 21:33
By: gvanrossum

Comment:
Martin, is this still broken in 2.0? Fredrik, any idea?
-------------------------------------------------------

Date: 2000-Oct-01 11:13
By: loewis

Comment:
Yes, it is still broken in 2.0b2.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114033&group_id=5470


From noreply@sourceforge.net  Sun Oct  1 20:15:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 1 Oct 2000 12:15:52 -0700
Subject: [Python-bugs-list] [Bug #115789] operator module missing documentation
Message-ID: <200010011915.MAA20060@bush.i.sourceforge.net>

Bug #115789, was updated on 2000-Oct-01 12:15
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: operator module missing documentation

Details: The operator module documentation is missing descriptions for isCallable(), isNumberType(), isSequenceType(), isMappingType().

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115789&group_id=5470


From noreply@sourceforge.net  Mon Oct  2 04:36:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 1 Oct 2000 20:36:32 -0700
Subject: [Python-bugs-list] [Bug #115789] operator module missing documentation
Message-ID: <200010020336.UAA05285@bush.i.sourceforge.net>

Bug #115789, was updated on 2000-Oct-01 12:15
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 3
Summary: operator module missing documentation

Details: The operator module documentation is missing descriptions for isCallable(), isNumberType(), isSequenceType(), isMappingType().

Follow-Ups:

Date: 2000-Oct-01 20:36
By: fdrake

Comment:
It's not clear that these should be documented except to warn people maintaining existing code that these aren't as useful as they sound.  Note that isMappingType(), isNumberType(), and isSequenceType() all return true for all instance objects; this is seriously misleading.

I've checked in documentation with prominent warnings as Doc/lib/liboperator.tex revision .
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115789&group_id=5470


From noreply@sourceforge.net  Mon Oct  2 10:23:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 2 Oct 2000 02:23:06 -0700
Subject: [Python-bugs-list] [Bug #115555] Parser crashes for deeply nested list displays
Message-ID: <200010020923.CAA07609@delerium.i.sourceforge.net>

Bug #115555, was updated on 2000-Sep-28 03:42
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Parser crashes for deeply nested list displays

Details: Compiling

s=[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]

gives an error message

s_push: parser stack overflow

Python 1.5.2 then reports a MemoryError, 2.0b2 a SyntaxError.

Follow-Ups:

Date: 2000-Sep-28 12:35
By: jhylton

Comment:
What is the desired outcome here?  Python is reporting a SyntaxError; it's not crashing.  Would you like to increase the max stack size for the parser?  What should it's limit be?

The current parser stack limit allows eval("["*x+"]"*x) for values of x up to and including 35.  I'm not sure why the limit is set this low.  I bumped the value of MAXSTACK in parser.c from 500 to 5000 and it accepted the nest list expression for values of x up to 357.

-------------------------------------------------------

Date: 2000-Sep-29 09:08
By: loewis

Comment:
It was confusing that Python would produce a SyntaxError for an obviously-correct script, and that such a small limit was found in the parser.

Since the limit is not due to recursion on the C stack:  Would a patch removing this limitation be accepted (certainly not for 2.0). The two alternatives I see are to make the array completely dynamic, or to allocate a dynamic array in the stack if the static one overflows.
-------------------------------------------------------

Date: 2000-Sep-29 21:48
By: jhylton

Comment:
There is a limit that is based on the C stack, because the parser is recursive descent.  If I set the max stack size to 100000, I get a seg fault.
I'm not sure if a patch for this would be accepted post 2.0 or not; I'll talk to Guido and see what he thinks.

I think we could safely increase the static limit before 2.0, though I'm not 100% certain.  What nesting level did your application come up with?
I would guess that max stack == 10000 (700 nested lists) should be safe on all reasonable platforms and much more useful.

-------------------------------------------------------

Date: 2000-Sep-30 19:12
By: bwarsaw

Comment:
BTW, JPython gets to 133 nestings (on my RH6.1 system) before a java.lang.StackOverflow gets thrown.

Ever heard the old joke "Doctor, it hurts when I do this?" ... 
-------------------------------------------------------

Date: 2000-Oct-02 02:23
By: loewis

Comment:
The problem was found when printing an expression like parser.suite("3*4").tolist(),
then modifying the string, and feeding the outcome back to Python. It is not a serious problem that this works for every possible Python code - it is just confusing to get a SyntaxError when there is no syntax error in the input.

BTW, I believe the parser is *not* recursive on the C stack; I could not find any sign of recursion inside Parser/parser.c. Most likely, the crash you got when increasing the parser stack size comes from Python/compile.c; the com_* functions are recursive on the C stack. It would be possible to remove the recursion here as well (using an explicit stack that lives on the heap); that would require a larger rewrite of compile.c, though.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115555&group_id=5470


From noreply@sourceforge.net  Mon Oct  2 10:34:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 2 Oct 2000 02:34:12 -0700
Subject: [Python-bugs-list] [Bug #115595] Building extensions on windows
Message-ID: <200010020934.CAA16899@bush.i.sourceforge.net>

Bug #115595, was updated on 2000-Sep-28 10:13
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: Building extensions on windows

Details: Reported by Mike Fletcher:
Building extensions on windows(at least with MSVC) in debug mode link with the wrong python import library. This leads to crashes because the extension loads the release python dll instead of the debug dll:

Fatal Python error: PyThreadState_Get: no current thread


Follow-Ups:

Date: 2000-Sep-28 10:41
By: fdrake

Comment:
Assigned to Thomas Heller since he's the distutils-on-Windows export!
-------------------------------------------------------

Date: 2000-Sep-29 05:35
By: theller

Comment:
According to my tests, the bug seems fixed with the recent
changes I made.
I'm still leaving it open because I'm still working on the
library stuff.
-------------------------------------------------------

Date: 2000-Oct-02 02:34
By: theller

Comment:
It's fixed in distutils-1.0pre.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115595&group_id=5470


From noreply@sourceforge.net  Mon Oct  2 11:22:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 2 Oct 2000 03:22:39 -0700
Subject: [Python-bugs-list] [Bug #115555] Parser crashes for deeply nested list displays
Message-ID: <200010021022.DAA09801@delerium.i.sourceforge.net>

Bug #115555, was updated on 2000-Sep-28 03:42
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Parser crashes for deeply nested list displays

Details: Compiling

s=[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]

gives an error message

s_push: parser stack overflow

Python 1.5.2 then reports a MemoryError, 2.0b2 a SyntaxError.

Follow-Ups:

Date: 2000-Sep-28 12:35
By: jhylton

Comment:
What is the desired outcome here?  Python is reporting a SyntaxError; it's not crashing.  Would you like to increase the max stack size for the parser?  What should it's limit be?

The current parser stack limit allows eval("["*x+"]"*x) for values of x up to and including 35.  I'm not sure why the limit is set this low.  I bumped the value of MAXSTACK in parser.c from 500 to 5000 and it accepted the nest list expression for values of x up to 357.

-------------------------------------------------------

Date: 2000-Sep-29 09:08
By: loewis

Comment:
It was confusing that Python would produce a SyntaxError for an obviously-correct script, and that such a small limit was found in the parser.

Since the limit is not due to recursion on the C stack:  Would a patch removing this limitation be accepted (certainly not for 2.0). The two alternatives I see are to make the array completely dynamic, or to allocate a dynamic array in the stack if the static one overflows.
-------------------------------------------------------

Date: 2000-Sep-29 21:48
By: jhylton

Comment:
There is a limit that is based on the C stack, because the parser is recursive descent.  If I set the max stack size to 100000, I get a seg fault.
I'm not sure if a patch for this would be accepted post 2.0 or not; I'll talk to Guido and see what he thinks.

I think we could safely increase the static limit before 2.0, though I'm not 100% certain.  What nesting level did your application come up with?
I would guess that max stack == 10000 (700 nested lists) should be safe on all reasonable platforms and much more useful.

-------------------------------------------------------

Date: 2000-Sep-30 19:12
By: bwarsaw

Comment:
BTW, JPython gets to 133 nestings (on my RH6.1 system) before a java.lang.StackOverflow gets thrown.

Ever heard the old joke "Doctor, it hurts when I do this?" ... 
-------------------------------------------------------

Date: 2000-Oct-02 02:23
By: loewis

Comment:
The problem was found when printing an expression like parser.suite("3*4").tolist(),
then modifying the string, and feeding the outcome back to Python. It is not a serious problem that this works for every possible Python code - it is just confusing to get a SyntaxError when there is no syntax error in the input.

BTW, I believe the parser is *not* recursive on the C stack; I could not find any sign of recursion inside Parser/parser.c. Most likely, the crash you got when increasing the parser stack size comes from Python/compile.c; the com_* functions are recursive on the C stack. It would be possible to remove the recursion here as well (using an explicit stack that lives on the heap); that would require a larger rewrite of compile.c, though.
-------------------------------------------------------

Date: 2000-Oct-02 03:22
By: gvanrossum

Comment:
The SyntaxError is actually caused by a bug in the parser code! When s_push() reports a stack overflow it returns -1, which is passed through unchanged by push() -- but the code that calls it only checks for positive error codes! I've fixed this by returning E_NOMEM from s_push() instead.

The only downside I see of making MAXSTACK larger is that a stack of maximal size is allocated each time the parser is invoked. With MAXSTACK=500 on a 32-bit machine, that's 6K. Switch to 5000 and it's 60K. No big deal except perhaps for ports to PalmPilots and the like...

Note that with MAXSTACK=500, you can "only" have 35 nested lists.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115555&group_id=5470


From noreply@sourceforge.net  Mon Oct  2 11:43:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 2 Oct 2000 03:43:26 -0700
Subject: [Python-bugs-list] [Bug #115831] 0.0**-2.0 returns "inf" instead of raising ValueError
Message-ID: <200010021043.DAA10500@delerium.i.sourceforge.net>

Bug #115831, was updated on 2000-Oct-02 03:43
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: 0.0**-2.0 returns "inf" instead of raising ValueError

Details: 0.0**(-2.5) correctly raises "ValueError: 0.0 to a negative power", but
0.0**(-2.0) or 0.0**(-2) returns "inf", instead of raising the same exception.
Something wrong here?

0**0 (integer or float) does return 1 which is correct limiting value.

[Reported to me by William Park]

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115831&group_id=5470


From noreply@sourceforge.net  Mon Oct  2 14:27:15 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 2 Oct 2000 06:27:15 -0700
Subject: [Python-bugs-list] [Bug #115844] OverflowError: integer multiplication
Message-ID: <200010021327.GAA25928@bush.i.sourceforge.net>

Bug #115844, was updated on 2000-Oct-02 06:27
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: OverflowError: integer multiplication

Details: 
Python2.0b2 compiled from source on a full RH7.0 install:


Python 2.0b2 (#2, Sep 27 2000, 11:40:58) 
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> a = 5 * 5
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>>

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115844&group_id=5470


From noreply@sourceforge.net  Mon Oct  2 14:31:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 2 Oct 2000 06:31:10 -0700
Subject: [Python-bugs-list] [Bug #115845] sre: maxsplit as keyword argument
Message-ID: <200010021331.GAA26000@bush.i.sourceforge.net>

Bug #115845, was updated on 2000-Oct-02 06:31
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: sre: maxsplit as keyword argument

Details: Split gives TypeError when called as a method of compiled
regular expression object with maxsplit as keyword argument.
This error is only in sre, pre is OK.

Python 1.6 (#2, Sep  6 2000, 18:20:07) [C] on osf1V4
>>> import re
>>> patt = re.compile(' ')
>>> list = patt.split("a b c",50)              # OK
>>> list = re.split(' ',"a b c",maxsplit=50)   # OK     
>>> list = patt.split("a b c",maxsplit=50)     # ERROR
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: this function takes no keyword arguments

>>> import pre
>>> patt = pre.compile(' ')
>>> list = patt.split("a b c",maxsplit=50)     # OK



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115845&group_id=5470


From noreply@sourceforge.net  Mon Oct  2 14:39:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 2 Oct 2000 06:39:05 -0700
Subject: [Python-bugs-list] [Bug #115844] OverflowError: integer multiplication
Message-ID: <200010021339.GAA26371@bush.i.sourceforge.net>

Bug #115844, was updated on 2000-Oct-02 06:27
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: OverflowError: integer multiplication

Details: 
Python2.0b2 compiled from source on a full RH7.0 install:


Python 2.0b2 (#2, Sep 27 2000, 11:40:58) 
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> a = 5 * 5
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>>

Follow-Ups:

Date: 2000-Oct-02 06:39
By: gvanrossum

Comment:
Something very basic is wrong. What output does the test suite give? ("make test"). Please see the README for digging into this.

Note that you submitted your bug report anonymously. We can't help you very effectively unless we can exchange email with you!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115844&group_id=5470


From noreply@sourceforge.net  Mon Oct  2 14:41:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 2 Oct 2000 06:41:31 -0700
Subject: [Python-bugs-list] [Bug #115845] sre: maxsplit as keyword argument
Message-ID: <200010021341.GAA26413@bush.i.sourceforge.net>

Bug #115845, was updated on 2000-Oct-02 06:31
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: sre: maxsplit as keyword argument

Details: Split gives TypeError when called as a method of compiled
regular expression object with maxsplit as keyword argument.
This error is only in sre, pre is OK.

Python 1.6 (#2, Sep  6 2000, 18:20:07) [C] on osf1V4
>>> import re
>>> patt = re.compile(' ')
>>> list = patt.split("a b c",50)              # OK
>>> list = re.split(' ',"a b c",maxsplit=50)   # OK     
>>> list = patt.split("a b c",maxsplit=50)     # ERROR
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: this function takes no keyword arguments

>>> import pre
>>> patt = pre.compile(' ')
>>> list = patt.split("a b c",maxsplit=50)     # OK



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115845&group_id=5470


From noreply@sourceforge.net  Mon Oct  2 14:44:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 2 Oct 2000 06:44:44 -0700
Subject: [Python-bugs-list] [Bug #115732] Linking fails with old versions of readline
Message-ID: <200010021344.GAA17595@delerium.i.sourceforge.net>

Bug #115732, was updated on 2000-Sep-30 11:36
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: Linking fails with old versions of readline

Details: Python 2.0b2 introduced a new variable into the readline module 'library_version'. This relies on a feature not present in all versions of readline - 'rl_library_version' -  such as the one shipped with OpenBSD 2.7. The latest CVS version fails to link correctly against readlines that don't contain this variable:

[laurie /usr/local/src/Python-2.0b2]$ uname -a
OpenBSD droptop 2.7 GENERIC#25 i386
[laurie /usr/local/src/Python-2.0b2]$ make
<standard make output ... >
gcc   python.o  ../libpython2.0.a -lreadline -ltermcap  -lc_r -lutil -lm  -o python 
./readline.c:504: Undefined symbol `_rl_library_version' referenced from text segment
collect2: ld returned 1 exit status

The only obvious fix to this is to test for the presence of the variable in the configure file and have a HAS_READLINE_VERSION #define or similar which doesn't reference the readline variable, although that doesn't suggest what the library_version should be set to in its absence... None?

This is effectively a followup to bug #11487 which reported compilation problems with the aforementioned variable. It seems likely that the original bug submitter didn't get as far as linking Python due to other compilation problems so the original fix would have appeared to work.

Follow-Ups:

Date: 2000-Oct-02 06:44
By: jhylton

Comment:
It looks like we should just back out the last change to readline.c.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115732&group_id=5470


From noreply@sourceforge.net  Mon Oct  2 14:53:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 2 Oct 2000 06:53:00 -0700
Subject: [Python-bugs-list] [Bug #115844] OverflowError: integer multiplication
Message-ID: <200010021353.GAA17936@delerium.i.sourceforge.net>

Bug #115844, was updated on 2000-Oct-02 06:27
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Irreproducible
Priority: 3
Summary: OverflowError: integer multiplication

Details: 
Python2.0b2 compiled from source on a full RH7.0 install:


Python 2.0b2 (#2, Sep 27 2000, 11:40:58) 
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> a = 5 * 5
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>>

Follow-Ups:

Date: 2000-Oct-02 06:39
By: gvanrossum

Comment:
Something very basic is wrong. What output does the test suite give? ("make test"). Please see the README for digging into this.

Note that you submitted your bug report anonymously. We can't help you very effectively unless we can exchange email with you!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115844&group_id=5470


From noreply@sourceforge.net  Mon Oct  2 16:30:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 2 Oct 2000 08:30:46 -0700
Subject: [Python-bugs-list] [Bug #113797] Build problems on Reliant Unix
Message-ID: <200010021530.IAA30763@bush.i.sourceforge.net>

Bug #113797, was updated on 2000-Sep-07 07:33
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: Build problems on Reliant Unix

Details: - the linker requires the options '-W1 -Blargedynsym', otherwise, Python's global functions and variables are not visible to external modules

- when building --with-threads, the linker requires the option -Kpthread

- mmapmodule.o requires a special library

Python version: 2.0b1

compiler version:CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000
CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000


Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 13:45
By: fdrake

Comment:
We need to know the output of "uname -s" and "uname -r" for this system.  (If "uname -r" reports an error, please try "uname -v".)

Are you willing to test a modified configure script on this platform?

What additional library is required for the mmap module?
-------------------------------------------------------

Date: 2000-Sep-12 21:59
By: fdrake

Comment:
Received the following response from Daniel Dittmar <ddittmar@users.sourceforge.net>:

> We need to know the output of "uname -s" and "uname -r" 
> for this system.  (If "uname -r" reports an error, please 
> try "uname -v".)

uname -s
ReliantUNIX-N

uname -r
5.45


> Are you willing to test a modified configure script on
> this platform?

sure.

> What additional library is required for the mmap module?

The man page states -lucb. This didn't work on my machine 
as the BSD compatibility layer is not active. I tell you 
more as soon as I know how to activate it.

***********

Another problem: to detect pthreads, the compiler must be 
called with -Kpthread. Otherwise, pthread.h goes into a 
branch where it tries to include a non existent header, 
fails, and configure reports 'no pthreads'.

Daniel

-------------------------------------------------------

Date: 2000-Sep-15 11:57
By: fdrake

Comment:
For the mmap issue, I've added a comment to Modules/Setup.in to let installers know that -lucb may be needed.  In revision 1.110.
-------------------------------------------------------

Date: 2000-Sep-15 13:37
By: fdrake

Comment:
I'm sending a modified version of  the configure script to Daniel Dittmar to test for the first two points in this bug report.
-------------------------------------------------------

Date: 2000-Sep-21 08:17
By: fdrake

Comment:
Sent query to Daniel Dittmar asking if he's had a chance to test the revised configure script I sent.
-------------------------------------------------------

Date: 2000-Sep-21 08:46
By: fdrake

Comment:
Received message from Daniel indicating he should get a chace to test the changes this weekend, so it should be available for 2.0b2.
-------------------------------------------------------

Date: 2000-Sep-24 05:46
By: ddittmar

Comment:
- configure --without-threads works with the configure patch Revision 1.158

- mmapmodule would work if it includes the lines

#include <unistd.h>

static int
getpagesize (void)
{
    return sysconf (_SC_PAGESIZE);
}

This would be the preferred way as using the BSD compatibility with -lucb is discouraged.

It requires chages to configure (has_pagesize, has_sysconf_sc_pagesize)

- configure --with-threads doesn't build yet, keeping contact with fdrake
-------------------------------------------------------

Date: 2000-Sep-25 08:10
By: fdrake

Comment:
Fix to make sure the public API properly exposed to extensions checked in as configure.in revision 1.155.  The rest of these issues can be dealt with in 2.0 final.
-------------------------------------------------------

Date: 2000-Sep-28 10:36
By: fdrake

Comment:
I've sent a patch for the mmap module to Daniel to test on Reliant UNIX; the patch should remove the need to link to libucb on that platform (the only platform that needed that as far as we know).
-------------------------------------------------------

Date: 2000-Oct-01 09:34
By: ddittmar

Comment:
The patch for the mmap module works on 2.0b2
-------------------------------------------------------

Date: 2000-Oct-01 10:51
By: fdrake

Comment:
mmap patch checked in as Modules/mmapmodule.c revision 2.24.
-------------------------------------------------------

Date: 2000-Oct-02 08:30
By: fdrake

Comment:
Sent another version of the configure script to Daniel Dittmar for testing the thread support.  I think this is the last remaining problem listed in this bug report.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113797&group_id=5470


From noreply@sourceforge.net  Mon Oct  2 21:56:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 2 Oct 2000 13:56:57 -0700
Subject: [Python-bugs-list] [Bug #115681] zipfile documentation out of sync with module
Message-ID: <200010022056.NAA11502@bush.i.sourceforge.net>

Bug #115681, was updated on 2000-Sep-29 12:46
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 6
Summary: zipfile documentation out of sync with module

Details: From: "Pete Shinners" <pete@visionart.com>
Subject: zipfile docs out of sync
Date: Fri, 29 Sep 2000 12:11:46 -0700

i've been using the zipfile module recently, and noticed
the documentation for it (both 2.0b1 & 2.0b2) are way
out of sync with the actual code in the module. specifically
the documentation for the zipfile.ZipFile objects.

for example, i cannot find the "TOC" variable.
"A read-only dictionary whose keys are the names in the
archive, and whose values are tuples as follows: "
the listdir() method is also missing?

it appears these have been changed to using
"NameToInfo" and "getinfo" for TOC, and listdir()
has changed to namelist() ??? it's hard to be sure.


Follow-Ups:

Date: 2000-Sep-29 12:48
By: fdrake

Comment:
I've sent a note to Jim Ahlstrom asking him to update the documentation or provide a list of changes that need to be made, since what we have is just TeXified from text he provided when he contributed the module.
-------------------------------------------------------

Date: 2000-Oct-02 13:56
By: fdrake

Comment:
Updated documentation partly based on new documentation from Jim Ahlstrom <jim@interet.com>.  Checked in as Doc/lib/libzipfile.tex revision 1.5.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115681&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 00:00:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 2 Oct 2000 16:00:38 -0700
Subject: [Python-bugs-list] [Bug #110849] Fwd: Debian Bug#42318: urllib.py has problems with malformed proxy env. variables (PR#59)
Message-ID: <200010022300.QAA16223@bush.i.sourceforge.net>

Bug #110849, was updated on 2000-Aug-01 14:16
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 4
Summary: Fwd: Debian Bug#42318: urllib.py has problems with malformed proxy env. variables (PR#59)

Details: Jitterbug-Id: 59
Submitted-By: flight@debian.org
Date: Fri, 20 Aug 1999 13:40:04 -0400 (EDT)
Version: 1.5.2
OS: Debian potato


Summary: Python's urllib expects a fully qualified URL in HTTP_PROXY (like
"http://proxy:8080/"). Many applications allow short forms in HTTP_PROXY
(like "proxy:8080"). If HTTP_PROXY is set to a short form, urllib.py will
fail with an uncomprehensible error message.


Long form:

Francesco Potorti` <F.Potorti@cnuce.cnr.it> says (in the Debian bug report
http://www.debian.org/Bugs/db/42/42318.html):

  "when setting a proxy variable that is not parsed by urllib, urllib does
   not print a comprehensible error message."

An example:


Short form HTTP_PROXY:

  master% HTTP_PROXY="proxy.cnr.it:8081" \
    python -c 'import urllib; print
urllib.urlretrieve("http://www.olemiss.edu/")'
  Traceback (innermost last):
    File "<string>", line 1, in ?
    File "/usr/lib/python1.5/urllib.py", line 69, in urlretrieve
      return _urlopener.retrieve(url)
    File "/usr/lib/python1.5/urllib.py", line 186, in retrieve
      fp = self.open(url)
    File "/usr/lib/python1.5/urllib.py", line 154, in open
      return self.open_unknown(fullurl)
    File "/usr/lib/python1.5/urllib.py", line 168, in open_unknown
      raise IOError, ('url error', 'unknown url type', type)
  IOError: ('url error', 'unknown url type', 'http')


Fully qualified URL in HTTP_PROXY:

  master% HTTP_PROXY="http://proxy.cnr.it:8081" \
    python -c 'import urllib; print
urllib.urlretrieve("http://www.olemiss.edu/")'
  ('/tmp/@15884.1', <mimetools.Message instance at 80adb08>)



====================================================================
Audit trail:
Mon Aug 30 12:35:03 1999	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 22:52
By: tim_one

Comment:
Assigned to Barry because I think of him as being the Potato Man.
-------------------------------------------------------

Date: 2000-Oct-02 16:00
By: jhylton

Comment:
The immediate fix for this bug report is to raise a more explanatory error message:
IOError: [Errno url error] invalid proxy for http: 'localhost:3128'

In the long term, we may want to support the requested feature.
Added to PEP 42.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110849&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 00:06:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 2 Oct 2000 16:06:40 -0700
Subject: [Python-bugs-list] [Bug #113721] urllib handles proxy badly
Message-ID: <200010022306.QAA16420@bush.i.sourceforge.net>

Bug #113721, was updated on 2000-Sep-06 09:30
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Works For Me
Bug Group: Irreproducible
Priority: 5
Summary: urllib handles proxy badly

Details: The following gives "host not found" when a proxy server is in use:

    import urllib
    w=urllib.urlopen("http://www.pythonlabs.com")

The host name is changed to "http=PROXYSERVER" and fails

This works under Python 1.5.2, but fails under Python 2.0b1

Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Oct-02 16:06
By: jhylton

Comment:
There is not enough information to go on in this bug report.  It looks like an invalid proxy specification. 

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113721&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 00:44:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 2 Oct 2000 16:44:03 -0700
Subject: [Python-bugs-list] [Bug #115528] import creates extra modules if in working directory
Message-ID: <200010022344.QAA17831@bush.i.sourceforge.net>

Bug #115528, was updated on 2000-Sep-27 20:08
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Wont Fix
Bug Group: Not a Bug
Priority: 5
Summary: import creates extra modules if in working directory

Details: Given the directory structure:

lib/
    foo/
         __init__.py
         bar.py

and PYTHONPATH includes lib

If my current working directory is lib/foo, then
>>> import bar
>>> print bar.__file__
bar.py
>>> import foo.bar
>>> print foo.bar.__file__
lib/foo/bar.py
>>> print bar == foo.bar
0

I think that any one file should produce only one module at runtime and this behavior is wrong.

The reason I am trying to count on file-module mapping is because I was to index some behavior by class, and if I can't count on classes from the same file testing identical then I'm stuck.

Follow-Ups:

Date: 2000-Sep-28 06:15
By: fdrake

Comment:
This is a result of including both lib/ and . (as '') on sys.path; the file is legitimately found for two different module imports, so it is loaded for each.  We recommend that you do not run the Python interpreter from within a package; determining this situation from the interpreter at runtime would be prohibitively expensive and slow startup.
-------------------------------------------------------

Date: 2000-Sep-28 06:18
By: lemburg

Comment:
Perhaps modules should use an absolute file name in the __file__
attribute and also be stored under this name in the module
dictionary ?!
-------------------------------------------------------

Date: 2000-Sep-28 10:05
By: fdrake

Comment:
Storing modules by filename in a dictionary isn't quite enough.  If there isn't a .pyc file, or if it's out of date, an import will use the .py file, but the next import will use the .pyc file generated from the first import.

Perhaps the directory of the script shoudn't be added to sys.path if there's an __init__.py file in that directory?  In the specific case reported here, the first import would have raised an ImportError in that case, unless there really was a different bar module elsewhere.  That seems acceptable to me, but I'm not at all sure how much legacy code would break (though I suspect very little).

This should probably be discussed on the Import-SIG; I'll send something shortly.
-------------------------------------------------------

Date: 2000-Oct-02 16:44
By: fdrake

Comment:
I've just sent a note to the Import-SIG about this:

http://www.python.org/pipermail/import-sig/2000-October/000058.html

I will mark this as a "Won't Fix", since it's not actually a bug but simply a mis-use of the interpreter.  
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115528&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 01:56:22 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 2 Oct 2000 17:56:22 -0700
Subject: [Python-bugs-list] [Bug #115732] Linking fails with old versions of readline
Message-ID: <200010030056.RAA20368@bush.i.sourceforge.net>

Bug #115732, was updated on 2000-Sep-30 11:36
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: None
Bug Group: None
Priority: 7
Summary: Linking fails with old versions of readline

Details: Python 2.0b2 introduced a new variable into the readline module 'library_version'. This relies on a feature not present in all versions of readline - 'rl_library_version' -  such as the one shipped with OpenBSD 2.7. The latest CVS version fails to link correctly against readlines that don't contain this variable:

[laurie /usr/local/src/Python-2.0b2]$ uname -a
OpenBSD droptop 2.7 GENERIC#25 i386
[laurie /usr/local/src/Python-2.0b2]$ make
<standard make output ... >
gcc   python.o  ../libpython2.0.a -lreadline -ltermcap  -lc_r -lutil -lm  -o python 
./readline.c:504: Undefined symbol `_rl_library_version' referenced from text segment
collect2: ld returned 1 exit status

The only obvious fix to this is to test for the presence of the variable in the configure file and have a HAS_READLINE_VERSION #define or similar which doesn't reference the readline variable, although that doesn't suggest what the library_version should be set to in its absence... None?

This is effectively a followup to bug #11487 which reported compilation problems with the aforementioned variable. It seems likely that the original bug submitter didn't get as far as linking Python due to other compilation problems so the original fix would have appeared to work.

Follow-Ups:

Date: 2000-Oct-02 06:44
By: jhylton

Comment:
It looks like we should just back out the last change to readline.c.

-------------------------------------------------------

Date: 2000-Oct-02 17:56
By: gvanrossum

Comment:
Closed. I took out the reference to rl_library_version. It's not worth the hassle.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115732&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 07:26:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 2 Oct 2000 23:26:16 -0700
Subject: [Python-bugs-list] [Bug #114749] HTML docs: mark off-site links
Message-ID: <200010030626.XAA23191@delerium.i.sourceforge.net>

Bug #114749, was updated on 2000-Sep-18 15:05
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: Feature Request
Priority: 4
Summary: HTML docs: mark off-site links

Details: The module index is empty.
In the library the contents is empty.

The tag <tex2html_anchor_invisible_mark> appears in lots of the .html files.

The encode() method is not documented for strings.

No docs on unicode strings in lib ref like the strings module.

Please mark links that leave the local machine. For example the link to "Python How-To Guides".


Follow-Ups:

Date: 2000-Sep-18 20:38
By: fdrake

Comment:
The "".encode() method is documented in the latest documentation package.  The Module Index and Contents pages are corrected as well.

What docs were you looking for on Unicode strings that was missing?  Please be sure to use the latest version of the documentation on www.pythonlabs.com; python.org is out of date.

I'll look into the other matters; things can clearly be improved.
-------------------------------------------------------

Date: 2000-Sep-22 10:10
By: fdrake

Comment:
The <tex2html_anchor_invisible_mark> is removed as of Doc/perl/python.perl revision 1.86.

The only remaining problem from this bug report is the marking of off-site links, so I'm classifying this as a feature request and reducing the priority a little.  I've also modified the summary to better reflect this remaining issue.
-------------------------------------------------------

Date: 2000-Sep-22 11:58
By: fdrake

Comment:
I expect I may have a small link-icon to use for this late next week (but it could take longer).
-------------------------------------------------------

Date: 2000-Oct-02 23:26
By: fdrake

Comment:
The next release will include a link-annotation icon that will be used for off-site links.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114749&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 07:51:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 2 Oct 2000 23:51:34 -0700
Subject: [Python-bugs-list] [Bug #115894] Difference between dos_8x3 and dos-8x3
Message-ID: <200010030651.XAA32594@bush.i.sourceforge.net>

Bug #115894, was updated on 2000-Oct-02 23:51
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Difference between dos_8x3 and dos-8x3

Details: While looking for another bug, I ran across the following in src/Lib/ and am wondering if it's correct as it struck me as wrong...

src/Lib/dos_8x3 
src/Lib/dos-8x3

Is there a difference between the two or is it just an artifact?

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115894&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 10:53:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 02:53:55 -0700
Subject: [Python-bugs-list] [Bug #115831] 0.0**-2.0 returns "inf" instead of raising ValueError
Message-ID: <200010030953.CAA30738@delerium.i.sourceforge.net>

Bug #115831, was updated on 2000-Oct-02 03:43
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: 0.0**-2.0 returns "inf" instead of raising ValueError

Details: 0.0**(-2.5) correctly raises "ValueError: 0.0 to a negative power", but
0.0**(-2.0) or 0.0**(-2) returns "inf", instead of raising the same exception.
Something wrong here?

0**0 (integer or float) does return 1 which is correct limiting value.

[Reported to me by William Park]

Follow-Ups:

Date: 2000-Oct-03 02:53
By: ping

Comment:
Hi.  I just submitted patch 101751 to address this.
Hope this helps.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115831&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 11:11:19 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 03:11:19 -0700
Subject: [Python-bugs-list] [Bug #115900] difference between pre and sre for buggy expressions
Message-ID: <200010031011.DAA07463@bush.i.sourceforge.net>

Bug #115900, was updated on 2000-Oct-03 03:11
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: difference between pre and sre for buggy expressions

Details: def check_pattern(pattern):
    import pre, sre

    pre_version = pre.compile(pattern)

    print pre_version.match('-1234a')
    print pre_version.match(' 1234a')

    sre_version = sre.compile(pattern)

    print sre_version.match('-1234a')
    print sre_version.match(' 1234a')

# This is a buggy re: It is trying to match a minus sign as part of a
# set of characters, but does not follow the documented rule of
# "precede it with a backslash, or place it as the first character"
# However, pre and sre behave differently, and neither behaviour is
# quite what I was expecting. Is this a hint of a bug?
check_pattern('([\s-])(\.?)'  + r'([HLEr0123456789\s-])(\.?)'*4 +r'([abcd]?)')

# Preceeding them with a backslash makes pre and sre behave identically.
check_pattern('([\s\-])(\.?)'  + r'([HLEr0123456789\s\-])(\.?)'*4 +r'([abcd]?)')


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115900&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 11:58:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 03:58:04 -0700
Subject: [Python-bugs-list] [Bug #114490] crash on empty module registry key
Message-ID: <200010031058.DAA09081@bush.i.sourceforge.net>

Bug #114490, was updated on 2000-Sep-15 00:31
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Closed
Resolution: Duplicate
Bug Group: Platform-specific
Priority: 6
Summary: crash on empty module registry key

Details: Having an empty module path key under the PythonPath Registry key lets Python die on startup.

Follow-Ups:

Date: 2000-Sep-15 00:40
By: tim_one

Comment:
Assigned to MarkH and boosted priority.

BobJuner, you didn't say which version of Python you're using.  If you can, please try it with a current snapshot from CVS:  MarkH very recently fixed something similar, and possibly similar enough to be identical.

-------------------------------------------------------

Date: 2000-Sep-16 14:29
By: BobJuner

Comment:
This occured to me using 2.0b1. I'll try a CVS snapshot during the next days.
-------------------------------------------------------

Date: 2000-Sep-16 15:40
By: mhammond

Comment:
Almost certainly a dupe of 113828 - as you have not produced a test case I can not be 100% sure this is the same bug, but am pretty close to that sure :-)
-------------------------------------------------------

Date: 2000-Oct-03 03:58
By: mhammond

Comment:
Marking as dup, since there has been no confirmed sighting since the cited dupe.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114490&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 12:45:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 04:45:04 -0700
Subject: [Python-bugs-list] [Bug #115903] sre: split exceeds recursion limit
Message-ID: <200010031145.EAA02515@delerium.i.sourceforge.net>

Bug #115903, was updated on 2000-Oct-03 04:45
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: sre: split exceeds recursion limit

Details: Python 1.6 (#2, Sep  6 2000, 18:20:07) [C] on osf1V4
>>> import sre
>>> import pre
>>> txt=open("file").read()
>>> patt1=sre.compile('a.*?bb', sre.DOTALL)
>>> patt2=pre.compile('a.*?bb', pre.DOTALL)
>>> patt1.split(txt)                               # ERROR
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python1.6/sre.py", line 146, in _split
    m = c.search()
RuntimeError: maximum recursion limit exceeded
>>> patt2.split(txt)                               # OK
['begin\012', '\012end\012']

where file content is:

  begin
  atttttttb
  atttttttb
  ... 
  atttttttb
  atttttttb
  atttttttbb
  end

If string "atttttttb" is repeated more than 1000 times
sre ends with RuntimeError.

If "attttttt" or "atttttttbb" are used instead of
"atttttttb" lines, there is no problem.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115903&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 13:47:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 05:47:05 -0700
Subject: [Python-bugs-list] [Bug #115907] Encoding of "=" by quopri.py module
Message-ID: <200010031247.FAA13358@bush.i.sourceforge.net>

Bug #115907, was updated on 2000-Oct-03 05:47
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Encoding of "=" by quopri.py module

Details: While making an automated mail sending engine, I used the quopri.encode(...) for my multipart mails.
quopri.encode(...) converts "=" into "==" while the mail clients expect "=3D". Thus I got some problems reading such mails with Outlook Express 5 , Netscape Messenger (Linux) and StarOffice Mail (Linux). Especially when the HTML part of the mail contains hyperkinks <a href=...>...</a> that crash Outlook express. The others make a 404 HTTP error.
I run Python 1.5.2, but this bug/feature remains perhaps with Python 1.6 and Python 2.0bx cause I didn't notice any change log to the quopri module.
I found a workaround (fix ?) by changing the "quote" function of "quopri.py" to this:
==== quopri.py ====
...
def quote(c):
## if c == ESCAPE:
##  return ESCAPE * 2
## else:
  i = ord(c)
  return ESCAPE + HEX[i/16] + HEX[i%16]
...
==== end quopri.py ====
Now, the 3 above mentioned mail clients read correctly the raw text and html parts of my mails - including hyperlinks.
Is it a bug, a feature, or did I misuse "quopri" ?

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115907&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 14:43:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 06:43:26 -0700
Subject: [Python-bugs-list] [Bug #115912] GC crashes in 2.0b1 and 2.0b2
Message-ID: <200010031343.GAA15699@bush.i.sourceforge.net>

Bug #115912, was updated on 2000-Oct-03 06:43
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 5
Summary: GC crashes in 2.0b1 and 2.0b2

Details: Forwarded message from Andrew Reutter at Origin:


We are experiencing crashes in both Python 2.0b1 and 2.0b2 that appear to be
related to cyclical garbage collection.
A summary of the scenario follows:

We have embedded Python as a .lib into a much larger project.  We build this
project in both Win32 and Solaris environments.
On Win32 _only_, we use custom memory management routines in order to
facilitate the tracking of memory.
The memory manager also fills memory with specific bit patterns upon both
allocation and deallocation in order to detect the use of uninitialized or
freed memory.

After several minutes of successful execution, we see a reproducible crash
in gc_list_remove.
It receives a node pointer which points to memory filled with our memory
initialization bit pattern (0xCD),
indicating to us that the allocation was successful, but the object was
never fully initialized or placed in a gc_list.
Although this crash occurs at the same point in our code each time, the
address of the node pointer varies with each execution,
making it impossible to set a breakpoint when the node allocation takes
place.

Since we only tweak memory management under Win32, our memory manager is
unlikely to be the culprit.
The crash disappears when Python is compiled without the WITH_CYCLE_GC
definition.

Unfortunately, the project is both extremely large and the source is closed,
so we are unable to send you a quick methodology for reproduction of our
crash.  We would nonetheless like to assist you in solving this problem in
any way we _are_ able, so let us know.
Are there any other reported bugs in gcmodule.c (we noted that some were
fixed when b2 was released)?
Is there any information you could provide us that would help us debug it
ourselves?  An example would be to direct us to the single method by which
all objects are allocated, if such a method exists.



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115912&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 14:44:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 06:44:27 -0700
Subject: [Python-bugs-list] [Bug #115912] GC crashes in 2.0b1 and 2.0b2
Message-ID: <200010031344.GAA15713@bush.i.sourceforge.net>

Bug #115912, was updated on 2000-Oct-03 06:43
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 5
Summary: GC crashes in 2.0b1 and 2.0b2

Details: Forwarded message from Andrew Reutter at Origin:


We are experiencing crashes in both Python 2.0b1 and 2.0b2 that appear to be
related to cyclical garbage collection.
A summary of the scenario follows:

We have embedded Python as a .lib into a much larger project.  We build this
project in both Win32 and Solaris environments.
On Win32 _only_, we use custom memory management routines in order to
facilitate the tracking of memory.
The memory manager also fills memory with specific bit patterns upon both
allocation and deallocation in order to detect the use of uninitialized or
freed memory.

After several minutes of successful execution, we see a reproducible crash
in gc_list_remove.
It receives a node pointer which points to memory filled with our memory
initialization bit pattern (0xCD),
indicating to us that the allocation was successful, but the object was
never fully initialized or placed in a gc_list.
Although this crash occurs at the same point in our code each time, the
address of the node pointer varies with each execution,
making it impossible to set a breakpoint when the node allocation takes
place.

Since we only tweak memory management under Win32, our memory manager is
unlikely to be the culprit.
The crash disappears when Python is compiled without the WITH_CYCLE_GC
definition.

Unfortunately, the project is both extremely large and the source is closed,
so we are unable to send you a quick methodology for reproduction of our
crash.  We would nonetheless like to assist you in solving this problem in
any way we _are_ able, so let us know.
Are there any other reported bugs in gcmodule.c (we noted that some were
fixed when b2 was released)?
Is there any information you could provide us that would help us debug it
ourselves?  An example would be to direct us to the single method by which
all objects are allocated, if such a method exists.



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115912&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 14:47:19 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 06:47:19 -0700
Subject: [Python-bugs-list] [Bug #115894] Difference between dos_8x3 and dos-8x3
Message-ID: <200010031347.GAA15781@bush.i.sourceforge.net>

Bug #115894, was updated on 2000-Oct-02 23:51
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Wont Fix
Bug Group: Not a Bug
Priority: 5
Summary: Difference between dos_8x3 and dos-8x3

Details: While looking for another bug, I ran across the following in src/Lib/ and am wondering if it's correct as it struck me as wrong...

src/Lib/dos_8x3 
src/Lib/dos-8x3

Is there a difference between the two or is it just an artifact?

Follow-Ups:

Date: 2000-Oct-03 06:47
By: gvanrossum

Comment:
It's a so-called "CVS turd". CVS won't let you delete directories. There once was a dos_8x3 directory but it was decided that the proper name was dos-8x3. The dos_8x3 directory is empty; when you use "cvs update -P" (-P stands for prune)empty directories will be deleted by CVS.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115894&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 14:53:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 06:53:58 -0700
Subject: [Python-bugs-list] [Bug #115900] difference between pre and sre for buggy expressions
Message-ID: <200010031353.GAA16141@bush.i.sourceforge.net>

Bug #115900, was updated on 2000-Oct-03 03:11
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: difference between pre and sre for buggy expressions

Details: def check_pattern(pattern):
    import pre, sre

    pre_version = pre.compile(pattern)

    print pre_version.match('-1234a')
    print pre_version.match(' 1234a')

    sre_version = sre.compile(pattern)

    print sre_version.match('-1234a')
    print sre_version.match(' 1234a')

# This is a buggy re: It is trying to match a minus sign as part of a
# set of characters, but does not follow the documented rule of
# "precede it with a backslash, or place it as the first character"
# However, pre and sre behave differently, and neither behaviour is
# quite what I was expecting. Is this a hint of a bug?
check_pattern('([\s-])(\.?)'  + r'([HLEr0123456789\s-])(\.?)'*4 +r'([abcd]?)')

# Preceeding them with a backslash makes pre and sre behave identically.
check_pattern('([\s\-])(\.?)'  + r'([HLEr0123456789\s\-])(\.?)'*4 +r'([abcd]?)')


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115900&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 14:54:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 06:54:11 -0700
Subject: [Python-bugs-list] [Bug #113811] Python 2.0 beta 1 -- urllib.urlopen() fails
Message-ID: <200010031354.GAA07711@delerium.i.sourceforge.net>

Bug #113811, was updated on 2000-Sep-07 09:45
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Irreproducible
Priority: 3
Summary: Python 2.0 beta 1 -- urllib.urlopen() fails

Details: In performing a urllib.urlopen(url) with "url" containing a valid URL, I got the following error message:

Traceback (most recent call last):
  File "IGNRatings.py", line 249, in ?
    main(sys.argv[1:])
  File "IGNRatings.py", line 132, in main
    inStream = urllib.urlopen(url)
  File "E:\Python20\lib\urllib.py", line 61, in urlopen
    return _urlopener.open(url)
  File "E:\Python20\lib\urllib.py", line 163, in open
    return getattr(self, name)(url)
  File "E:\Python20\lib\urllib.py", line 259, in open_http
    h = httplib.HTTP(host)
  File "E:\Python20\lib\httplib.py", line 626, in __init__
    self._conn = self._connection_class(host, port)
  File "E:\Python20\lib\httplib.py", line 325, in __init__
    self._set_hostport(host, port)
  File "E:\Python20\lib\httplib.py", line 332, in _set_hostport
    port = int(host[i+1:])
ValueError: invalid literal for int():


I looked into this a tiny bit and found that HTTPConnection.__init__() is called with host="http:" -- probably not the right thing. Python 1.6 works correctly.

Thanks,
Bob Alexander
bobalex@home.com

Follow-Ups:

Date: 2000-Sep-07 15:02
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-11 15:04
By: gvanrossum

Comment:
My suspicion is that this is caused by an invalid URL.
The stacktrace doesn't show what URL is being used, but I bet that on close inspection there's a tiny problem with it.

We'll have to close this for lack of information unless the original submittor can help us to debug this by printing the value of url in urlopen().
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113811&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 15:14:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 07:14:53 -0700
Subject: [Python-bugs-list] [Bug #110834] urlparse and HTTP parameters (PR#205)
Message-ID: <200010031414.HAA08554@delerium.i.sourceforge.net>

Bug #110834, was updated on 2000-Aug-01 14:13
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 3
Summary: urlparse and HTTP parameters (PR#205)

Details: Jitterbug-Id: 205
Submitted-By: mnot@akamai.com
Date: Tue, 15 Feb 2000 17:09:44 -0500 (EST)
Version: 1.5.2
OS: All


Python parses urls into the following data structure:
  (scheme, netloc, path, params, query, fragment)
and references RFC1808. 1808 has been updated by RFC2396, which allows
on each path segment, not just the last. This would imply a data structure
either like this:
  (scheme, netloc, path, query, fragment)
or this:
  (scheme, netloc, [(segment, parameters)...], query, fragment)

Rather than updating urlparse.py (and introducing incompatibility), it may be
nice to introduce a new class (say, uriparse.py) that implements 2396. If
there's enough interest, I may give it a go...


====================================================================
Audit trail:
Wed Feb 23 21:39:30 2000	guido	sent reply 1
Wed Feb 23 21:39:42 2000	guido	changed notes
Wed Feb 23 21:39:42 2000	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:13
By: none

Comment:
From: Guido van Rossum <bugs-py@python.org>
Subject: Re: urlparse and HTTP parameters (PR#205)
Date: Wed Feb 23 21:39:30 2000

Go for it!

--Guido van Rossum

-------------------------------------------------------

Date: 2000-Aug-01 14:13
By: none

Comment:
Go for it!
-------------------------------------------------------

Date: 2000-Aug-16 19:02
By: fdrake

Comment:
An excellent idea; it can be incorporated in the existing urlparse module using new names.  This won't be done for Python 2.0 at any rate, however.
-------------------------------------------------------

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-16 15:07
By: bwarsaw

Comment:
Jeremy seems like the best person to decide about this.
-------------------------------------------------------

Date: 2000-Oct-03 07:14
By: jhylton

Comment:
added to pep 42

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110834&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 15:52:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 07:52:51 -0700
Subject: [Python-bugs-list] [Bug #110681] memory leak in loops (PR#398)
Message-ID: <200010031452.HAA10044@delerium.i.sourceforge.net>

Bug #110681, was updated on 2000-Jul-31 14:14
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Wont Fix
Bug Group: Not a Bug
Priority: 5
Summary: memory leak in loops (PR#398)

Details: Jitterbug-Id: 398
Submitted-By: ingo.adler@synacon.ch
Date: Fri, 14 Jul 2000 05:10:25 -0400 (EDT)
Version: 1.5.2
OS: win nt


I have a simple loop, which produces memory leaks at every call (36 bytes):

{
    Py_SetProgramName("pythontest.exe");
    Py_Initialize();

    initxmodulec();

    PyRun_SimpleString("print \"... Python started ...\"");

    PyRun_SimpleString("import xmodule");
    PyRun_SimpleString("from xmodule import *");

// The Loop
    PyRun_SimpleString(
        "y = Y()\n"
        "for i in range(1000):\n"
        "\tx = y.getX()\n"
        "\tx.getNumber()\n"
    );




    PyRun_SimpleString("print \"... Python finished ...\"");
    Py_Finalize();
}

X and Y are my classes implemented in C++, connected to Python via Swig Shadow
Classes:

class X {

public:
    float getNumber()
    {
        return 12.2;
    }
};

class Y {
    X* pX;

public:
    Y()
    {
        pX = new X;
    }

    ~Y()
    {
        delete pX;
    }

    X* getX()
    {
        return pX;
    }
};

The classes and python are compiled statically with CBuilder5.0, Swig1.3a3 (same
problem with swig1.1).

I tested the application with "CodeGuard", which shows the memory leaks.
For every call in the loop there is an entry like this (I translated it to
English):

Error. 0x300010 (Thread 0x013B):
resource leak: memory block (0x15422F0) was never released

memory leak (0x015422F0) [size: 36 Byte] was assigned with malloc
call stack:
   0x0045ED5D(=pythontest.exe:0x01:05DD5D)
G:\Projects\src\fortuna\Python\Objects\stringobject.c#145
   0x00401EFD(=pythontest.exe:0x01:000EFD)
G:\Projects\src\fortuna\test\xmodule_wrap.c#769
   0x0040255D(=pythontest.exe:0x01:00155D)
G:\Projects\src\fortuna\test\xmodule_wrap.c#941
   0x0041BA79(=pythontest.exe:0x01:01AA79)
G:\Projects\src\fortuna\Python\Python\ceval.c#2359
   0x0041B912(=pythontest.exe:0x01:01A912)
G:\Projects\src\fortuna\Python\Python\ceval.c#2324
   0x0040EE3E(=pythontest.exe:0x01:00DE3E)
G:\Projects\src\fortuna\Python\Python\bltinmodule.c#12


The Code for line 941:

#define Y_getX(_swigobj)  (_swigobj->getX())
static PyObject *_wrap_Y_getX(PyObject *self, PyObject *args) {
    Y  *_arg0;
    PyObject  *_resultobj,*_argo0=0;
    X  *_result;
    self = self;
    if(!PyArg_ParseTuple(args,"O:Y_getX",&_argo0)) 
        return NULL;
    if ((SWIG_ConvertPtr(_argo0,(void **) &_arg0,SWIGTYPE_Y_p,1)) == -1) return
NULL;
    _result = (X *)Y_getX(_arg0);
/*941*/ _resultobj = SWIG_NewPointerObj((void *) _result, SWIGTYPE_X_p);
    return _resultobj;
}

The Code for line 769:

SWIGSTATICRUNTIME(PyObject *)
SWIG_NewPointerObj(void *ptr, _swig_type_info *type) {
  char result[512];
  PyObject *robj;
  if (!ptr) {
    Py_INCREF(Py_None);
    return Py_None;
  }
#ifdef SWIG_COBJECT_TYPES
  robj = PyCObject_FromVoidPtrAndDesc((void *) ptr, type->name, NULL);
#else
  SWIG_MakePtr(result,ptr,type);
/*769*/  robj = PyString_FromString(result);
#endif
  return robj;
}


Ingo Adler



====================================================================
Audit trail:
Tue Jul 25 07:27:50 2000	guido	changed notes
Tue Jul 25 07:27:50 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-01 14:01
By: none

Comment:
From: "M.-A. Lemburg" <mal@lemburg.com>
Subject: Re: [Python-bugs-list] memory leak in loops (PR#398)
Date: Fri, 14 Jul 2000 11:22:51 +0200

ingo.adler@synacon.ch wrote:
> 
> Full_Name: ingo adler
> Version: 1.5.2
> OS: win nt
> Submission from: megazh-d-201.agrinet.ch (212.28.158.201)
> 
> I have a simple loop, which produces memory leaks at every call (36 bytes):
> 
> {
>     Py_SetProgramName("pythontest.exe");
>     Py_Initialize();
> 
>     initxmodulec();
> 
>     PyRun_SimpleString("print \"... Python started ...\"");
> 
>     PyRun_SimpleString("import xmodule");
>     PyRun_SimpleString("from xmodule import *");
> 
> // The Loop
>     PyRun_SimpleString(
>         "y = Y()\n"
>         "for i in range(1000):\n"
>         "\tx = y.getX()\n"
>         "\tx.getNumber()\n"

Could be that SWIG doesn't get a chance to cleanup the shadow
object for x and y. Try adding

del x,y

as final script line.

Note that SWIG uses Python strings to represent pointers in
C++. It uses an internal table to store these.

>     );
> 
>     PyRun_SimpleString("print \"... Python finished ...\"");
>     Py_Finalize();
> }
> 
> X and Y are my classes implemented in C++, connected to Python via Swig Shadow
> Classes:
> 
> class X {
> 
> public:
>     float getNumber()
>     {
>         return 12.2;
>     }
> };
> 
> class Y {
>     X* pX;
> 
> public:
>     Y()
>     {
>         pX = new X;
>     }
> 
>     ~Y()
>     {
>         delete pX;
>     }
> 
>     X* getX()
>     {
>         return pX;
>     }
> };
> 
> The classes and python are compiled statically with CBuilder5.0, Swig1.3a3 (same
> problem with swig1.1).
> 
> I tested the application with "CodeGuard", which shows the memory leaks.
> For every call in the loop there is an entry like this (I translated it to
> English):
> 
> Error. 0x300010 (Thread 0x013B):
> resource leak: memory block (0x15422F0) was never released
> 
> memory leak (0x015422F0) [size: 36 Byte] was assigned with malloc
> call stack:
>    0x0045ED5D(=pythontest.exe:0x01:05DD5D)
> G:\Projects\src\fortuna\Python\Objects\stringobject.c#145
>    0x00401EFD(=pythontest.exe:0x01:000EFD)
> G:\Projects\src\fortuna\test\xmodule_wrap.c#769
>    0x0040255D(=pythontest.exe:0x01:00155D)
> G:\Projects\src\fortuna\test\xmodule_wrap.c#941
>    0x0041BA79(=pythontest.exe:0x01:01AA79)
> G:\Projects\src\fortuna\Python\Python\ceval.c#2359
>    0x0041B912(=pythontest.exe:0x01:01A912)
> G:\Projects\src\fortuna\Python\Python\ceval.c#2324
>    0x0040EE3E(=pythontest.exe:0x01:00DE3E)
> G:\Projects\src\fortuna\Python\Python\bltinmodule.c#12
> 
> The Code for line 941:
> 
> #define Y_getX(_swigobj)  (_swigobj->getX())
> static PyObject *_wrap_Y_getX(PyObject *self, PyObject *args) {
>     Y  *_arg0;
>     PyObject  *_resultobj,*_argo0=0;
>     X  *_result;
>     self = self;
>     if(!PyArg_ParseTuple(args,"O:Y_getX",&_argo0))
>         return NULL;
>     if ((SWIG_ConvertPtr(_argo0,(void **) &_arg0,SWIGTYPE_Y_p,1)) == -1) return
> NULL;
>     _result = (X *)Y_getX(_arg0);
> /*941*/ _resultobj = SWIG_NewPointerObj((void *) _result, SWIGTYPE_X_p);
>     return _resultobj;
> }
> 
> The Code for line 769:
> 
> SWIGSTATICRUNTIME(PyObject *)
> SWIG_NewPointerObj(void *ptr, _swig_type_info *type) {
>   char result[512];
>   PyObject *robj;
>   if (!ptr) {
>     Py_INCREF(Py_None);
>     return Py_None;
>   }
> #ifdef SWIG_COBJECT_TYPES
>   robj = PyCObject_FromVoidPtrAndDesc((void *) ptr, type->name, NULL);
> #else
>   SWIG_MakePtr(result,ptr,type);
> /*769*/  robj = PyString_FromString(result);
> #endif
>   return robj;
> }
> 
> Ingo Adler
> 
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Ingo Adler <ingo.adler@synacon.ch>
Subject: Re: [Python-bugs-list] memory leak in loops (PR#398)
Date: Fri, 14 Jul 2000 11:40:42 +0100

This is a multi-part message in MIME format.
--------------6D29988B97CCE77010389AE2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> > // The Loop
> >     PyRun_SimpleString(
> >         "y = Y()\n"
> >         "for i in range(1000):\n"
> >         "\tx = y.getX()\n"
> >         "\tx.getNumber()\n"
>
> Could be that SWIG doesn't get a chance to cleanup the shadow
> object for x and y. Try adding
>
> del x,y
>
> as final script line.
>
> Note that SWIG uses Python strings to represent pointers in
> C++. It uses an internal table to store these.
>

I changed the code to:

    PyRun_SimpleString(
        "y = Y()\n"
        "for i in range(1000):\n"
        "\tx = y.getX()\n"
        "\tx.getNumber()\n"
        "\tdel x\n"
    );

It doesn't change anything.

The memory leak only occurs when I call x.getNumber() in the loop. Otherwise x =
y.getX() is memory leak free.

Ingo Adler

--------------6D29988B97CCE77010389AE2
Content-Type: text/x-vcard; charset=us-ascii;
 name="ingo.adler.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ingo Adler
Content-Disposition: attachment;
 filename="ingo.adler.vcf"

begin:vcard 
n:Adler;Ingo
tel;cell:+41-79-3786792
tel;fax:+41-41-7103244
tel;home:+41-41-7103268
tel;work:+41-41-8111500
x-mozilla-html:FALSE
url:www.synacon.ch
org:Synacon GmbH
adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland
version:2.1
email;internet:ingo.adler@synacon.ch
title:Dipl.-Inform.
fn:Ingo Adler
end:vcard

--------------6D29988B97CCE77010389AE2--



-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: "M.-A. Lemburg" <mal@lemburg.com>
Subject: Re: [Python-bugs-list] memory leak in loops (PR#398)
Date: Fri, 14 Jul 2000 12:13:13 +0200

Ingo Adler wrote:
> 
> > > // The Loop
> > >     PyRun_SimpleString(
> > >         "y = Y()\n"
> > >         "for i in range(1000):\n"
> > >         "\tx = y.getX()\n"
> > >         "\tx.getNumber()\n"
> >
> > Could be that SWIG doesn't get a chance to cleanup the shadow
> > object for x and y. Try adding
> >
> > del x,y
> >
> > as final script line.
> >
> > Note that SWIG uses Python strings to represent pointers in
> > C++. It uses an internal table to store these.
> >
> 
> I changed the code to:
> 
>     PyRun_SimpleString(
>         "y = Y()\n"
>         "for i in range(1000):\n"
>         "\tx = y.getX()\n"
>         "\tx.getNumber()\n"
>         "\tdel x\n"
>     );
> 
> It doesn't change anything.
> 
> The memory leak only occurs when I call x.getNumber() in the loop. Otherwise x =
> y.getX() is memory leak free.

Two other possibilities:

1. Python interns the string object used by SWIG to represent
the point. It should then free the memory in the Py_Finalize()
call. If it doesn't, there's a bug to be found ;-)

2. SWIG has the leak. Try using the alternative method of
defining SWIG_COBJECT_TYPES (don't know how this is done --
it seems to be new in SWIG).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Ingo Adler <ingo.adler@synacon.ch>
Subject: Re: [Python-bugs-list] memory leak in loops (PR#398)
Date: Fri, 14 Jul 2000 12:45:02 +0100

This is a multi-part message in MIME format.
--------------82393A6779ADCFC3A2ADE19E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I could reproduce the problem with Developer Studio 6.0.

If anyone wants the project to test it - I can provide it.

Ingo Adler

--------------82393A6779ADCFC3A2ADE19E
Content-Type: text/x-vcard; charset=us-ascii;
 name="ingo.adler.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ingo Adler
Content-Disposition: attachment;
 filename="ingo.adler.vcf"

begin:vcard 
n:Adler;Ingo
tel;cell:+41-79-3786792
tel;fax:+41-41-7103244
tel;home:+41-41-7103268
tel;work:+41-41-8111500
x-mozilla-html:FALSE
url:www.synacon.ch
org:Synacon GmbH
adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland
version:2.1
email;internet:ingo.adler@synacon.ch
title:Dipl.-Inform.
fn:Ingo Adler
end:vcard

--------------82393A6779ADCFC3A2ADE19E--



-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: "Mark Hammond" <mhammond@skippinet.com.au>
Subject: RE: [Python-bugs-list] memory leak in loops (PR#398)
Date: Mon, 17 Jul 2000 22:16:54 -0400

> I could reproduce the problem with Developer Studio 6.0.
>
> If anyone wants the project to test it - I can provide it.

If you can repro the problem in just a few lines of C/C++ code but with no
SWIG generated code, I would be interested.  Otherwise, I suggest you do
some more work to narrow the problem down some more; as described, there is
still too much work to be done to narrow down the problem to the cause for
me to be interested (or anyone else given the feedback to date!)

Mark.



-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Ingo Adler <ingo.adler@synacon.ch>
Subject: Re: [Python-bugs-list] memory leak in loops (PR#398)
Date: Tue, 25 Jul 2000 01:34:22 +0200

This is a multi-part message in MIME format.
--------------72A23DA082087CB843E12C92
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Mark,

I could repro the memory leaks (they seem to be the same) with a much smaller
program:

int main(int argc, char* argv[])
{
    Py_SetProgramName("pythontest.exe");
    Py_Initialize();
    PyRun_SimpleString("print \"... Python started ...\"");
    PyRun_SimpleString("print \"... Python finished ...\"");
    Py_Finalize();

    return 0;
}

There seems to be a more general problem, which includes my special problem.

Output of Code Guard (translated to English). BoundsChecker shows the same
leaks.

Ingo

Output:

Memory Block (0x014EB9B4) [Size: 37 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043515A(=pythontest.exe:0x01:03415A)
D:\projects\Python\Objects\stringobject.c#95
   0x0043A8EB(=pythontest.exe:0x01:0398EB)
D:\projects\Python\Python\marshal.c#483
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504
   0x0043AB88(=pythontest.exe:0x01:039B88)
D:\projects\Python\Python\marshal.c#568
   0x0043AD37(=pythontest.exe:0x01:039D37)
D:\projects\Python\Python\marshal.c#624
   0x0042BC54(=pythontest.exe:0x01:02AC54)
D:\projects\Python\Python\import.c#575

------------------------------------------
Error 00078. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E4858) was never freed

Memory Block (0x014E4858) [Size: 31 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00425400(=pythontest.exe:0x01:024400)
D:\projects\Python\Objects\dictobject.c#1084
   0x00433896(=pythontest.exe:0x01:032896)
D:\projects\Python\Objects\moduleobject.c#56
   0x0042B993(=pythontest.exe:0x01:02A993)
D:\projects\Python\Python\import.c#428
   0x0043B0C9(=pythontest.exe:0x01:03A0C9)
D:\projects\Python\Python\modsupport.c#82
   0x0040C68A(=pythontest.exe:0x01:00B68A)
D:\projects\Python\Python\bltinmodule.c#2393

------------------------------------------
Error 00079. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E47D0) was never freed

Memory Block (0x014E47D0) [Size: 28 Byte] was assigned with malloc
Aufrufhierarchie:
   0x00433CB3(=pythontest.exe:0x01:032CB3)
D:\projects\Python\Objects\object.c#122
   0x00424115(=pythontest.exe:0x01:023115)
D:\projects\Python\Objects\dictobject.c#124
   0x004367D3(=pythontest.exe:0x01:0357D3)
D:\projects\Python\Objects\stringobject.c#1075
   0x00425418(=pythontest.exe:0x01:024418)
D:\projects\Python\Objects\dictobject.c#1087
   0x0043387A(=pythontest.exe:0x01:03287A)
D:\projects\Python\Objects\moduleobject.c#54
   0x0042B993(=pythontest.exe:0x01:02A993)
D:\projects\Python\Python\import.c#428

------------------------------------------
Error 00080. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E47AC) was never freed

Memory Block (0x014E47AC) [Size: 32 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00425400(=pythontest.exe:0x01:024400)
D:\projects\Python\Objects\dictobject.c#1084
   0x0043387A(=pythontest.exe:0x01:03287A)
D:\projects\Python\Objects\moduleobject.c#54
   0x0042B993(=pythontest.exe:0x01:02A993)
D:\projects\Python\Python\import.c#428
   0x0043B0C9(=pythontest.exe:0x01:03A0C9)
D:\projects\Python\Python\modsupport.c#82
   0x0040C68A(=pythontest.exe:0x01:00B68A)
D:\projects\Python\Python\bltinmodule.c#2393

------------------------------------------
Error 00081. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E46E4) was never freed

Memory Block (0x014E46E4) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x004240F7(=pythontest.exe:0x01:0230F7)
D:\projects\Python\Objects\dictobject.c#120
   0x0043C27B(=pythontest.exe:0x01:03B27B)
D:\projects\Python\Python\pythonrun.c#132
   0x00402934(=pythontest.exe:0x01:001934)
G:\Projects\src\test\pythonmain.cpp#15
   0x3257DC12(=CC3250MT.DLL:0x01:07CC12)

------------------------------------------
Error 00082. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x1524000) was never freed

Memory Block (0x01524000) [Size: 12288 Byte] was assigned with malloc
Aufrufhierarchie:
   0x004243A7(=pythontest.exe:0x01:0233A7)
D:\projects\Python\Objects\dictobject.c#280
   0x004245C4(=pythontest.exe:0x01:0235C4)
D:\projects\Python\Objects\dictobject.c#370
   0x00436837(=pythontest.exe:0x01:035837)
D:\projects\Python\Objects\stringobject.c#1086
   0x00415CA9(=pythontest.exe:0x01:014CA9)
D:\projects\Python\Python\compile.c#249
   0x0043AC12(=pythontest.exe:0x01:039C12)
D:\projects\Python\Python\marshal.c#578
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504

------------------------------------------
Error 00083. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFC9C) was never freed

Memory Block (0x014EFC9C) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411EE6(=pythontest.exe:0x01:010EE6)
D:\projects\Python\Objects\classobject.c#126
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00084. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFC74) was never freed

Memory Block (0x014EFC74) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411ED6(=pythontest.exe:0x01:010ED6)
D:\projects\Python\Objects\classobject.c#125
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00085. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFC4C) was never freed

Memory Block (0x014EFC4C) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411EC6(=pythontest.exe:0x01:010EC6)
D:\projects\Python\Objects\classobject.c#124
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00086. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14F19CC) was never freed

Memory Block (0x014F19CC) [Size: 47 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00431E97(=pythontest.exe:0x01:030E97)
D:\projects\Python\Objects\listobject.c#309
   0x0041137E(=pythontest.exe:0x01:01037E)
D:\projects\Python\Python\ceval.c#2512
   0x0040F906(=pythontest.exe:0x01:00E906)
D:\projects\Python\Python\ceval.c#1503
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324
   0x0042BAD4(=pythontest.exe:0x01:02AAD4)
D:\projects\Python\Python\import.c#485

------------------------------------------
Error 00087. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14F596C) was never freed

Memory Block (0x014F596C) [Size: 32 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x0042CED6(=pythontest.exe:0x01:02BED6)
D:\projects\Python\Python\import.c#1513
   0x0042CD19(=pythontest.exe:0x01:02BD19)
D:\projects\Python\Python\import.c#1441
   0x0042CE6A(=pythontest.exe:0x01:02BE6A)
D:\projects\Python\Python\import.c#1489
   0x00409B32(=pythontest.exe:0x01:008B32)
D:\projects\Python\Python\bltinmodule.c#65

------------------------------------------
Error 00088. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EB870) was never freed

Memory Block (0x014EB870) [Size: 32 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043515A(=pythontest.exe:0x01:03415A)
D:\projects\Python\Objects\stringobject.c#95
   0x0043A8EB(=pythontest.exe:0x01:0398EB)
D:\projects\Python\Python\marshal.c#483
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504
   0x0043AB88(=pythontest.exe:0x01:039B88)
D:\projects\Python\Python\marshal.c#568
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504
   0x0043AB76(=pythontest.exe:0x01:039B76)
D:\projects\Python\Python\marshal.c#567

------------------------------------------
Error 00089. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFBDC) was never freed

Memory Block (0x014EFBDC) [Size: 34 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411C9E(=pythontest.exe:0x01:010C9E)
D:\projects\Python\Objects\classobject.c#58
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00090. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E74C4) was never freed

Memory Block (0x014E74C4) [Size: 988 Byte] was assigned with malloc
Aufrufhierarchie:
   0x00430B62(=pythontest.exe:0x01:02FB62)
D:\projects\Python\Objects\intobject.c#113
   0x00430BFD(=pythontest.exe:0x01:02FBFD)
D:\projects\Python\Objects\intobject.c#163
   0x0040C6FC(=pythontest.exe:0x01:00B6FC)
D:\projects\Python\Python\bltinmodule.c#2404
   0x0043C29A(=pythontest.exe:0x01:03B29A)
D:\projects\Python\Python\pythonrun.c#136
   0x00402934(=pythontest.exe:0x01:001934)
G:\Projects\src\test\pythonmain.cpp#15
   0x3257DC12(=CC3250MT.DLL:0x01:07CC12)

------------------------------------------
Error 00091. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E96C4) was never freed

Memory Block (0x014E96C4) [Size: 174 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0042B0D9(=pythontest.exe:0x01:02A0D9) D:\projects\Python\PC\getpathp.c#403

   0x0042B2D5(=pythontest.exe:0x01:02A2D5) D:\projects\Python\PC\getpathp.c#508

   0x0043E40C(=pythontest.exe:0x01:03D40C)
D:\projects\Python\Python\sysmodule.c#413
   0x0043C2CA(=pythontest.exe:0x01:03B2CA)
D:\projects\Python\Python\pythonrun.c#142
   0x00402934(=pythontest.exe:0x01:001934)
G:\Projects\src\test\pythonmain.cpp#15
   0x3257DC12(=CC3250MT.DLL:0x01:07CC12)

------------------------------------------
Error 00092. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EF660) was never freed

Memory Block (0x014EF660) [Size: 36 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00425400(=pythontest.exe:0x01:024400)
D:\projects\Python\Objects\dictobject.c#1084
   0x0042BA54(=pythontest.exe:0x01:02AA54)
D:\projects\Python\Python\import.c#466
   0x0042BF73(=pythontest.exe:0x01:02AF73)
D:\projects\Python\Python\import.c#724
   0x0042C876(=pythontest.exe:0x01:02B876)
D:\projects\Python\Python\import.c#1202
   0x0042D51E(=pythontest.exe:0x01:02C51E)
D:\projects\Python\Python\import.c#1755

------------------------------------------
Error 00093. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x15211C8) was never freed

Memory Block (0x015211C8) [Size: 31 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x004129EE(=pythontest.exe:0x01:0119EE)
D:\projects\Python\Objects\classobject.c#517
   0x004246DD(=pythontest.exe:0x01:0236DD)
D:\projects\Python\Objects\dictobject.c#419
   0x0042546E(=pythontest.exe:0x01:02446E)
D:\projects\Python\Objects\dictobject.c#1103
   0x0043DF2E(=pythontest.exe:0x01:03CF2E)
D:\projects\Python\Python\sysmodule.c#95

------------------------------------------
Aufgerufene Funktionen:
 delete (35 Mal)
 getchar (1 Mal)
 fflush (2 Mal)
 fputs (2 Mal)
 fwrite (2 Mal)
 vsprintf (2 Mal)
 strrchr (14 Mal)
 fclose (14 Mal)
 strspn (251 Mal)
 fread (2021 Mal)
 _fgetc (40 Mal)
 fstat (7 Mal)
 fopen (72 Mal)
 strncmp (19 Mal)
 strcmp (423 Mal)
 stat (21 Mal)
 strncpy (32 Mal)
 strchr (125 Mal)
 sprintf (2 Mal)
 memcmp (1349 Mal)
 memset (133 Mal)
 strcpy (834 Mal)
 strlen (784 Mal)
 SysFreeMem (87 Mal)
 SysGetMem (87 Mal)
 realloc (88 Mal)
 memcpy (837 Mal)
 delete[] (2 Mal)
 free (4936 Mal)
 new[] (14 Mal)
 new (40 Mal)
 calloc (5 Mal)
 malloc (4946 Mal)
Verwendete Resource-Arten:
 Datei-Stream (14 Allocs, 5 max)
 Datei-Handle (14 Allocs, 5 max)
 Objekt-Array (14 Allocs, 13 max)
 Objekt (40 Allocs, 28 max)
 Memory Block (5039 Allocs, 2448 max)
Verwendete Module:
 00400000 07/25/2000 01:06:08 G:\Projects\src\bin\pythontest.exe
 0CD00000 02/03/2000 06:00:00 g:\programme\borland\cbuilder5\bin\CG32.DLL
 201A0000 02/22/2000 05:20:00 C:\WINNT.45\TRAYHOOK.dll
 32500000 02/03/2000 06:00:00 G:\Projects\src\bin\CC3250MT.DLL
 40000000 02/03/2000 05:01:00 C:\WINNT.45\System32\VCL50.BPL
 41000000 02/03/2000 06:00:00 G:\Projects\src\bin\BORLNDMM.DLL
 52180000 08/09/1996 00:00:00 C:\WINNT.45\system32\version.dll
 61220000 12/07/1999 16:03:46 G:\Programme\Microsoft
 Hardware\Mouse\MSH_ZWF.dll
 65340000 02/18/2000 16:16:02 C:\WINNT.45\system32\oleaut32.dll
 70970000 05/09/1998 13:57:06 C:\WINNT.45\system32\SHELL32.dll
 70BD0000 03/18/1999 00:00:00 C:\WINNT.45\system32\SHLWAPI.dll
 71190000 07/22/1999 21:09:08 C:\WINNT.45\system32\MSIDLE.DLL
 71590000 03/18/1999 00:00:00 C:\WINNT.45\system32\COMCTL32.dll
 73060000 05/13/1999 12:05:00 C:\WINNT.45\System32\winspool.drv
 77660000 05/13/1999 12:05:00 C:\WINNT.45\System32\MSWSOCK.dll
 77666C35 05/13/1999 12:05:00 C:\WINNT.45\system32\wsock32.dll
 77690000 05/13/1999 12:05:00 C:\WINNT.45\system32\WS2HELP.dll
 776A0000 05/13/1999 12:05:00 C:\WINNT.45\system32\WS2_32.dll
 77710000 05/13/1999 12:05:00 C:\WINNT.45\system32\mpr.dll
 77920000 05/13/1999 12:05:00 C:\WINNT.45\System32\oledlg.dll
 779B0000 08/09/1996 00:00:00 C:\WINNT.45\system32\LZ32.dll
 77B80000 05/13/1999 12:05:00 C:\WINNT.45\system32\ole32.dll
 77D80000 05/13/1999 12:05:00 C:\WINNT.45\system32\comdlg32.dll
 77DC0000 05/13/1999 12:05:00 C:\WINNT.45\system32\ADVAPI32.dll
 77E10000 05/13/1999 12:05:00 C:\WINNT.45\system32\RPCRT4.dll
 77E70000 05/13/1999 12:05:00 C:\WINNT.45\system32\user32.dll
 77ED0000 05/13/1999 12:05:00 C:\WINNT.45\system32\GDI32.dll
 77F00000 05/13/1999 12:05:00 C:\WINNT.45\system32\kernel32.dll
 77F70000 05/13/1999 12:05:00 C:\WINNT.45\System32\ntdll.dll
 78000000 12/07/1999 05:00:00 C:\WINNT.45\system32\MSVCRT.dll
==========================================



Mark Hammond wrote:

> > I could reproduce the problem with Developer Studio 6.0.
> >
> > If anyone wants the project to test it - I can provide it.
>
> If you can repro the problem in just a few lines of C/C++ code but with no
> SWIG generated code, I would be interested.  Otherwise, I suggest you do
> some more work to narrow the problem down some more; as described, there is
> still too much work to be done to narrow down the problem to the cause for
> me to be interested (or anyone else given the feedback to date!)
>
> Mark.

--------------72A23DA082087CB843E12C92
Content-Type: text/x-vcard; charset=us-ascii;
 name="ingo.adler.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ingo Adler
Content-Disposition: attachment;
 filename="ingo.adler.vcf"

begin:vcard 
n:Adler;Ingo
tel;fax:+41-41-7103244
tel;work:+41-41-8111500
x-mozilla-html:FALSE
org:Synacon GmbH
adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland
version:2.1
email;internet:ingo.adler@synacon.ch
fn:Ingo Adler
end:vcard

--------------72A23DA082087CB843E12C92--



-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
Actually, it's hard to say whether this is worth fixing...
Could it be a SWIG problem?
-------------------------------------------------------

Date: 2000-Sep-25 12:54
By: bwarsaw

Comment:
I don't believe there is a Python bug worth fixing here.  I've done some memory use testing with Python 2.0b2 using Insure++ on Linux, both with the regular interpreter, and with the small example embedded script given below.

There are "technical" memory leaks but they are almost all related to either leaks in the OS, or global memory still in use at the time Python exits.  An example of the former is leaks in strerror() - nothing we can do about that.  An example of the latter are leaks in the string intern dictionary, and we've already decided not to do anything about that.

There no identifiable chunks of memory leaked every time through the loop so I believe the problems reported below are either related to swig, have been fixed for Python 2.0, or are of the variety described above.
-------------------------------------------------------

Date: 2000-Oct-03 07:52
By: tregnago

Comment:
I'm working on an embedded application. I've looked with CodeGuard and it detect few memory leaks( similar as reported below ) only executing "Py_Initialize()" immediatly followed by "Py_Finalize()". Are you sure that this basic example is leaks free in your case?
I'm in big problems with that, and I can't find a way to escape from that.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110681&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 15:55:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 07:55:50 -0700
Subject: [Python-bugs-list] [Bug #115918] 2.0b2: print a_module.__dict__ also prints the license text
Message-ID: <200010031455.HAA18693@bush.i.sourceforge.net>

Bug #115918, was updated on 2000-Oct-03 07:55
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 2.0b2: print a_module.__dict__ also prints the license text

Details: When trying to print the dictionary of an imported module, say:

import a_module
print a_module.__dict__

Python 2.0b2 also prints the Python license text (intermingled
with the printing of the dictionary contents).


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115918&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 16:01:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 08:01:03 -0700
Subject: [Python-bugs-list] [Bug #115919] Integer multiplication overflow
Message-ID: <200010031501.IAA10456@delerium.i.sourceforge.net>

Bug #115919, was updated on 2000-Oct-03 08:01
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Integer multiplication overflow

Details: roland@cachemir ~ $ python2.0 
Python 2.0b2 (#3, Oct  3 2000, 16:30:25) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> 1+1
2
>>> 1*1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>> 

Last CVS update 2000-10-03 around 14:00 UTC.  Last before that was some weeks ago, sorry for not being precise.  Compiled with ./configure --prefix=/usr/local/ && make, su and make install.  Only personal change is the use of readline in Modules/Setup.local.  Did I do something wrong?

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115919&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 16:02:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 08:02:45 -0700
Subject: [Python-bugs-list] [Bug #115903] sre: split exceeds recursion limit
Message-ID: <200010031502.IAA10486@delerium.i.sourceforge.net>

Bug #115903, was updated on 2000-Oct-03 04:45
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: sre: split exceeds recursion limit

Details: Python 1.6 (#2, Sep  6 2000, 18:20:07) [C] on osf1V4
>>> import sre
>>> import pre
>>> txt=open("file").read()
>>> patt1=sre.compile('a.*?bb', sre.DOTALL)
>>> patt2=pre.compile('a.*?bb', pre.DOTALL)
>>> patt1.split(txt)                               # ERROR
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python1.6/sre.py", line 146, in _split
    m = c.search()
RuntimeError: maximum recursion limit exceeded
>>> patt2.split(txt)                               # OK
['begin\012', '\012end\012']

where file content is:

  begin
  atttttttb
  atttttttb
  ... 
  atttttttb
  atttttttb
  atttttttbb
  end

If string "atttttttb" is repeated more than 1000 times
sre ends with RuntimeError.

If "attttttt" or "atttttttbb" are used instead of
"atttttttb" lines, there is no problem.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115903&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 16:03:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 08:03:58 -0700
Subject: [Python-bugs-list] [Bug #114256] Python 2.0b1, Win2K - urllib failure
Message-ID: <200010031503.IAA10616@delerium.i.sourceforge.net>

Bug #114256, was updated on 2000-Sep-12 09:16
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Summary: Python 2.0b1, Win2K - urllib failure

Details: This might be related to bug #110692, since it seems to be related to proxies.

A program I have that works under older versions of Python now fails with this traceback:


Traceback (most recent call last):
  File "IGNRatings.py", line 289, in ?
    main(sys.argv[1:])
  File "IGNRatings.py", line 133, in main
    inStream = urllib.urlopen(url)
  File "E:\Python20\lib\urllib.py", line 61, in urlopen
    return _urlopener.open(url)
  File "E:\Python20\lib\urllib.py", line 163, in open
    return getattr(self, name)(url)
  File "E:\Python20\lib\urllib.py", line 259, in open_http
    h = httplib.HTTP(host)
  File "E:\Python20\lib\httplib.py", line 624, in __init__
    self._conn = self._connection_class(host, port)
  File "E:\Python20\lib\httplib.py", line 324, in __init__
    self._set_hostport(host, port)
  File "E:\Python20\lib\httplib.py", line 330, in _set_hostport
    port = int(host[i+1:])
ValueError: invalid literal for int():


My URL is nothing special:

    'http://dreamcast.ign.com/review_lists/a.html'


I have tracked the problem down a bit:

In urllib.py, line 147, the statement

    proxy = self.proxies[type]

assigns the string

    'http://http://proxy:8080'

to "proxy". My guess is that's not right. Anyway, the following line assigns

    type = 'http'
    proxy = '//http://proxy:8080'

and the next line assigns

    host = 'http:'
    selector = '//proxy:8080'

'http:' as a host name then goes on to cause trouble when an HTTPConnection is constructed.

Hope this info helps you track it down.

Bob Alexander
bobalex@home.com

Follow-Ups:

Date: 2000-Sep-24 11:51
By: effbot

Comment:
Fixed in 2.0b2.

The earlier code assumed "protocol=host;protocol=host;..." or "host", but Windows may also use "protocol=host" (just one entry), as well as "protocol://host".  This code needs some more work, so I'll leave the bug open for now.
-------------------------------------------------------

Date: 2000-Sep-30 21:35
By: gvanrossum

Comment:
Fredrik, can you fix the code right or assign it to someone else who can? Or decide to close the bug report after all.
-------------------------------------------------------

Date: 2000-Oct-03 08:03
By: effbot

Comment:
Okay, I've failed to find case for which the new code
doesn't work, so let's close this one.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114256&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 16:12:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 08:12:50 -0700
Subject: [Python-bugs-list] [Bug #115845] sre: maxsplit as keyword argument
Message-ID: <200010031512.IAA10917@delerium.i.sourceforge.net>

Bug #115845, was updated on 2000-Oct-02 06:31
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: sre: maxsplit as keyword argument

Details: Split gives TypeError when called as a method of compiled
regular expression object with maxsplit as keyword argument.
This error is only in sre, pre is OK.

Python 1.6 (#2, Sep  6 2000, 18:20:07) [C] on osf1V4
>>> import re
>>> patt = re.compile(' ')
>>> list = patt.split("a b c",50)              # OK
>>> list = re.split(' ',"a b c",maxsplit=50)   # OK     
>>> list = patt.split("a b c",maxsplit=50)     # ERROR
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: this function takes no keyword arguments

>>> import pre
>>> patt = pre.compile(' ')
>>> list = patt.split("a b c",maxsplit=50)     # OK



Follow-Ups:

Date: 2000-Oct-03 08:12
By: effbot

Comment:
maxcount is a positional argument, and you shouldn't
really use keyword arguments unless the documentation
*explicitly* tells you to...

(but we might fix this anyway -- stay tuned)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115845&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 16:16:33 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 08:16:33 -0700
Subject: [Python-bugs-list] [Bug #115918] 2.0b2: print a_module.__dict__ also prints the license text
Message-ID: <200010031516.IAA19497@bush.i.sourceforge.net>

Bug #115918, was updated on 2000-Oct-03 07:55
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 2.0b2: print a_module.__dict__ also prints the license text

Details: When trying to print the dictionary of an imported module, say:

import a_module
print a_module.__dict__

Python 2.0b2 also prints the Python license text (intermingled
with the printing of the dictionary contents).


Follow-Ups:

Date: 2000-Oct-03 08:16
By: gvanrossum

Comment:
Hm. Yes, this is a problem. It's caused because __dict__ contains __builtins__ which contains the magic license object. Barry -- what to do? Maybe the license object should have a static repr which is the entire license text????
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115918&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 16:19:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 08:19:17 -0700
Subject: [Python-bugs-list] [Bug #115918] 2.0b2: print a_module.__dict__ also prints the license text
Message-ID: <200010031519.IAA11261@delerium.i.sourceforge.net>

Bug #115918, was updated on 2000-Oct-03 07:55
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: 2.0b2: print a_module.__dict__ also prints the license text

Details: When trying to print the dictionary of an imported module, say:

import a_module
print a_module.__dict__

Python 2.0b2 also prints the Python license text (intermingled
with the printing of the dictionary contents).


Follow-Ups:

Date: 2000-Oct-03 08:16
By: gvanrossum

Comment:
Hm. Yes, this is a problem. It's caused because __dict__ contains __builtins__ which contains the magic license object. Barry -- what to do? Maybe the license object should have a static repr which is the entire license text????
-------------------------------------------------------

Date: 2000-Oct-03 08:19
By: jhylton

Comment:
Is there any way to make the license builtin behave nicely in this context?

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115918&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 16:19:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 08:19:37 -0700
Subject: [Python-bugs-list] [Bug #113803] [2.0b1 NT4.0] printing non asci char causes idle to abort
Message-ID: <200010031519.IAA19699@bush.i.sourceforge.net>

Bug #113803, was updated on 2000-Sep-07 08:33
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: [2.0b1 NT4.0] printing non asci char causes idle to abort

Details: try:

alef = u'\u05d0'
print alef.encode('utf-8')

any enter after the last statement will cause idle to abort

on 'bare' python this does not cause any problem.

[tebeka@lycosmail.com]

Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-12 15:13
By: gvanrossum

Comment:
Crash confirmed in IDLE on Win98SE.
Prints (expected) garbage and doesn't crash in command line on Win98SE.
No crash in IDLE or command line on Linux.

Tim, can you take a look with the VC debugger?

-------------------------------------------------------

Date: 2000-Sep-12 19:45
By: tim_one

Comment:
Changed group to platform-specific.

Note that this is a simpler test case w/ the same symptom:

print "\327\220"

Don't know why, do know that _tkinter.pyd and tk83.dll crap out w/ page faults at the end, assigned to Fredrik on the chance he's bumped into this before.  /F, bounce it back at me if it's unclear to you.
-------------------------------------------------------

Date: 2000-Sep-12 23:38
By: tim_one

Comment:
Bad news:  this doesn't always fail in the debugger (sometimes it just prints an alef glyph and nothing odd happens at all).

Better news:  it usually fails, and when it does it dies here (_tkinter.c):

static char *
AsString(PyObject *value, PyObject *tmp)
{
	if (PyString_Check(value))
		return PyString_AsString(value);
	else {
		PyObject *v = PyObject_Str(value);
		PyList_Append(tmp, v);
		Py_DECREF(v);
		return PyString_AsString(v);
	}
}

It's in the "else" branch, v is NULL, and the Py_DECREF expansion blows up with an access violation.  Py_ObjectStr certainly *can* return NULL, and I don't understand the intent of this code well enough to know why it believes that needn't be guarded against.

"value" at this point has type PyUnicode_Type.  For whatever reason, the debugger won't let me cast it to a PyUnicodeObject*.
-------------------------------------------------------

Date: 2000-Sep-20 00:30
By: micpro

Comment:
Crash confirmed for python 2.0 on Linux.
Segfault in _tkinter:267 when called from _tkinter.c:1260
Reason: string object expected, but unicode is given.
AsObj does treat this correctly, so this gets better after
changing line 1260
   Tcl_SetResult(Tkapp_Interp(self), AsString(res, tmp),
                 TCL_VOLATILE);

to
   Tcl_SetObjResult(Tkapp_Interp(self), AsObj(res));

After this change, idle does not segfault anymore and prints
alef correctly, but it still behaves strange after printing. it.
-------------------------------------------------------

Date: 2000-Sep-30 21:32
By: gvanrossum

Comment:
This looks kinda important, so I've raised the priority.
-------------------------------------------------------

Date: 2000-Oct-03 08:19
By: gvanrossum

Comment:
Reassigned to Guido so Fredrik can concentrate on SRE.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113803&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 16:20:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 08:20:32 -0700
Subject: [Python-bugs-list] [Bug #112265] Impossible to get Win32 default font encoding in Tk widgets
Message-ID: <200010031520.IAA19704@bush.i.sourceforge.net>

Bug #112265, was updated on 2000-Aug-18 13:37
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: Impossible to get Win32 default font encoding in Tk widgets

Details: I did not managed to obtain correct font encoding in widgets on Win32 (NT Workstation, Polish version, default encoding cp1250). All cp1250 Polish characters were displayed incorrectly. I think, all characters that do not belong to Latin-1 will be displayed incorrectly. Regarding Python1.6b1, I checked the Tcl/Tk installation (8.3.2). The pure Tcl/Tk programs DO display characters in cp1250 correctly.
As far as I know, the Tcl interpreter woks with UTF-8 encoded strings. Does Python1.6b1 really know about it?

Follow-Ups:

Date: 2000-Aug-26 08:04
By: effbot

Comment:
this is really a "how do I", rather than a bug
report ;-)

:::

In 1.6 and beyond, Python's default 8-bit
encoding is plain ASCII.  this encoding is only
used when you're using 8-bit strings in "unicode
contexts" -- for example, if you compare an
8-bit string to a unicode string, or pass it to
a subsystem designed to use unicode strings.

If you pass an 8-bit string containing
characters outside the ASCII range to a function
expecting a unicode string, the result is
undefined (it's usually results in an exception,
but some subsystems may have other ideas).

Finally, Tkinter now supports Unicode.  In fact,
it assumes that all strings passed to it are
Unicode.  When using 8-bit strings, it's only
safe to use plain ASCII.

Tkinter currently doesn't raise exceptions for
8-bit strings with non-ASCII characters, but it
probably should.  Otherwise, Tk will attempt to
parse the string as an UTF-8 string, and if that
fails, it assumes ISO-8859-1.

:::

Anyway, to write portable code using characters
outside the ASCII character set, you should use
unicode strings.

in your case, you can use:

   s = unicode("<a cp1250 string>", "cp1250")

to get the platform's default encoding, you can do:

   import locale
   language, encoding = locale.getdefaultlocale()

where encoding should be cp1250 on your box.

:::

The reason this work under Tcl/Tk is that Tcl
assumes that your source code uses the
platform's default encoding, and converts things
to Unicode (not necessarily UTF-8) for you under
the hood.  Python 2.1 will hopefully support
*explicit* source encodings, but 1.6/2.0
doesn't.

-------------------------------------------------------

Date: 2000-Sep-30 21:18
By: gvanrossum

Comment:
If it's a howto, should the bug report be closed?
-------------------------------------------------------

Date: 2000-Oct-03 08:20
By: gvanrossum

Comment:
Reassigned so Fredrik can concentrate on SRE.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112265&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 16:21:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 08:21:37 -0700
Subject: [Python-bugs-list] [Bug #115907] Encoding of "=" by quopri.py module
Message-ID: <200010031521.IAA11336@delerium.i.sourceforge.net>

Bug #115907, was updated on 2000-Oct-03 05:47
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Encoding of "=" by quopri.py module

Details: While making an automated mail sending engine, I used the quopri.encode(...) for my multipart mails.
quopri.encode(...) converts "=" into "==" while the mail clients expect "=3D". Thus I got some problems reading such mails with Outlook Express 5 , Netscape Messenger (Linux) and StarOffice Mail (Linux). Especially when the HTML part of the mail contains hyperkinks <a href=...>...</a> that crash Outlook express. The others make a 404 HTTP error.
I run Python 1.5.2, but this bug/feature remains perhaps with Python 1.6 and Python 2.0bx cause I didn't notice any change log to the quopri module.
I found a workaround (fix ?) by changing the "quote" function of "quopri.py" to this:
==== quopri.py ====
...
def quote(c):
## if c == ESCAPE:
##  return ESCAPE * 2
## else:
  i = ord(c)
  return ESCAPE + HEX[i/16] + HEX[i%16]
...
==== end quopri.py ====
Now, the 3 above mentioned mail clients read correctly the raw text and html parts of my mails - including hyperlinks.
Is it a bug, a feature, or did I misuse "quopri" ?

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115907&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 16:22:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 08:22:34 -0700
Subject: [Python-bugs-list] [Bug #110823] Tkinter missing button state symbols (PR#132)
Message-ID: <200010031522.IAA19762@bush.i.sourceforge.net>

Bug #110823, was updated on 2000-Aug-01 14:10
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Tkinter missing button state symbols (PR#132)

Details: Jitterbug-Id: 132
Submitted-By: aa8vb@yahoo.com
Date: Thu, 18 Nov 1999 08:16:55 -0500 (EST)
Version: 1.5.2
OS: IRIX 6.5


I have:

  picture.bind( "<ButtonPress-1>"  , click_cb )
  picture.bind( "<ButtonRelease-1>", click_cb )

In click_cb(), event.state is 0 for ButtonPress and 256 for ButtonRelease.

Where are the Tkinter constants for these?  Or how should one distinguish
between a press and release in a callback?

(I want to avoid having a separate callback for each type of event.)



====================================================================
Audit trail:
Thu Nov 18 10:42:46 1999	guido	changed notes
Thu Nov 18 10:42:46 1999	guido	moved from incoming to notabug
Thu Nov 18 14:07:59 1999	guido	changed notes
Thu Nov 18 14:07:59 1999	guido	moved from notabug to request

Follow-Ups:

Date: 2000-Aug-01 14:10
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] Tkinter missing button state symbols (PR#132)
Date: Thu, 18 Nov 1999 10:41:31 -0500

> Full_Name: Randall Hopper
> Version: 1.5.2
> OS: IRIX 6.5
> Submission from: ethyl-f.rtpfddi.epa.gov (134.67.65.11)
> 
> 
> I have:
> 
>   picture.bind( "<ButtonPress-1>"  , click_cb )
>   picture.bind( "<ButtonRelease-1>", click_cb )
> 
> In click_cb(), event.state is 0 for ButtonPress and 256 for ButtonRelease.
> 
> Where are the Tkinter constants for these?  Or how should one distinguish
> between a press and release in a callback?
> 
> (I want to avoid having a separate callback for each type of event.)

This is not a question for the bugs list.

Write to help@python.org or use the newsgroup for help.  I don't know
offhand what the answer is to your question; I suspect that the answer
is in the Tcl/Tk man page for the bind command though.

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:10
By: none

Comment:
From: Randall Hopper <Hopper.Randall@epa.gov>
Subject: Re: [Python-bugs-list] Tkinter missing button state symbols (PR#132)
Date: Thu, 18 Nov 1999 14:04:13 -0500

Guido van Rossum:
 |> Full_Name: Randall Hopper
 |> Version: 1.5.2
 |> OS: IRIX 6.5
 |> Submission from: ethyl-f.rtpfddi.epa.gov (134.67.65.11)
 |> 
 |> 
 |> I have:
 |> 
 |>   picture.bind( "<ButtonPress-1>"  , click_cb )
 |>   picture.bind( "<ButtonRelease-1>", click_cb )
 |> 
 |> In click_cb(), event.state is 0 for ButtonPress and 256 for ButtonRelease.
 |> 
 |> Where are the Tkinter constants for these?  Or how should one distinguish
 |> between a press and release in a callback?
 |> 
 |> (I want to avoid having a separate callback for each type of event.)
 |
 |This is not a question for the bugs list.
 |
 |Write to help@python.org or use the newsgroup for help.  I don't know
 |offhand what the answer is to your question; I suspect that the answer
 |is in the Tcl/Tk man page for the bind command though.

My fault.  I should have rephrased the question into a statement.  Tkinter
does not provide symbol defines for event.state values (%s keyword in Tcl).
Tcl doesn't either, but it would be useful if Tkinter did.

This is a small enhancement request rather than a hard bug, but I thought
the submission form was for probably applicable for both.

Thanks,

Randall

-------------------------------------------------------

Date: 2000-Aug-01 14:10
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] Tkinter missing button state symbols (PR#132)
Date: Thu, 18 Nov 1999 14:05:57 -0500

Yes, requests are okay.  Sorry for the confusion.

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:10
By: none

Comment:
Should add a symbol as he suggests.
-------------------------------------------------------

Date: 2000-Aug-09 02:21
By: effbot

Comment:
IIRC, these constants are platform (X library) dependent (they have to be exported from _tkinter.c, not Tkconstants.py).

I'll investigate.  Feel free to assign the bug to me if you like.

</F>
-------------------------------------------------------

Date: 2000-Aug-10 11:43
By: gvanrossum

Comment:
/F, go for it!
-------------------------------------------------------

Date: 2000-Sep-24 07:01
By: none

Comment:
LOL.I DON'T UNDERSTAND THIS SHIT BUT SOUNDS REALLY INTERESTING.WHERE CAN I LEARN HOW TO DO THIS??? SOME-ONE HELP ME!!
-------------------------------------------------------

Date: 2000-Sep-30 21:30
By: gvanrossum

Comment:
Fredrik, you promised to do this...  Do you have time?
-------------------------------------------------------

Date: 2000-Oct-03 08:22
By: gvanrossum

Comment:
I'll do this so Fredrik can do SRE.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110823&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 16:22:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 08:22:03 -0700
Subject: [Python-bugs-list] [Bug #110677] PRIVATE: various minor Tkinter things (PR#388)
Message-ID: <200010031522.IAA19753@bush.i.sourceforge.net>

Bug #110677, was updated on 2000-Jul-31 14:13
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: PRIVATE: various minor Tkinter things (PR#388)

Details: Jitterbug-Id: 388
Submitted-By: markus.oberhumer@jk.uni-linz.ac.at
Date: Wed,  5 Jul 2000 09:38:11 -0400 (EDT)
Version: python CVS
OS: all


Tkinter.Wm.wm_state() lacks a missing "newstate=None" optional parameter.

Tkinter.Text lacks some important methods: [xy]view_moveto, [xy]view_scroll

Canvas.CanvasItem & Canvas.Group:
  - bind lacks an optional "add" param
  - unbind lacks an optional "funcid" param
  - tkraise/lower should call self.canvas.tag_XXXX
  - bbox() return value is inconsistent with Canvas.bbox()



====================================================================
Audit trail:
Tue Jul 11 08:24:23 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-09 12:17
By: effbot

Comment:
the first two items are fixed.  I'll look at the Canvas.py stuff later.
-------------------------------------------------------

Date: 2000-Sep-30 21:21
By: gvanrossum

Comment:
Later being when?
-------------------------------------------------------

Date: 2000-Oct-03 08:22
By: gvanrossum

Comment:
I'll do this so Fredrik can work on SRE.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110677&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 16:23:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 08:23:42 -0700
Subject: [Python-bugs-list] [Bug #113795] IDLE 0.6 with Python 2.0b1 doesn't handle chinese characters
Message-ID: <200010031523.IAA19882@bush.i.sourceforge.net>

Bug #113795, was updated on 2000-Sep-07 06:49
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: Later
Bug Group: 3rd Party
Priority: 1
Summary: IDLE 0.6 with Python 2.0b1 doesn't handle chinese characters

Details: I just switched from 1.5.2 to 2.0b1 on W2K/Simplified Chinese version. I used to be able to input chinese characters directly into IDLE, and access violations did happen quite often. Now with 2.0b1, I can't even input chinese characters into the IDLE window anymore:IDLE automatically changed chinese characters into illegible stuff; it's the same when I copy from a text editor and paste into the IDLE window. I guess it's related to the induction of unicode support in 2.0, but is there a workaround I should know, or I should switch back to 1.5.2, or it's a bug worth fixing?

Thanks.


Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 23:13
By: tim_one

Comment:
Assigned to Fredrik, because Swedes have an uncanny intuition about how IDLE and Tk work in the presence of characters I can't get at <0.9 wink>.  Boosted the priority because it sounds like a legit practical problem.
-------------------------------------------------------

Date: 2000-Sep-20 12:47
By: loewis

Comment:
I can reproduce the problem by installing a Russion or Arabic keyboard layout on Win2k; typing into an Entry or Text widget displays Latin-1 characters. I can observe the same problem with a plain 8.3 wish, so it appears to be a bug in Tk - which apparently truncates characters on input. So I propose to close this as 3rd Party/Later, and recategorize it as Tkinter.
-------------------------------------------------------

Date: 2000-Oct-03 08:23
By: gvanrossum

Comment:
I'll take this so Fredrik can concentrate on SRE.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113795&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 16:25:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 08:25:24 -0700
Subject: [Python-bugs-list] [Bug #115919] Integer multiplication overflow
Message-ID: <200010031525.IAA11534@delerium.i.sourceforge.net>

Bug #115919, was updated on 2000-Oct-03 08:01
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Integer multiplication overflow

Details: roland@cachemir ~ $ python2.0 
Python 2.0b2 (#3, Oct  3 2000, 16:30:25) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> 1+1
2
>>> 1*1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>> 

Last CVS update 2000-10-03 around 14:00 UTC.  Last before that was some weeks ago, sorry for not being precise.  Compiled with ./configure --prefix=/usr/local/ && make, su and make install.  Only personal change is the use of readline in Modules/Setup.local.  Did I do something wrong?

Follow-Ups:

Date: 2000-Oct-03 08:25
By: jhylton

Comment:
What happens when you run "make test"?  It looks like there is something fundamentally broken, but I can't tell what it is.  If 1*1 fails, I expect the rest of the test suite to also report errors.


-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115919&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 16:27:02 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 08:27:02 -0700
Subject: [Python-bugs-list] [Bug #115844] OverflowError: integer multiplication
Message-ID: <200010031527.IAA11571@delerium.i.sourceforge.net>

Bug #115844, was updated on 2000-Oct-02 06:27
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Irreproducible
Priority: 3
Summary: OverflowError: integer multiplication

Details: 
Python2.0b2 compiled from source on a full RH7.0 install:


Python 2.0b2 (#2, Sep 27 2000, 11:40:58) 
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> a = 5 * 5
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>>

Follow-Ups:

Date: 2000-Oct-02 06:39
By: gvanrossum

Comment:
Something very basic is wrong. What output does the test suite give? ("make test"). Please see the README for digging into this.

Note that you submitted your bug report anonymously. We can't help you very effectively unless we can exchange email with you!
-------------------------------------------------------

Date: 2000-Oct-03 08:27
By: jhylton

Comment:
Strange! Another bug about integer multiplication overflow.  The other one is on a Debian install.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115844&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 16:29:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 08:29:53 -0700
Subject: [Python-bugs-list] [Bug #115844] OverflowError: integer multiplication
Message-ID: <200010031529.IAA11703@delerium.i.sourceforge.net>

Bug #115844, was updated on 2000-Oct-02 06:27
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Irreproducible
Priority: 3
Summary: OverflowError: integer multiplication

Details: 
Python2.0b2 compiled from source on a full RH7.0 install:


Python 2.0b2 (#2, Sep 27 2000, 11:40:58) 
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> a = 5 * 5
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>>

Follow-Ups:

Date: 2000-Oct-02 06:39
By: gvanrossum

Comment:
Something very basic is wrong. What output does the test suite give? ("make test"). Please see the README for digging into this.

Note that you submitted your bug report anonymously. We can't help you very effectively unless we can exchange email with you!
-------------------------------------------------------

Date: 2000-Oct-03 08:27
By: jhylton

Comment:
Strange! Another bug about integer multiplication overflow.  The other one is on a Debian install.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115844&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 16:35:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 08:35:00 -0700
Subject: [Python-bugs-list] [Bug #115625] python2.0b2 test_pty fails on x86 Solaris 8
Message-ID: <200010031535.IAA11929@delerium.i.sourceforge.net>

Bug #115625, was updated on 2000-Sep-28 16:20
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: python2.0b2 test_pty fails on x86 Solaris 8

Details: When I enable the termios module in Python 2.0b2 on x86
Solaris 8, the test_pty test fails with the following
message:

test test_pty failed -- master_fd is not a tty

I have no special interest in the termios module,
but I thought I'd report the problem since the README
file suggests enabling it if possible.  I have not tried
any other platforms so I cannot tell if the problem is
system-specific.

It would be worth checking the list of suggested Unix
modules in the README file against the Setup file, because
some files suggested in the README were already uncommented,
and others were marked as obsolete (e.g. soundex).

Follow-Ups:

Date: 2000-Sep-28 17:31
By: fdrake

Comment:
Updated the information about potentially interesting extensions in the README file, revision 1.100.

The test_pty failure remains.
-------------------------------------------------------

Date: 2000-Oct-03 08:35
By: jhylton

Comment:
I don't have Solaris (x86 or otherwise).  Can you help with this bug Thomas?

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115625&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 16:38:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 08:38:10 -0700
Subject: [Python-bugs-list] [Bug #115919] Integer multiplication overflow
Message-ID: <200010031538.IAA12027@delerium.i.sourceforge.net>

Bug #115919, was updated on 2000-Oct-03 08:01
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Integer multiplication overflow

Details: roland@cachemir ~ $ python2.0 
Python 2.0b2 (#3, Oct  3 2000, 16:30:25) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> 1+1
2
>>> 1*1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>> 

Last CVS update 2000-10-03 around 14:00 UTC.  Last before that was some weeks ago, sorry for not being precise.  Compiled with ./configure --prefix=/usr/local/ && make, su and make install.  Only personal change is the use of readline in Modules/Setup.local.  Did I do something wrong?

Follow-Ups:

Date: 2000-Oct-03 08:25
By: jhylton

Comment:
What happens when you run "make test"?  It looks like there is something fundamentally broken, but I can't tell what it is.  If 1*1 fails, I expect the rest of the test suite to also report errors.


-------------------------------------------------------

Date: 2000-Oct-03 08:38
By: lo-lan-do

Comment:
make test shows me plenty of lines looking like this one (except the name of the test changes):

test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication

I also get messages along the lines of 'test test_dbm skipped --  No module named dbm', but I guess these ones are OK.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115919&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 16:40:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 08:40:50 -0700
Subject: [Python-bugs-list] [Bug #115919] Integer multiplication overflow
Message-ID: <200010031540.IAA12206@delerium.i.sourceforge.net>

Bug #115919, was updated on 2000-Oct-03 08:01
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Integer multiplication overflow

Details: roland@cachemir ~ $ python2.0 
Python 2.0b2 (#3, Oct  3 2000, 16:30:25) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> 1+1
2
>>> 1*1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>> 

Last CVS update 2000-10-03 around 14:00 UTC.  Last before that was some weeks ago, sorry for not being precise.  Compiled with ./configure --prefix=/usr/local/ && make, su and make install.  Only personal change is the use of readline in Modules/Setup.local.  Did I do something wrong?

Follow-Ups:

Date: 2000-Oct-03 08:25
By: jhylton

Comment:
What happens when you run "make test"?  It looks like there is something fundamentally broken, but I can't tell what it is.  If 1*1 fails, I expect the rest of the test suite to also report errors.


-------------------------------------------------------

Date: 2000-Oct-03 08:38
By: lo-lan-do

Comment:
make test shows me plenty of lines looking like this one (except the name of the test changes):

test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication

I also get messages along the lines of 'test test_dbm skipped --  No module named dbm', but I guess these ones are OK.
-------------------------------------------------------

Date: 2000-Oct-03 08:40
By: jhylton

Comment:
Can you include the complete output?

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115919&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 16:45:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 08:45:44 -0700
Subject: [Python-bugs-list] [Bug #110830] "continue" inside "try" (PR#177)
Message-ID: <200010031545.IAA20782@bush.i.sourceforge.net>

Bug #110830, was updated on 2000-Aug-01 14:12
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 1
Summary: "continue" inside "try" (PR#177)

Details: Jitterbug-Id: 177
Submitted-By: simonb@logical.co.za
Date: Tue, 11 Jan 2000 05:17:37 -0500 (EST)
Version: 1-5-2
OS: NT 4.0


Hi there

I don't know if this is a bug, or is intentional behaviour for a specific
reason.

The following code produces a syntax error about the continue not being within a
looping structure rather than a prefectly silly infinite loop...

while 1:
  try:
    continue
  except:
    pass

where the following works as one would expect...

while 1:
  try:
    raise 1
  except:
    continue

I figure that there is more likely a sane reason for this behaviour than being a
bug, but I am curious.

Thanks
Simon



====================================================================
Audit trail:
Wed Jan 12 18:11:45 2000	guido	changed notes
Wed Jan 12 18:11:45 2000	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:12
By: none

Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] Syntax (PR#177)
Date: Tue, 11 Jan 2000 12:10:17 -0500

[Simon Barratt, putting "continue" in a "try" block]
> I don't know if this is a bug, or is intentional behaviour
> for a specific reason.

Actually, it's a bit of both <wink>.  See the Language Reference Manual's
section on the "continue" statement, particularly the footnote:

    The restriction on occurring in the try clause is
    implementer's laziness and will eventually be lifted.

It's been this way (and documented) forever; it's simply hard to implement
given the current structure of the interpreter loop.

Rest assured there's nothing *conceptually* wrong with putting continue in a
try!  It's simply an implementation restriction; the error msg should
probably make that clearer.  IIRC, JPython doesn't have this restriction.
"Someday" it will get repaired in CPython too.



-------------------------------------------------------

Date: 2000-Aug-01 14:12
By: none

Comment:
It's a zero-priority bug (i.e. not likely to be fixed).

-------------------------------------------------------

Date: 2000-Aug-03 13:00
By: twouters

Comment:
Like the bot said, low priority 'to be fixed' bug.

-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 09:37
By: fdrake

Comment:
Improved exception messages when 'continue' is in a 'try' block, checked in as Python/compile.c revision 2.141.  This still doesn't do the "right thing" by implementing 'continue' in this context, but makes it easier for users to understand the exception.
-------------------------------------------------------

Date: 2000-Oct-03 08:45
By: fdrake

Comment:
Added this to PEP 42; closing the bug report.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110830&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 16:59:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 08:59:01 -0700
Subject: [Python-bugs-list] [Bug #115625] python2.0b2 test_pty fails on x86 Solaris 8
Message-ID: <200010031559.IAA13055@delerium.i.sourceforge.net>

Bug #115625, was updated on 2000-Sep-28 16:20
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: python2.0b2 test_pty fails on x86 Solaris 8

Details: When I enable the termios module in Python 2.0b2 on x86
Solaris 8, the test_pty test fails with the following
message:

test test_pty failed -- master_fd is not a tty

I have no special interest in the termios module,
but I thought I'd report the problem since the README
file suggests enabling it if possible.  I have not tried
any other platforms so I cannot tell if the problem is
system-specific.

It would be worth checking the list of suggested Unix
modules in the README file against the Setup file, because
some files suggested in the README were already uncommented,
and others were marked as obsolete (e.g. soundex).

Follow-Ups:

Date: 2000-Sep-28 17:31
By: fdrake

Comment:
Updated the information about potentially interesting extensions in the README file, revision 1.100.

The test_pty failure remains.
-------------------------------------------------------

Date: 2000-Oct-03 08:35
By: jhylton

Comment:
I don't have Solaris (x86 or otherwise).  Can you help with this bug Thomas?

-------------------------------------------------------

Date: 2000-Oct-03 08:59
By: twouters

Comment:
I only have an aging, flukey, cranky old Sun box with Solaris 2.6 (and probably not properly installed at that;) but I'll give it a try. I suspect something goes wrong with the isatty test, but I'll see whether I can reproduce it on Sun hardware :P

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115625&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 17:00:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 09:00:31 -0700
Subject: [Python-bugs-list] [Bug #110681] memory leak in loops (PR#398)
Message-ID: <200010031600.JAA13086@delerium.i.sourceforge.net>

Bug #110681, was updated on 2000-Jul-31 14:14
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: memory leak in loops (PR#398)

Details: Jitterbug-Id: 398
Submitted-By: ingo.adler@synacon.ch
Date: Fri, 14 Jul 2000 05:10:25 -0400 (EDT)
Version: 1.5.2
OS: win nt


I have a simple loop, which produces memory leaks at every call (36 bytes):

{
    Py_SetProgramName("pythontest.exe");
    Py_Initialize();

    initxmodulec();

    PyRun_SimpleString("print \"... Python started ...\"");

    PyRun_SimpleString("import xmodule");
    PyRun_SimpleString("from xmodule import *");

// The Loop
    PyRun_SimpleString(
        "y = Y()\n"
        "for i in range(1000):\n"
        "\tx = y.getX()\n"
        "\tx.getNumber()\n"
    );




    PyRun_SimpleString("print \"... Python finished ...\"");
    Py_Finalize();
}

X and Y are my classes implemented in C++, connected to Python via Swig Shadow
Classes:

class X {

public:
    float getNumber()
    {
        return 12.2;
    }
};

class Y {
    X* pX;

public:
    Y()
    {
        pX = new X;
    }

    ~Y()
    {
        delete pX;
    }

    X* getX()
    {
        return pX;
    }
};

The classes and python are compiled statically with CBuilder5.0, Swig1.3a3 (same
problem with swig1.1).

I tested the application with "CodeGuard", which shows the memory leaks.
For every call in the loop there is an entry like this (I translated it to
English):

Error. 0x300010 (Thread 0x013B):
resource leak: memory block (0x15422F0) was never released

memory leak (0x015422F0) [size: 36 Byte] was assigned with malloc
call stack:
   0x0045ED5D(=pythontest.exe:0x01:05DD5D)
G:\Projects\src\fortuna\Python\Objects\stringobject.c#145
   0x00401EFD(=pythontest.exe:0x01:000EFD)
G:\Projects\src\fortuna\test\xmodule_wrap.c#769
   0x0040255D(=pythontest.exe:0x01:00155D)
G:\Projects\src\fortuna\test\xmodule_wrap.c#941
   0x0041BA79(=pythontest.exe:0x01:01AA79)
G:\Projects\src\fortuna\Python\Python\ceval.c#2359
   0x0041B912(=pythontest.exe:0x01:01A912)
G:\Projects\src\fortuna\Python\Python\ceval.c#2324
   0x0040EE3E(=pythontest.exe:0x01:00DE3E)
G:\Projects\src\fortuna\Python\Python\bltinmodule.c#12


The Code for line 941:

#define Y_getX(_swigobj)  (_swigobj->getX())
static PyObject *_wrap_Y_getX(PyObject *self, PyObject *args) {
    Y  *_arg0;
    PyObject  *_resultobj,*_argo0=0;
    X  *_result;
    self = self;
    if(!PyArg_ParseTuple(args,"O:Y_getX",&_argo0)) 
        return NULL;
    if ((SWIG_ConvertPtr(_argo0,(void **) &_arg0,SWIGTYPE_Y_p,1)) == -1) return
NULL;
    _result = (X *)Y_getX(_arg0);
/*941*/ _resultobj = SWIG_NewPointerObj((void *) _result, SWIGTYPE_X_p);
    return _resultobj;
}

The Code for line 769:

SWIGSTATICRUNTIME(PyObject *)
SWIG_NewPointerObj(void *ptr, _swig_type_info *type) {
  char result[512];
  PyObject *robj;
  if (!ptr) {
    Py_INCREF(Py_None);
    return Py_None;
  }
#ifdef SWIG_COBJECT_TYPES
  robj = PyCObject_FromVoidPtrAndDesc((void *) ptr, type->name, NULL);
#else
  SWIG_MakePtr(result,ptr,type);
/*769*/  robj = PyString_FromString(result);
#endif
  return robj;
}


Ingo Adler



====================================================================
Audit trail:
Tue Jul 25 07:27:50 2000	guido	changed notes
Tue Jul 25 07:27:50 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-01 14:01
By: none

Comment:
From: "M.-A. Lemburg" <mal@lemburg.com>
Subject: Re: [Python-bugs-list] memory leak in loops (PR#398)
Date: Fri, 14 Jul 2000 11:22:51 +0200

ingo.adler@synacon.ch wrote:
> 
> Full_Name: ingo adler
> Version: 1.5.2
> OS: win nt
> Submission from: megazh-d-201.agrinet.ch (212.28.158.201)
> 
> I have a simple loop, which produces memory leaks at every call (36 bytes):
> 
> {
>     Py_SetProgramName("pythontest.exe");
>     Py_Initialize();
> 
>     initxmodulec();
> 
>     PyRun_SimpleString("print \"... Python started ...\"");
> 
>     PyRun_SimpleString("import xmodule");
>     PyRun_SimpleString("from xmodule import *");
> 
> // The Loop
>     PyRun_SimpleString(
>         "y = Y()\n"
>         "for i in range(1000):\n"
>         "\tx = y.getX()\n"
>         "\tx.getNumber()\n"

Could be that SWIG doesn't get a chance to cleanup the shadow
object for x and y. Try adding

del x,y

as final script line.

Note that SWIG uses Python strings to represent pointers in
C++. It uses an internal table to store these.

>     );
> 
>     PyRun_SimpleString("print \"... Python finished ...\"");
>     Py_Finalize();
> }
> 
> X and Y are my classes implemented in C++, connected to Python via Swig Shadow
> Classes:
> 
> class X {
> 
> public:
>     float getNumber()
>     {
>         return 12.2;
>     }
> };
> 
> class Y {
>     X* pX;
> 
> public:
>     Y()
>     {
>         pX = new X;
>     }
> 
>     ~Y()
>     {
>         delete pX;
>     }
> 
>     X* getX()
>     {
>         return pX;
>     }
> };
> 
> The classes and python are compiled statically with CBuilder5.0, Swig1.3a3 (same
> problem with swig1.1).
> 
> I tested the application with "CodeGuard", which shows the memory leaks.
> For every call in the loop there is an entry like this (I translated it to
> English):
> 
> Error. 0x300010 (Thread 0x013B):
> resource leak: memory block (0x15422F0) was never released
> 
> memory leak (0x015422F0) [size: 36 Byte] was assigned with malloc
> call stack:
>    0x0045ED5D(=pythontest.exe:0x01:05DD5D)
> G:\Projects\src\fortuna\Python\Objects\stringobject.c#145
>    0x00401EFD(=pythontest.exe:0x01:000EFD)
> G:\Projects\src\fortuna\test\xmodule_wrap.c#769
>    0x0040255D(=pythontest.exe:0x01:00155D)
> G:\Projects\src\fortuna\test\xmodule_wrap.c#941
>    0x0041BA79(=pythontest.exe:0x01:01AA79)
> G:\Projects\src\fortuna\Python\Python\ceval.c#2359
>    0x0041B912(=pythontest.exe:0x01:01A912)
> G:\Projects\src\fortuna\Python\Python\ceval.c#2324
>    0x0040EE3E(=pythontest.exe:0x01:00DE3E)
> G:\Projects\src\fortuna\Python\Python\bltinmodule.c#12
> 
> The Code for line 941:
> 
> #define Y_getX(_swigobj)  (_swigobj->getX())
> static PyObject *_wrap_Y_getX(PyObject *self, PyObject *args) {
>     Y  *_arg0;
>     PyObject  *_resultobj,*_argo0=0;
>     X  *_result;
>     self = self;
>     if(!PyArg_ParseTuple(args,"O:Y_getX",&_argo0))
>         return NULL;
>     if ((SWIG_ConvertPtr(_argo0,(void **) &_arg0,SWIGTYPE_Y_p,1)) == -1) return
> NULL;
>     _result = (X *)Y_getX(_arg0);
> /*941*/ _resultobj = SWIG_NewPointerObj((void *) _result, SWIGTYPE_X_p);
>     return _resultobj;
> }
> 
> The Code for line 769:
> 
> SWIGSTATICRUNTIME(PyObject *)
> SWIG_NewPointerObj(void *ptr, _swig_type_info *type) {
>   char result[512];
>   PyObject *robj;
>   if (!ptr) {
>     Py_INCREF(Py_None);
>     return Py_None;
>   }
> #ifdef SWIG_COBJECT_TYPES
>   robj = PyCObject_FromVoidPtrAndDesc((void *) ptr, type->name, NULL);
> #else
>   SWIG_MakePtr(result,ptr,type);
> /*769*/  robj = PyString_FromString(result);
> #endif
>   return robj;
> }
> 
> Ingo Adler
> 
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Ingo Adler <ingo.adler@synacon.ch>
Subject: Re: [Python-bugs-list] memory leak in loops (PR#398)
Date: Fri, 14 Jul 2000 11:40:42 +0100

This is a multi-part message in MIME format.
--------------6D29988B97CCE77010389AE2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> > // The Loop
> >     PyRun_SimpleString(
> >         "y = Y()\n"
> >         "for i in range(1000):\n"
> >         "\tx = y.getX()\n"
> >         "\tx.getNumber()\n"
>
> Could be that SWIG doesn't get a chance to cleanup the shadow
> object for x and y. Try adding
>
> del x,y
>
> as final script line.
>
> Note that SWIG uses Python strings to represent pointers in
> C++. It uses an internal table to store these.
>

I changed the code to:

    PyRun_SimpleString(
        "y = Y()\n"
        "for i in range(1000):\n"
        "\tx = y.getX()\n"
        "\tx.getNumber()\n"
        "\tdel x\n"
    );

It doesn't change anything.

The memory leak only occurs when I call x.getNumber() in the loop. Otherwise x =
y.getX() is memory leak free.

Ingo Adler

--------------6D29988B97CCE77010389AE2
Content-Type: text/x-vcard; charset=us-ascii;
 name="ingo.adler.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ingo Adler
Content-Disposition: attachment;
 filename="ingo.adler.vcf"

begin:vcard 
n:Adler;Ingo
tel;cell:+41-79-3786792
tel;fax:+41-41-7103244
tel;home:+41-41-7103268
tel;work:+41-41-8111500
x-mozilla-html:FALSE
url:www.synacon.ch
org:Synacon GmbH
adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland
version:2.1
email;internet:ingo.adler@synacon.ch
title:Dipl.-Inform.
fn:Ingo Adler
end:vcard

--------------6D29988B97CCE77010389AE2--



-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: "M.-A. Lemburg" <mal@lemburg.com>
Subject: Re: [Python-bugs-list] memory leak in loops (PR#398)
Date: Fri, 14 Jul 2000 12:13:13 +0200

Ingo Adler wrote:
> 
> > > // The Loop
> > >     PyRun_SimpleString(
> > >         "y = Y()\n"
> > >         "for i in range(1000):\n"
> > >         "\tx = y.getX()\n"
> > >         "\tx.getNumber()\n"
> >
> > Could be that SWIG doesn't get a chance to cleanup the shadow
> > object for x and y. Try adding
> >
> > del x,y
> >
> > as final script line.
> >
> > Note that SWIG uses Python strings to represent pointers in
> > C++. It uses an internal table to store these.
> >
> 
> I changed the code to:
> 
>     PyRun_SimpleString(
>         "y = Y()\n"
>         "for i in range(1000):\n"
>         "\tx = y.getX()\n"
>         "\tx.getNumber()\n"
>         "\tdel x\n"
>     );
> 
> It doesn't change anything.
> 
> The memory leak only occurs when I call x.getNumber() in the loop. Otherwise x =
> y.getX() is memory leak free.

Two other possibilities:

1. Python interns the string object used by SWIG to represent
the point. It should then free the memory in the Py_Finalize()
call. If it doesn't, there's a bug to be found ;-)

2. SWIG has the leak. Try using the alternative method of
defining SWIG_COBJECT_TYPES (don't know how this is done --
it seems to be new in SWIG).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Ingo Adler <ingo.adler@synacon.ch>
Subject: Re: [Python-bugs-list] memory leak in loops (PR#398)
Date: Fri, 14 Jul 2000 12:45:02 +0100

This is a multi-part message in MIME format.
--------------82393A6779ADCFC3A2ADE19E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I could reproduce the problem with Developer Studio 6.0.

If anyone wants the project to test it - I can provide it.

Ingo Adler

--------------82393A6779ADCFC3A2ADE19E
Content-Type: text/x-vcard; charset=us-ascii;
 name="ingo.adler.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ingo Adler
Content-Disposition: attachment;
 filename="ingo.adler.vcf"

begin:vcard 
n:Adler;Ingo
tel;cell:+41-79-3786792
tel;fax:+41-41-7103244
tel;home:+41-41-7103268
tel;work:+41-41-8111500
x-mozilla-html:FALSE
url:www.synacon.ch
org:Synacon GmbH
adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland
version:2.1
email;internet:ingo.adler@synacon.ch
title:Dipl.-Inform.
fn:Ingo Adler
end:vcard

--------------82393A6779ADCFC3A2ADE19E--



-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: "Mark Hammond" <mhammond@skippinet.com.au>
Subject: RE: [Python-bugs-list] memory leak in loops (PR#398)
Date: Mon, 17 Jul 2000 22:16:54 -0400

> I could reproduce the problem with Developer Studio 6.0.
>
> If anyone wants the project to test it - I can provide it.

If you can repro the problem in just a few lines of C/C++ code but with no
SWIG generated code, I would be interested.  Otherwise, I suggest you do
some more work to narrow the problem down some more; as described, there is
still too much work to be done to narrow down the problem to the cause for
me to be interested (or anyone else given the feedback to date!)

Mark.



-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Ingo Adler <ingo.adler@synacon.ch>
Subject: Re: [Python-bugs-list] memory leak in loops (PR#398)
Date: Tue, 25 Jul 2000 01:34:22 +0200

This is a multi-part message in MIME format.
--------------72A23DA082087CB843E12C92
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Mark,

I could repro the memory leaks (they seem to be the same) with a much smaller
program:

int main(int argc, char* argv[])
{
    Py_SetProgramName("pythontest.exe");
    Py_Initialize();
    PyRun_SimpleString("print \"... Python started ...\"");
    PyRun_SimpleString("print \"... Python finished ...\"");
    Py_Finalize();

    return 0;
}

There seems to be a more general problem, which includes my special problem.

Output of Code Guard (translated to English). BoundsChecker shows the same
leaks.

Ingo

Output:

Memory Block (0x014EB9B4) [Size: 37 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043515A(=pythontest.exe:0x01:03415A)
D:\projects\Python\Objects\stringobject.c#95
   0x0043A8EB(=pythontest.exe:0x01:0398EB)
D:\projects\Python\Python\marshal.c#483
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504
   0x0043AB88(=pythontest.exe:0x01:039B88)
D:\projects\Python\Python\marshal.c#568
   0x0043AD37(=pythontest.exe:0x01:039D37)
D:\projects\Python\Python\marshal.c#624
   0x0042BC54(=pythontest.exe:0x01:02AC54)
D:\projects\Python\Python\import.c#575

------------------------------------------
Error 00078. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E4858) was never freed

Memory Block (0x014E4858) [Size: 31 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00425400(=pythontest.exe:0x01:024400)
D:\projects\Python\Objects\dictobject.c#1084
   0x00433896(=pythontest.exe:0x01:032896)
D:\projects\Python\Objects\moduleobject.c#56
   0x0042B993(=pythontest.exe:0x01:02A993)
D:\projects\Python\Python\import.c#428
   0x0043B0C9(=pythontest.exe:0x01:03A0C9)
D:\projects\Python\Python\modsupport.c#82
   0x0040C68A(=pythontest.exe:0x01:00B68A)
D:\projects\Python\Python\bltinmodule.c#2393

------------------------------------------
Error 00079. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E47D0) was never freed

Memory Block (0x014E47D0) [Size: 28 Byte] was assigned with malloc
Aufrufhierarchie:
   0x00433CB3(=pythontest.exe:0x01:032CB3)
D:\projects\Python\Objects\object.c#122
   0x00424115(=pythontest.exe:0x01:023115)
D:\projects\Python\Objects\dictobject.c#124
   0x004367D3(=pythontest.exe:0x01:0357D3)
D:\projects\Python\Objects\stringobject.c#1075
   0x00425418(=pythontest.exe:0x01:024418)
D:\projects\Python\Objects\dictobject.c#1087
   0x0043387A(=pythontest.exe:0x01:03287A)
D:\projects\Python\Objects\moduleobject.c#54
   0x0042B993(=pythontest.exe:0x01:02A993)
D:\projects\Python\Python\import.c#428

------------------------------------------
Error 00080. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E47AC) was never freed

Memory Block (0x014E47AC) [Size: 32 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00425400(=pythontest.exe:0x01:024400)
D:\projects\Python\Objects\dictobject.c#1084
   0x0043387A(=pythontest.exe:0x01:03287A)
D:\projects\Python\Objects\moduleobject.c#54
   0x0042B993(=pythontest.exe:0x01:02A993)
D:\projects\Python\Python\import.c#428
   0x0043B0C9(=pythontest.exe:0x01:03A0C9)
D:\projects\Python\Python\modsupport.c#82
   0x0040C68A(=pythontest.exe:0x01:00B68A)
D:\projects\Python\Python\bltinmodule.c#2393

------------------------------------------
Error 00081. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E46E4) was never freed

Memory Block (0x014E46E4) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x004240F7(=pythontest.exe:0x01:0230F7)
D:\projects\Python\Objects\dictobject.c#120
   0x0043C27B(=pythontest.exe:0x01:03B27B)
D:\projects\Python\Python\pythonrun.c#132
   0x00402934(=pythontest.exe:0x01:001934)
G:\Projects\src\test\pythonmain.cpp#15
   0x3257DC12(=CC3250MT.DLL:0x01:07CC12)

------------------------------------------
Error 00082. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x1524000) was never freed

Memory Block (0x01524000) [Size: 12288 Byte] was assigned with malloc
Aufrufhierarchie:
   0x004243A7(=pythontest.exe:0x01:0233A7)
D:\projects\Python\Objects\dictobject.c#280
   0x004245C4(=pythontest.exe:0x01:0235C4)
D:\projects\Python\Objects\dictobject.c#370
   0x00436837(=pythontest.exe:0x01:035837)
D:\projects\Python\Objects\stringobject.c#1086
   0x00415CA9(=pythontest.exe:0x01:014CA9)
D:\projects\Python\Python\compile.c#249
   0x0043AC12(=pythontest.exe:0x01:039C12)
D:\projects\Python\Python\marshal.c#578
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504

------------------------------------------
Error 00083. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFC9C) was never freed

Memory Block (0x014EFC9C) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411EE6(=pythontest.exe:0x01:010EE6)
D:\projects\Python\Objects\classobject.c#126
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00084. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFC74) was never freed

Memory Block (0x014EFC74) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411ED6(=pythontest.exe:0x01:010ED6)
D:\projects\Python\Objects\classobject.c#125
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00085. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFC4C) was never freed

Memory Block (0x014EFC4C) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411EC6(=pythontest.exe:0x01:010EC6)
D:\projects\Python\Objects\classobject.c#124
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00086. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14F19CC) was never freed

Memory Block (0x014F19CC) [Size: 47 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00431E97(=pythontest.exe:0x01:030E97)
D:\projects\Python\Objects\listobject.c#309
   0x0041137E(=pythontest.exe:0x01:01037E)
D:\projects\Python\Python\ceval.c#2512
   0x0040F906(=pythontest.exe:0x01:00E906)
D:\projects\Python\Python\ceval.c#1503
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324
   0x0042BAD4(=pythontest.exe:0x01:02AAD4)
D:\projects\Python\Python\import.c#485

------------------------------------------
Error 00087. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14F596C) was never freed

Memory Block (0x014F596C) [Size: 32 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x0042CED6(=pythontest.exe:0x01:02BED6)
D:\projects\Python\Python\import.c#1513
   0x0042CD19(=pythontest.exe:0x01:02BD19)
D:\projects\Python\Python\import.c#1441
   0x0042CE6A(=pythontest.exe:0x01:02BE6A)
D:\projects\Python\Python\import.c#1489
   0x00409B32(=pythontest.exe:0x01:008B32)
D:\projects\Python\Python\bltinmodule.c#65

------------------------------------------
Error 00088. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EB870) was never freed

Memory Block (0x014EB870) [Size: 32 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043515A(=pythontest.exe:0x01:03415A)
D:\projects\Python\Objects\stringobject.c#95
   0x0043A8EB(=pythontest.exe:0x01:0398EB)
D:\projects\Python\Python\marshal.c#483
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504
   0x0043AB88(=pythontest.exe:0x01:039B88)
D:\projects\Python\Python\marshal.c#568
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504
   0x0043AB76(=pythontest.exe:0x01:039B76)
D:\projects\Python\Python\marshal.c#567

------------------------------------------
Error 00089. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFBDC) was never freed

Memory Block (0x014EFBDC) [Size: 34 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411C9E(=pythontest.exe:0x01:010C9E)
D:\projects\Python\Objects\classobject.c#58
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00090. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E74C4) was never freed

Memory Block (0x014E74C4) [Size: 988 Byte] was assigned with malloc
Aufrufhierarchie:
   0x00430B62(=pythontest.exe:0x01:02FB62)
D:\projects\Python\Objects\intobject.c#113
   0x00430BFD(=pythontest.exe:0x01:02FBFD)
D:\projects\Python\Objects\intobject.c#163
   0x0040C6FC(=pythontest.exe:0x01:00B6FC)
D:\projects\Python\Python\bltinmodule.c#2404
   0x0043C29A(=pythontest.exe:0x01:03B29A)
D:\projects\Python\Python\pythonrun.c#136
   0x00402934(=pythontest.exe:0x01:001934)
G:\Projects\src\test\pythonmain.cpp#15
   0x3257DC12(=CC3250MT.DLL:0x01:07CC12)

------------------------------------------
Error 00091. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E96C4) was never freed

Memory Block (0x014E96C4) [Size: 174 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0042B0D9(=pythontest.exe:0x01:02A0D9) D:\projects\Python\PC\getpathp.c#403

   0x0042B2D5(=pythontest.exe:0x01:02A2D5) D:\projects\Python\PC\getpathp.c#508

   0x0043E40C(=pythontest.exe:0x01:03D40C)
D:\projects\Python\Python\sysmodule.c#413
   0x0043C2CA(=pythontest.exe:0x01:03B2CA)
D:\projects\Python\Python\pythonrun.c#142
   0x00402934(=pythontest.exe:0x01:001934)
G:\Projects\src\test\pythonmain.cpp#15
   0x3257DC12(=CC3250MT.DLL:0x01:07CC12)

------------------------------------------
Error 00092. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EF660) was never freed

Memory Block (0x014EF660) [Size: 36 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00425400(=pythontest.exe:0x01:024400)
D:\projects\Python\Objects\dictobject.c#1084
   0x0042BA54(=pythontest.exe:0x01:02AA54)
D:\projects\Python\Python\import.c#466
   0x0042BF73(=pythontest.exe:0x01:02AF73)
D:\projects\Python\Python\import.c#724
   0x0042C876(=pythontest.exe:0x01:02B876)
D:\projects\Python\Python\import.c#1202
   0x0042D51E(=pythontest.exe:0x01:02C51E)
D:\projects\Python\Python\import.c#1755

------------------------------------------
Error 00093. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x15211C8) was never freed

Memory Block (0x015211C8) [Size: 31 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x004129EE(=pythontest.exe:0x01:0119EE)
D:\projects\Python\Objects\classobject.c#517
   0x004246DD(=pythontest.exe:0x01:0236DD)
D:\projects\Python\Objects\dictobject.c#419
   0x0042546E(=pythontest.exe:0x01:02446E)
D:\projects\Python\Objects\dictobject.c#1103
   0x0043DF2E(=pythontest.exe:0x01:03CF2E)
D:\projects\Python\Python\sysmodule.c#95

------------------------------------------
Aufgerufene Funktionen:
 delete (35 Mal)
 getchar (1 Mal)
 fflush (2 Mal)
 fputs (2 Mal)
 fwrite (2 Mal)
 vsprintf (2 Mal)
 strrchr (14 Mal)
 fclose (14 Mal)
 strspn (251 Mal)
 fread (2021 Mal)
 _fgetc (40 Mal)
 fstat (7 Mal)
 fopen (72 Mal)
 strncmp (19 Mal)
 strcmp (423 Mal)
 stat (21 Mal)
 strncpy (32 Mal)
 strchr (125 Mal)
 sprintf (2 Mal)
 memcmp (1349 Mal)
 memset (133 Mal)
 strcpy (834 Mal)
 strlen (784 Mal)
 SysFreeMem (87 Mal)
 SysGetMem (87 Mal)
 realloc (88 Mal)
 memcpy (837 Mal)
 delete[] (2 Mal)
 free (4936 Mal)
 new[] (14 Mal)
 new (40 Mal)
 calloc (5 Mal)
 malloc (4946 Mal)
Verwendete Resource-Arten:
 Datei-Stream (14 Allocs, 5 max)
 Datei-Handle (14 Allocs, 5 max)
 Objekt-Array (14 Allocs, 13 max)
 Objekt (40 Allocs, 28 max)
 Memory Block (5039 Allocs, 2448 max)
Verwendete Module:
 00400000 07/25/2000 01:06:08 G:\Projects\src\bin\pythontest.exe
 0CD00000 02/03/2000 06:00:00 g:\programme\borland\cbuilder5\bin\CG32.DLL
 201A0000 02/22/2000 05:20:00 C:\WINNT.45\TRAYHOOK.dll
 32500000 02/03/2000 06:00:00 G:\Projects\src\bin\CC3250MT.DLL
 40000000 02/03/2000 05:01:00 C:\WINNT.45\System32\VCL50.BPL
 41000000 02/03/2000 06:00:00 G:\Projects\src\bin\BORLNDMM.DLL
 52180000 08/09/1996 00:00:00 C:\WINNT.45\system32\version.dll
 61220000 12/07/1999 16:03:46 G:\Programme\Microsoft
 Hardware\Mouse\MSH_ZWF.dll
 65340000 02/18/2000 16:16:02 C:\WINNT.45\system32\oleaut32.dll
 70970000 05/09/1998 13:57:06 C:\WINNT.45\system32\SHELL32.dll
 70BD0000 03/18/1999 00:00:00 C:\WINNT.45\system32\SHLWAPI.dll
 71190000 07/22/1999 21:09:08 C:\WINNT.45\system32\MSIDLE.DLL
 71590000 03/18/1999 00:00:00 C:\WINNT.45\system32\COMCTL32.dll
 73060000 05/13/1999 12:05:00 C:\WINNT.45\System32\winspool.drv
 77660000 05/13/1999 12:05:00 C:\WINNT.45\System32\MSWSOCK.dll
 77666C35 05/13/1999 12:05:00 C:\WINNT.45\system32\wsock32.dll
 77690000 05/13/1999 12:05:00 C:\WINNT.45\system32\WS2HELP.dll
 776A0000 05/13/1999 12:05:00 C:\WINNT.45\system32\WS2_32.dll
 77710000 05/13/1999 12:05:00 C:\WINNT.45\system32\mpr.dll
 77920000 05/13/1999 12:05:00 C:\WINNT.45\System32\oledlg.dll
 779B0000 08/09/1996 00:00:00 C:\WINNT.45\system32\LZ32.dll
 77B80000 05/13/1999 12:05:00 C:\WINNT.45\system32\ole32.dll
 77D80000 05/13/1999 12:05:00 C:\WINNT.45\system32\comdlg32.dll
 77DC0000 05/13/1999 12:05:00 C:\WINNT.45\system32\ADVAPI32.dll
 77E10000 05/13/1999 12:05:00 C:\WINNT.45\system32\RPCRT4.dll
 77E70000 05/13/1999 12:05:00 C:\WINNT.45\system32\user32.dll
 77ED0000 05/13/1999 12:05:00 C:\WINNT.45\system32\GDI32.dll
 77F00000 05/13/1999 12:05:00 C:\WINNT.45\system32\kernel32.dll
 77F70000 05/13/1999 12:05:00 C:\WINNT.45\System32\ntdll.dll
 78000000 12/07/1999 05:00:00 C:\WINNT.45\system32\MSVCRT.dll
==========================================



Mark Hammond wrote:

> > I could reproduce the problem with Developer Studio 6.0.
> >
> > If anyone wants the project to test it - I can provide it.
>
> If you can repro the problem in just a few lines of C/C++ code but with no
> SWIG generated code, I would be interested.  Otherwise, I suggest you do
> some more work to narrow the problem down some more; as described, there is
> still too much work to be done to narrow down the problem to the cause for
> me to be interested (or anyone else given the feedback to date!)
>
> Mark.

--------------72A23DA082087CB843E12C92
Content-Type: text/x-vcard; charset=us-ascii;
 name="ingo.adler.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ingo Adler
Content-Disposition: attachment;
 filename="ingo.adler.vcf"

begin:vcard 
n:Adler;Ingo
tel;fax:+41-41-7103244
tel;work:+41-41-8111500
x-mozilla-html:FALSE
org:Synacon GmbH
adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland
version:2.1
email;internet:ingo.adler@synacon.ch
fn:Ingo Adler
end:vcard

--------------72A23DA082087CB843E12C92--



-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
Actually, it's hard to say whether this is worth fixing...
Could it be a SWIG problem?
-------------------------------------------------------

Date: 2000-Sep-25 12:54
By: bwarsaw

Comment:
I don't believe there is a Python bug worth fixing here.  I've done some memory use testing with Python 2.0b2 using Insure++ on Linux, both with the regular interpreter, and with the small example embedded script given below.

There are "technical" memory leaks but they are almost all related to either leaks in the OS, or global memory still in use at the time Python exits.  An example of the former is leaks in strerror() - nothing we can do about that.  An example of the latter are leaks in the string intern dictionary, and we've already decided not to do anything about that.

There no identifiable chunks of memory leaked every time through the loop so I believe the problems reported below are either related to swig, have been fixed for Python 2.0, or are of the variety described above.
-------------------------------------------------------

Date: 2000-Oct-03 07:52
By: tregnago

Comment:
I'm working on an embedded application. I've looked with CodeGuard and it detect few memory leaks( similar as reported below ) only executing "Py_Initialize()" immediatly followed by "Py_Finalize()". Are you sure that this basic example is leaks free in your case?
I'm in big problems with that, and I can't find a way to escape from that.
-------------------------------------------------------

Date: 2000-Oct-03 09:00
By: bwarsaw

Comment:
Re-opening since there really are memory leaks we can fix.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110681&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 17:01:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 09:01:54 -0700
Subject: [Python-bugs-list] [Bug #115618] SRE lookbehind raises a RuntimeError
Message-ID: <200010031601.JAA13114@delerium.i.sourceforge.net>

Bug #115618, was updated on 2000-Sep-28 14:47
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: SRE lookbehind raises a RuntimeError

Details: Test program:

import re
p=re.compile('(?<!abc)(def)')
p.search('abcddef')    

This raises an exception in the search():
RuntimeError: internal error in regular expression engine                       


Follow-Ups:

Date: 2000-Sep-30 21:40
By: gvanrossum

Comment:
Confirmed in 2.0b2 on Linux (Red Hat 6.2).
-------------------------------------------------------

Date: 2000-Oct-03 09:01
By: effbot

Comment:
The assert_not primitive contained a bogus assertion.
Fixed in 2.0rc1.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115618&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 17:02:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 09:02:21 -0700
Subject: [Python-bugs-list] [Bug #115919] Integer multiplication overflow
Message-ID: <200010031602.JAA13139@delerium.i.sourceforge.net>

Bug #115919, was updated on 2000-Oct-03 08:01
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Integer multiplication overflow

Details: roland@cachemir ~ $ python2.0 
Python 2.0b2 (#3, Oct  3 2000, 16:30:25) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> 1+1
2
>>> 1*1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>> 

Last CVS update 2000-10-03 around 14:00 UTC.  Last before that was some weeks ago, sorry for not being precise.  Compiled with ./configure --prefix=/usr/local/ && make, su and make install.  Only personal change is the use of readline in Modules/Setup.local.  Did I do something wrong?

Follow-Ups:

Date: 2000-Oct-03 08:25
By: jhylton

Comment:
What happens when you run "make test"?  It looks like there is something fundamentally broken, but I can't tell what it is.  If 1*1 fails, I expect the rest of the test suite to also report errors.


-------------------------------------------------------

Date: 2000-Oct-03 08:38
By: lo-lan-do

Comment:
make test shows me plenty of lines looking like this one (except the name of the test changes):

test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication

I also get messages along the lines of 'test test_dbm skipped --  No module named dbm', but I guess these ones are OK.
-------------------------------------------------------

Date: 2000-Oct-03 08:40
By: jhylton

Comment:
Can you include the complete output?

-------------------------------------------------------

Date: 2000-Oct-03 09:02
By: lo-lan-do

Comment:
[In case the bug would be caused by a recent upgrade to a beta glibc, I tried the '1*1' test with Python 1.5.2.  No bug visible there.]

$ make distclean && ./configure --prefix=/usr/local/ && make
$ make test &> test.log

It seems that 'make test' somehow hangs when testing threads, so I cut at that point.  I hope the relevant info is shown before that point.
Here goes...

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Unhandled exception in thread:
test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication
test_opcodes
test_operations
test_builtin
test test_builtin crashed -- exceptions.OverflowError: integer multiplication
test_exceptions
test_types
test test_types crashed -- exceptions.OverflowError: integer multiplication
test_MimeWriter
test_StringIO
test_al
test test_al skipped --  No module named al
test_array
test test_array crashed -- exceptions.OverflowError: integer multiplication
test_atexit
test_audioop
test test_audioop skipped --  No module named audioop
test_augassign
test test_augassign crashed -- exceptions.OverflowError: integer multiplication
test_binascii
test_binhex
test test_binhex crashed -- exceptions.OverflowError: integer multiplication
test_bsddb
test_cd
test test_cd skipped --  No module named cd
test_cfgparser
test test_cfgparser crashed -- exceptions.OverflowError: integer multiplication
test_cgi
test test_cgi crashed -- exceptions.OverflowError: integer multiplication
test_cl
test test_cl skipped --  No module named cl
test_class
test_cmath
test_compile
test_contains
test_cookie
test test_cookie crashed -- exceptions.OverflowError: integer multiplication
test_cpickle
test_crypt
test test_crypt skipped --  No module named crypt
test_dbm
test test_dbm skipped --  No module named dbm
test_dl
test test_dl skipped --  No module named dl
test_dospath
test_errno
test_extcall
test_fcntl
test_file
test_fork1
test_format
test_gc
test_gdbm
test test_gdbm skipped --  No module named gdbm
test_getopt
test_gettext
test test_gettext crashed -- exceptions.OverflowError: integer multiplication
test_gl
test test_gl skipped --  No module named gl
test_grp
test_gzip
test test_gzip skipped --  No module named zlib
test_hash
test_imageop
test test_imageop skipped --  No module named imageop
test_imgfile
test test_imgfile skipped --  No module named imgfile
test_largefile
test test_largefile skipped --  platform does not have largefile support
test_linuxaudiodev
test test_linuxaudiodev skipped --  No module named linuxaudiodev
test_long
test test_long crashed -- exceptions.OverflowError: integer multiplication
test_longexp
test_math
test_md5
test_mimetools
test test_mimetools crashed -- exceptions.AttributeError: encode
test_minidom
test test_minidom skipped --  No module named pyexpat
test_mmap
test test_mmap crashed -- exceptions.OverflowError: integer multiplication
test_new
test_nis
test test_nis skipped --  No module named nis
test_ntpath
test_openpty
test_operator
test test_operator failed -- Writing: 'mul(5, 2) = <class exceptions.OverflowError at 0x818f41c>: 10 expected', expected: 'testing:
 neg\012testing: or_\012testing: pos\012testing: repeat\012testing: rshift'
test_parser
test_pickle
test_pkg
test_poll
test test_poll crashed -- exceptions.OverflowError: integer multiplication
test_popen2
test_posixpath
test_pow
test test_pow crashed -- exceptions.OverflowError: integer multiplication
test_pty
test test_pty skipped --  No module named termios
test_pwd
test_pyexpat
test test_pyexpat skipped --  cannot import name expat
test_re
test test_re crashed -- exceptions.OverflowError: integer multiplication
test_regex
test_rfc822
test test_rfc822 crashed -- exceptions.OverflowError: integer multiplication
test_rgbimg
test test_rgbimg skipped --  No module named rgbimg
test_rotor
test_sax
test test_sax skipped --  cannot import name expat
test_select
test_sha
test_signal
test_socket
test_sre
test test_sre failed -- Writing: "sre.match(r'(a)|(b)', 'b').start(1)", expected: ''
test_strftime
test test_strftime crashed -- exceptions.OverflowError: integer multiplication
test_string
test_strop
test_struct
test test_struct crashed -- exceptions.OverflowError: integer multiplication
test_sunaudiodev
test test_sunaudiodev skipped --  No module named sunaudiodev
test_thread
Traceback (most recent call last):
  File "./Lib/test/test_thread.py", line 21, in task
    delay = random.random() * numtasks
  File "/home/roland/perso/src/sourceforge/python/dist/src/Lib/whrandom.py", line 71, in random
    x = (171 * x) % 30269
OverflowError: integer multiplication

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115919&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 17:03:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 09:03:45 -0700
Subject: [Python-bugs-list] [Bug #115919] Integer multiplication overflow
Message-ID: <200010031603.JAA13269@delerium.i.sourceforge.net>

Bug #115919, was updated on 2000-Oct-03 08:01
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Integer multiplication overflow

Details: roland@cachemir ~ $ python2.0 
Python 2.0b2 (#3, Oct  3 2000, 16:30:25) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> 1+1
2
>>> 1*1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>> 

Last CVS update 2000-10-03 around 14:00 UTC.  Last before that was some weeks ago, sorry for not being precise.  Compiled with ./configure --prefix=/usr/local/ && make, su and make install.  Only personal change is the use of readline in Modules/Setup.local.  Did I do something wrong?

Follow-Ups:

Date: 2000-Oct-03 08:25
By: jhylton

Comment:
What happens when you run "make test"?  It looks like there is something fundamentally broken, but I can't tell what it is.  If 1*1 fails, I expect the rest of the test suite to also report errors.


-------------------------------------------------------

Date: 2000-Oct-03 08:38
By: lo-lan-do

Comment:
make test shows me plenty of lines looking like this one (except the name of the test changes):

test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication

I also get messages along the lines of 'test test_dbm skipped --  No module named dbm', but I guess these ones are OK.
-------------------------------------------------------

Date: 2000-Oct-03 08:40
By: jhylton

Comment:
Can you include the complete output?

-------------------------------------------------------

Date: 2000-Oct-03 09:02
By: lo-lan-do

Comment:
[In case the bug would be caused by a recent upgrade to a beta glibc, I tried the '1*1' test with Python 1.5.2.  No bug visible there.]

$ make distclean && ./configure --prefix=/usr/local/ && make
$ make test &> test.log

It seems that 'make test' somehow hangs when testing threads, so I cut at that point.  I hope the relevant info is shown before that point.
Here goes...

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Unhandled exception in thread:
test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication
test_opcodes
test_operations
test_builtin
test test_builtin crashed -- exceptions.OverflowError: integer multiplication
test_exceptions
test_types
test test_types crashed -- exceptions.OverflowError: integer multiplication
test_MimeWriter
test_StringIO
test_al
test test_al skipped --  No module named al
test_array
test test_array crashed -- exceptions.OverflowError: integer multiplication
test_atexit
test_audioop
test test_audioop skipped --  No module named audioop
test_augassign
test test_augassign crashed -- exceptions.OverflowError: integer multiplication
test_binascii
test_binhex
test test_binhex crashed -- exceptions.OverflowError: integer multiplication
test_bsddb
test_cd
test test_cd skipped --  No module named cd
test_cfgparser
test test_cfgparser crashed -- exceptions.OverflowError: integer multiplication
test_cgi
test test_cgi crashed -- exceptions.OverflowError: integer multiplication
test_cl
test test_cl skipped --  No module named cl
test_class
test_cmath
test_compile
test_contains
test_cookie
test test_cookie crashed -- exceptions.OverflowError: integer multiplication
test_cpickle
test_crypt
test test_crypt skipped --  No module named crypt
test_dbm
test test_dbm skipped --  No module named dbm
test_dl
test test_dl skipped --  No module named dl
test_dospath
test_errno
test_extcall
test_fcntl
test_file
test_fork1
test_format
test_gc
test_gdbm
test test_gdbm skipped --  No module named gdbm
test_getopt
test_gettext
test test_gettext crashed -- exceptions.OverflowError: integer multiplication
test_gl
test test_gl skipped --  No module named gl
test_grp
test_gzip
test test_gzip skipped --  No module named zlib
test_hash
test_imageop
test test_imageop skipped --  No module named imageop
test_imgfile
test test_imgfile skipped --  No module named imgfile
test_largefile
test test_largefile skipped --  platform does not have largefile support
test_linuxaudiodev
test test_linuxaudiodev skipped --  No module named linuxaudiodev
test_long
test test_long crashed -- exceptions.OverflowError: integer multiplication
test_longexp
test_math
test_md5
test_mimetools
test test_mimetools crashed -- exceptions.AttributeError: encode
test_minidom
test test_minidom skipped --  No module named pyexpat
test_mmap
test test_mmap crashed -- exceptions.OverflowError: integer multiplication
test_new
test_nis
test test_nis skipped --  No module named nis
test_ntpath
test_openpty
test_operator
test test_operator failed -- Writing: 'mul(5, 2) = <class exceptions.OverflowError at 0x818f41c>: 10 expected', expected: 'testing:
 neg\012testing: or_\012testing: pos\012testing: repeat\012testing: rshift'
test_parser
test_pickle
test_pkg
test_poll
test test_poll crashed -- exceptions.OverflowError: integer multiplication
test_popen2
test_posixpath
test_pow
test test_pow crashed -- exceptions.OverflowError: integer multiplication
test_pty
test test_pty skipped --  No module named termios
test_pwd
test_pyexpat
test test_pyexpat skipped --  cannot import name expat
test_re
test test_re crashed -- exceptions.OverflowError: integer multiplication
test_regex
test_rfc822
test test_rfc822 crashed -- exceptions.OverflowError: integer multiplication
test_rgbimg
test test_rgbimg skipped --  No module named rgbimg
test_rotor
test_sax
test test_sax skipped --  cannot import name expat
test_select
test_sha
test_signal
test_socket
test_sre
test test_sre failed -- Writing: "sre.match(r'(a)|(b)', 'b').start(1)", expected: ''
test_strftime
test test_strftime crashed -- exceptions.OverflowError: integer multiplication
test_string
test_strop
test_struct
test test_struct crashed -- exceptions.OverflowError: integer multiplication
test_sunaudiodev
test test_sunaudiodev skipped --  No module named sunaudiodev
test_thread
Traceback (most recent call last):
  File "./Lib/test/test_thread.py", line 21, in task
    delay = random.random() * numtasks
  File "/home/roland/perso/src/sourceforge/python/dist/src/Lib/whrandom.py", line 71, in random
    x = (171 * x) % 30269
OverflowError: integer multiplication

-------------------------------------------------------

Date: 2000-Oct-03 09:03
By: jhylton

Comment:
Two more questions:
1) What platform?  Is this a 64-bit machine?  A regular x86?
2) Could you run this under gdb and report where exactly the error is being generated?  The exception is raised in Objects/intobject.c.  I would set a breakpoint at the top of int_mul() and step through the function.


-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115919&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 17:16:22 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 09:16:22 -0700
Subject: [Python-bugs-list] [Bug #115476] Python-2.0b2 is incompatible with readline version 2
Message-ID: <200010031616.JAA13825@delerium.i.sourceforge.net>

Bug #115476, was updated on 2000-Sep-27 05:26
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: None
Bug Group: None
Priority: 6
Summary: Python-2.0b2 is incompatible with readline version 2

Details: Python-2.0b2 is now incompatible with GNU readline version 2. This is new, Python-2.0b1 worked fine with it. The only reason that it is incompatible is that it is trying to read the symbol rl_library_version. I suggest this code is simply removed again.


Follow-Ups:

Date: 2000-Sep-27 10:52
By: jhylton

Comment:
The uses of rl_library_version was added a week ago after a suggestion by jpettit.  Need to resolve this for old issues of readline.

Question for jribbens: How unreasonable would it be to require readline 3 or later?  readline ver. 2 is more than three years old.

-------------------------------------------------------

Date: 2000-Sep-28 02:46
By: jribbens

Comment:
True, but unfortunately OpenBSD latest version ships with readline v2 installed. Normally I would consider this OpenBSD's fault for having an old version of readline, but since Python is not actually relying on any post-v2 features, I think it might be worthwhile retaining compatibility with the older library.
-------------------------------------------------------

Date: 2000-Oct-03 09:16
By: gvanrossum

Comment:
Fixed. We've removed the rl_library_version variable again in the CVS version.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115476&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 17:16:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 09:16:53 -0700
Subject: [Python-bugs-list] [Bug #113797] Build problems on Reliant Unix
Message-ID: <200010031616.JAA22037@bush.i.sourceforge.net>

Bug #113797, was updated on 2000-Sep-07 07:33
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: Build problems on Reliant Unix

Details: - the linker requires the options '-W1 -Blargedynsym', otherwise, Python's global functions and variables are not visible to external modules

- when building --with-threads, the linker requires the option -Kpthread

- mmapmodule.o requires a special library

Python version: 2.0b1

compiler version:CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000
CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000


Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 13:45
By: fdrake

Comment:
We need to know the output of "uname -s" and "uname -r" for this system.  (If "uname -r" reports an error, please try "uname -v".)

Are you willing to test a modified configure script on this platform?

What additional library is required for the mmap module?
-------------------------------------------------------

Date: 2000-Sep-12 21:59
By: fdrake

Comment:
Received the following response from Daniel Dittmar <ddittmar@users.sourceforge.net>:

> We need to know the output of "uname -s" and "uname -r" 
> for this system.  (If "uname -r" reports an error, please 
> try "uname -v".)

uname -s
ReliantUNIX-N

uname -r
5.45


> Are you willing to test a modified configure script on
> this platform?

sure.

> What additional library is required for the mmap module?

The man page states -lucb. This didn't work on my machine 
as the BSD compatibility layer is not active. I tell you 
more as soon as I know how to activate it.

***********

Another problem: to detect pthreads, the compiler must be 
called with -Kpthread. Otherwise, pthread.h goes into a 
branch where it tries to include a non existent header, 
fails, and configure reports 'no pthreads'.

Daniel

-------------------------------------------------------

Date: 2000-Sep-15 11:57
By: fdrake

Comment:
For the mmap issue, I've added a comment to Modules/Setup.in to let installers know that -lucb may be needed.  In revision 1.110.
-------------------------------------------------------

Date: 2000-Sep-15 13:37
By: fdrake

Comment:
I'm sending a modified version of  the configure script to Daniel Dittmar to test for the first two points in this bug report.
-------------------------------------------------------

Date: 2000-Sep-21 08:17
By: fdrake

Comment:
Sent query to Daniel Dittmar asking if he's had a chance to test the revised configure script I sent.
-------------------------------------------------------

Date: 2000-Sep-21 08:46
By: fdrake

Comment:
Received message from Daniel indicating he should get a chace to test the changes this weekend, so it should be available for 2.0b2.
-------------------------------------------------------

Date: 2000-Sep-24 05:46
By: ddittmar

Comment:
- configure --without-threads works with the configure patch Revision 1.158

- mmapmodule would work if it includes the lines

#include <unistd.h>

static int
getpagesize (void)
{
    return sysconf (_SC_PAGESIZE);
}

This would be the preferred way as using the BSD compatibility with -lucb is discouraged.

It requires chages to configure (has_pagesize, has_sysconf_sc_pagesize)

- configure --with-threads doesn't build yet, keeping contact with fdrake
-------------------------------------------------------

Date: 2000-Sep-25 08:10
By: fdrake

Comment:
Fix to make sure the public API properly exposed to extensions checked in as configure.in revision 1.155.  The rest of these issues can be dealt with in 2.0 final.
-------------------------------------------------------

Date: 2000-Sep-28 10:36
By: fdrake

Comment:
I've sent a patch for the mmap module to Daniel to test on Reliant UNIX; the patch should remove the need to link to libucb on that platform (the only platform that needed that as far as we know).
-------------------------------------------------------

Date: 2000-Oct-01 09:34
By: ddittmar

Comment:
The patch for the mmap module works on 2.0b2
-------------------------------------------------------

Date: 2000-Oct-01 10:51
By: fdrake

Comment:
mmap patch checked in as Modules/mmapmodule.c revision 2.24.
-------------------------------------------------------

Date: 2000-Oct-02 08:30
By: fdrake

Comment:
Sent another version of the configure script to Daniel Dittmar for testing the thread support.  I think this is the last remaining problem listed in this bug report.
-------------------------------------------------------

Date: 2000-Oct-03 09:16
By: fdrake

Comment:
Daniel Dittmar's response:
- the configure script works, except that the correct option is '-Kpthread'
(you mistyped '-Lpthread'

- there's a compilation error in thread_pthread.h:181: the expression
'(long) threadid' is not valid. The definition of pthread_t is 

typedef struct PTHREAD_HANDLE_T {
    void               *field1;
    short int           field2;
    short int           field3;
    } pthread_handle_t;

typedef pthread_handle_t pthread_t;

so I doubt that the alternative 

return (long) *(long *) &threadid

is valid. I could compile it with this version, but I doubt it's returning a
meaningful thread id. Is there a test for the thread module?

I'm away for the rest of the week, so I couldn't test anything for the
Wednesday date.

- for your information, I'm including the results of 'make test', at least
the failed ones:
test test_fork1 crashed -- exceptions.OSError: [Errno 4] Interrupted system
call
test test_popen2 crashed -- exceptions.IOError: [Errno 4] Interrupted system
call
test_signal
Trace/Breakpoint Trap - core dumped
make: *** Error code 133 (ignored)
make: *** Error code 133 (bu21) (ignored)

These test leave a few python processes around.

I'll probably look into this when I return.

Daniel

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113797&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 17:22:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 09:22:05 -0700
Subject: [Python-bugs-list] [Bug #113797] Build problems on Reliant Unix
Message-ID: <200010031622.JAA22271@bush.i.sourceforge.net>

Bug #113797, was updated on 2000-Sep-07 07:33
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: Build problems on Reliant Unix

Details: - the linker requires the options '-W1 -Blargedynsym', otherwise, Python's global functions and variables are not visible to external modules

- when building --with-threads, the linker requires the option -Kpthread

- mmapmodule.o requires a special library

Python version: 2.0b1

compiler version:CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000
CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000


Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 13:45
By: fdrake

Comment:
We need to know the output of "uname -s" and "uname -r" for this system.  (If "uname -r" reports an error, please try "uname -v".)

Are you willing to test a modified configure script on this platform?

What additional library is required for the mmap module?
-------------------------------------------------------

Date: 2000-Sep-12 21:59
By: fdrake

Comment:
Received the following response from Daniel Dittmar <ddittmar@users.sourceforge.net>:

> We need to know the output of "uname -s" and "uname -r" 
> for this system.  (If "uname -r" reports an error, please 
> try "uname -v".)

uname -s
ReliantUNIX-N

uname -r
5.45


> Are you willing to test a modified configure script on
> this platform?

sure.

> What additional library is required for the mmap module?

The man page states -lucb. This didn't work on my machine 
as the BSD compatibility layer is not active. I tell you 
more as soon as I know how to activate it.

***********

Another problem: to detect pthreads, the compiler must be 
called with -Kpthread. Otherwise, pthread.h goes into a 
branch where it tries to include a non existent header, 
fails, and configure reports 'no pthreads'.

Daniel

-------------------------------------------------------

Date: 2000-Sep-15 11:57
By: fdrake

Comment:
For the mmap issue, I've added a comment to Modules/Setup.in to let installers know that -lucb may be needed.  In revision 1.110.
-------------------------------------------------------

Date: 2000-Sep-15 13:37
By: fdrake

Comment:
I'm sending a modified version of  the configure script to Daniel Dittmar to test for the first two points in this bug report.
-------------------------------------------------------

Date: 2000-Sep-21 08:17
By: fdrake

Comment:
Sent query to Daniel Dittmar asking if he's had a chance to test the revised configure script I sent.
-------------------------------------------------------

Date: 2000-Sep-21 08:46
By: fdrake

Comment:
Received message from Daniel indicating he should get a chace to test the changes this weekend, so it should be available for 2.0b2.
-------------------------------------------------------

Date: 2000-Sep-24 05:46
By: ddittmar

Comment:
- configure --without-threads works with the configure patch Revision 1.158

- mmapmodule would work if it includes the lines

#include <unistd.h>

static int
getpagesize (void)
{
    return sysconf (_SC_PAGESIZE);
}

This would be the preferred way as using the BSD compatibility with -lucb is discouraged.

It requires chages to configure (has_pagesize, has_sysconf_sc_pagesize)

- configure --with-threads doesn't build yet, keeping contact with fdrake
-------------------------------------------------------

Date: 2000-Sep-25 08:10
By: fdrake

Comment:
Fix to make sure the public API properly exposed to extensions checked in as configure.in revision 1.155.  The rest of these issues can be dealt with in 2.0 final.
-------------------------------------------------------

Date: 2000-Sep-28 10:36
By: fdrake

Comment:
I've sent a patch for the mmap module to Daniel to test on Reliant UNIX; the patch should remove the need to link to libucb on that platform (the only platform that needed that as far as we know).
-------------------------------------------------------

Date: 2000-Oct-01 09:34
By: ddittmar

Comment:
The patch for the mmap module works on 2.0b2
-------------------------------------------------------

Date: 2000-Oct-01 10:51
By: fdrake

Comment:
mmap patch checked in as Modules/mmapmodule.c revision 2.24.
-------------------------------------------------------

Date: 2000-Oct-02 08:30
By: fdrake

Comment:
Sent another version of the configure script to Daniel Dittmar for testing the thread support.  I think this is the last remaining problem listed in this bug report.
-------------------------------------------------------

Date: 2000-Oct-03 09:16
By: fdrake

Comment:
Daniel Dittmar's response:
- the configure script works, except that the correct option is '-Kpthread'
(you mistyped '-Lpthread'

- there's a compilation error in thread_pthread.h:181: the expression
'(long) threadid' is not valid. The definition of pthread_t is 

typedef struct PTHREAD_HANDLE_T {
    void               *field1;
    short int           field2;
    short int           field3;
    } pthread_handle_t;

typedef pthread_handle_t pthread_t;

so I doubt that the alternative 

return (long) *(long *) &threadid

is valid. I could compile it with this version, but I doubt it's returning a
meaningful thread id. Is there a test for the thread module?

I'm away for the rest of the week, so I couldn't test anything for the
Wednesday date.

- for your information, I'm including the results of 'make test', at least
the failed ones:
test test_fork1 crashed -- exceptions.OSError: [Errno 4] Interrupted system
call
test test_popen2 crashed -- exceptions.IOError: [Errno 4] Interrupted system
call
test_signal
Trace/Breakpoint Trap - core dumped
make: *** Error code 133 (ignored)
make: *** Error code 133 (bu21) (ignored)

These test leave a few python processes around.

I'll probably look into this when I return.

Daniel

-------------------------------------------------------

Date: 2000-Oct-03 09:22
By: fdrake

Comment:
I've sent a note to Daniel asking for the config.h and config.log files generated by configure.  There's a real problem with the way we're creating thread identifiers; casting to a long just isn't sufficient.

It might be good to know what kind of processor is on the machine.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113797&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 17:32:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 09:32:30 -0700
Subject: [Python-bugs-list] [Bug #115919] Integer multiplication overflow
Message-ID: <200010031632.JAA22680@bush.i.sourceforge.net>

Bug #115919, was updated on 2000-Oct-03 08:01
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Integer multiplication overflow

Details: roland@cachemir ~ $ python2.0 
Python 2.0b2 (#3, Oct  3 2000, 16:30:25) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> 1+1
2
>>> 1*1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>> 

Last CVS update 2000-10-03 around 14:00 UTC.  Last before that was some weeks ago, sorry for not being precise.  Compiled with ./configure --prefix=/usr/local/ && make, su and make install.  Only personal change is the use of readline in Modules/Setup.local.  Did I do something wrong?

Follow-Ups:

Date: 2000-Oct-03 08:25
By: jhylton

Comment:
What happens when you run "make test"?  It looks like there is something fundamentally broken, but I can't tell what it is.  If 1*1 fails, I expect the rest of the test suite to also report errors.


-------------------------------------------------------

Date: 2000-Oct-03 08:38
By: lo-lan-do

Comment:
make test shows me plenty of lines looking like this one (except the name of the test changes):

test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication

I also get messages along the lines of 'test test_dbm skipped --  No module named dbm', but I guess these ones are OK.
-------------------------------------------------------

Date: 2000-Oct-03 08:40
By: jhylton

Comment:
Can you include the complete output?

-------------------------------------------------------

Date: 2000-Oct-03 09:02
By: lo-lan-do

Comment:
[In case the bug would be caused by a recent upgrade to a beta glibc, I tried the '1*1' test with Python 1.5.2.  No bug visible there.]

$ make distclean && ./configure --prefix=/usr/local/ && make
$ make test &> test.log

It seems that 'make test' somehow hangs when testing threads, so I cut at that point.  I hope the relevant info is shown before that point.
Here goes...

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Unhandled exception in thread:
test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication
test_opcodes
test_operations
test_builtin
test test_builtin crashed -- exceptions.OverflowError: integer multiplication
test_exceptions
test_types
test test_types crashed -- exceptions.OverflowError: integer multiplication
test_MimeWriter
test_StringIO
test_al
test test_al skipped --  No module named al
test_array
test test_array crashed -- exceptions.OverflowError: integer multiplication
test_atexit
test_audioop
test test_audioop skipped --  No module named audioop
test_augassign
test test_augassign crashed -- exceptions.OverflowError: integer multiplication
test_binascii
test_binhex
test test_binhex crashed -- exceptions.OverflowError: integer multiplication
test_bsddb
test_cd
test test_cd skipped --  No module named cd
test_cfgparser
test test_cfgparser crashed -- exceptions.OverflowError: integer multiplication
test_cgi
test test_cgi crashed -- exceptions.OverflowError: integer multiplication
test_cl
test test_cl skipped --  No module named cl
test_class
test_cmath
test_compile
test_contains
test_cookie
test test_cookie crashed -- exceptions.OverflowError: integer multiplication
test_cpickle
test_crypt
test test_crypt skipped --  No module named crypt
test_dbm
test test_dbm skipped --  No module named dbm
test_dl
test test_dl skipped --  No module named dl
test_dospath
test_errno
test_extcall
test_fcntl
test_file
test_fork1
test_format
test_gc
test_gdbm
test test_gdbm skipped --  No module named gdbm
test_getopt
test_gettext
test test_gettext crashed -- exceptions.OverflowError: integer multiplication
test_gl
test test_gl skipped --  No module named gl
test_grp
test_gzip
test test_gzip skipped --  No module named zlib
test_hash
test_imageop
test test_imageop skipped --  No module named imageop
test_imgfile
test test_imgfile skipped --  No module named imgfile
test_largefile
test test_largefile skipped --  platform does not have largefile support
test_linuxaudiodev
test test_linuxaudiodev skipped --  No module named linuxaudiodev
test_long
test test_long crashed -- exceptions.OverflowError: integer multiplication
test_longexp
test_math
test_md5
test_mimetools
test test_mimetools crashed -- exceptions.AttributeError: encode
test_minidom
test test_minidom skipped --  No module named pyexpat
test_mmap
test test_mmap crashed -- exceptions.OverflowError: integer multiplication
test_new
test_nis
test test_nis skipped --  No module named nis
test_ntpath
test_openpty
test_operator
test test_operator failed -- Writing: 'mul(5, 2) = <class exceptions.OverflowError at 0x818f41c>: 10 expected', expected: 'testing:
 neg\012testing: or_\012testing: pos\012testing: repeat\012testing: rshift'
test_parser
test_pickle
test_pkg
test_poll
test test_poll crashed -- exceptions.OverflowError: integer multiplication
test_popen2
test_posixpath
test_pow
test test_pow crashed -- exceptions.OverflowError: integer multiplication
test_pty
test test_pty skipped --  No module named termios
test_pwd
test_pyexpat
test test_pyexpat skipped --  cannot import name expat
test_re
test test_re crashed -- exceptions.OverflowError: integer multiplication
test_regex
test_rfc822
test test_rfc822 crashed -- exceptions.OverflowError: integer multiplication
test_rgbimg
test test_rgbimg skipped --  No module named rgbimg
test_rotor
test_sax
test test_sax skipped --  cannot import name expat
test_select
test_sha
test_signal
test_socket
test_sre
test test_sre failed -- Writing: "sre.match(r'(a)|(b)', 'b').start(1)", expected: ''
test_strftime
test test_strftime crashed -- exceptions.OverflowError: integer multiplication
test_string
test_strop
test_struct
test test_struct crashed -- exceptions.OverflowError: integer multiplication
test_sunaudiodev
test test_sunaudiodev skipped --  No module named sunaudiodev
test_thread
Traceback (most recent call last):
  File "./Lib/test/test_thread.py", line 21, in task
    delay = random.random() * numtasks
  File "/home/roland/perso/src/sourceforge/python/dist/src/Lib/whrandom.py", line 71, in random
    x = (171 * x) % 30269
OverflowError: integer multiplication

-------------------------------------------------------

Date: 2000-Oct-03 09:03
By: jhylton

Comment:
Two more questions:
1) What platform?  Is this a 64-bit machine?  A regular x86?
2) Could you run this under gdb and report where exactly the error is being generated?  The exception is raised in Objects/intobject.c.  I would set a breakpoint at the top of int_mul() and step through the function.


-------------------------------------------------------

Date: 2000-Oct-03 09:32
By: lo-lan-do

Comment:
1) Regular i686 (sez uname).
2) It seems that ah and bh are 1 and not 0 like they should.
A bit of printf-debugging shows me that LONG_BIT/2 is 32,
so somehow 1 >> 32 != 0, which seems most strange and
bizarre to me.  On the other hand, gcc tells me the following
when I compile:

intobject.c: In function `int_mul':
intobject.c:327: warning: right shift count >= width of type

I hope he [gcc] still does the rshift, but I'm no gcc guru.
Hope this helps...
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115919&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 17:35:07 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 09:35:07 -0700
Subject: [Python-bugs-list] [Bug #110681] memory leak in loops (PR#398)
Message-ID: <200010031635.JAA14690@delerium.i.sourceforge.net>

Bug #110681, was updated on 2000-Jul-31 14:14
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: memory leak in loops (PR#398)

Details: Jitterbug-Id: 398
Submitted-By: ingo.adler@synacon.ch
Date: Fri, 14 Jul 2000 05:10:25 -0400 (EDT)
Version: 1.5.2
OS: win nt


I have a simple loop, which produces memory leaks at every call (36 bytes):

{
    Py_SetProgramName("pythontest.exe");
    Py_Initialize();

    initxmodulec();

    PyRun_SimpleString("print \"... Python started ...\"");

    PyRun_SimpleString("import xmodule");
    PyRun_SimpleString("from xmodule import *");

// The Loop
    PyRun_SimpleString(
        "y = Y()\n"
        "for i in range(1000):\n"
        "\tx = y.getX()\n"
        "\tx.getNumber()\n"
    );




    PyRun_SimpleString("print \"... Python finished ...\"");
    Py_Finalize();
}

X and Y are my classes implemented in C++, connected to Python via Swig Shadow
Classes:

class X {

public:
    float getNumber()
    {
        return 12.2;
    }
};

class Y {
    X* pX;

public:
    Y()
    {
        pX = new X;
    }

    ~Y()
    {
        delete pX;
    }

    X* getX()
    {
        return pX;
    }
};

The classes and python are compiled statically with CBuilder5.0, Swig1.3a3 (same
problem with swig1.1).

I tested the application with "CodeGuard", which shows the memory leaks.
For every call in the loop there is an entry like this (I translated it to
English):

Error. 0x300010 (Thread 0x013B):
resource leak: memory block (0x15422F0) was never released

memory leak (0x015422F0) [size: 36 Byte] was assigned with malloc
call stack:
   0x0045ED5D(=pythontest.exe:0x01:05DD5D)
G:\Projects\src\fortuna\Python\Objects\stringobject.c#145
   0x00401EFD(=pythontest.exe:0x01:000EFD)
G:\Projects\src\fortuna\test\xmodule_wrap.c#769
   0x0040255D(=pythontest.exe:0x01:00155D)
G:\Projects\src\fortuna\test\xmodule_wrap.c#941
   0x0041BA79(=pythontest.exe:0x01:01AA79)
G:\Projects\src\fortuna\Python\Python\ceval.c#2359
   0x0041B912(=pythontest.exe:0x01:01A912)
G:\Projects\src\fortuna\Python\Python\ceval.c#2324
   0x0040EE3E(=pythontest.exe:0x01:00DE3E)
G:\Projects\src\fortuna\Python\Python\bltinmodule.c#12


The Code for line 941:

#define Y_getX(_swigobj)  (_swigobj->getX())
static PyObject *_wrap_Y_getX(PyObject *self, PyObject *args) {
    Y  *_arg0;
    PyObject  *_resultobj,*_argo0=0;
    X  *_result;
    self = self;
    if(!PyArg_ParseTuple(args,"O:Y_getX",&_argo0)) 
        return NULL;
    if ((SWIG_ConvertPtr(_argo0,(void **) &_arg0,SWIGTYPE_Y_p,1)) == -1) return
NULL;
    _result = (X *)Y_getX(_arg0);
/*941*/ _resultobj = SWIG_NewPointerObj((void *) _result, SWIGTYPE_X_p);
    return _resultobj;
}

The Code for line 769:

SWIGSTATICRUNTIME(PyObject *)
SWIG_NewPointerObj(void *ptr, _swig_type_info *type) {
  char result[512];
  PyObject *robj;
  if (!ptr) {
    Py_INCREF(Py_None);
    return Py_None;
  }
#ifdef SWIG_COBJECT_TYPES
  robj = PyCObject_FromVoidPtrAndDesc((void *) ptr, type->name, NULL);
#else
  SWIG_MakePtr(result,ptr,type);
/*769*/  robj = PyString_FromString(result);
#endif
  return robj;
}


Ingo Adler



====================================================================
Audit trail:
Tue Jul 25 07:27:50 2000	guido	changed notes
Tue Jul 25 07:27:50 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-01 14:01
By: none

Comment:
From: "M.-A. Lemburg" <mal@lemburg.com>
Subject: Re: [Python-bugs-list] memory leak in loops (PR#398)
Date: Fri, 14 Jul 2000 11:22:51 +0200

ingo.adler@synacon.ch wrote:
> 
> Full_Name: ingo adler
> Version: 1.5.2
> OS: win nt
> Submission from: megazh-d-201.agrinet.ch (212.28.158.201)
> 
> I have a simple loop, which produces memory leaks at every call (36 bytes):
> 
> {
>     Py_SetProgramName("pythontest.exe");
>     Py_Initialize();
> 
>     initxmodulec();
> 
>     PyRun_SimpleString("print \"... Python started ...\"");
> 
>     PyRun_SimpleString("import xmodule");
>     PyRun_SimpleString("from xmodule import *");
> 
> // The Loop
>     PyRun_SimpleString(
>         "y = Y()\n"
>         "for i in range(1000):\n"
>         "\tx = y.getX()\n"
>         "\tx.getNumber()\n"

Could be that SWIG doesn't get a chance to cleanup the shadow
object for x and y. Try adding

del x,y

as final script line.

Note that SWIG uses Python strings to represent pointers in
C++. It uses an internal table to store these.

>     );
> 
>     PyRun_SimpleString("print \"... Python finished ...\"");
>     Py_Finalize();
> }
> 
> X and Y are my classes implemented in C++, connected to Python via Swig Shadow
> Classes:
> 
> class X {
> 
> public:
>     float getNumber()
>     {
>         return 12.2;
>     }
> };
> 
> class Y {
>     X* pX;
> 
> public:
>     Y()
>     {
>         pX = new X;
>     }
> 
>     ~Y()
>     {
>         delete pX;
>     }
> 
>     X* getX()
>     {
>         return pX;
>     }
> };
> 
> The classes and python are compiled statically with CBuilder5.0, Swig1.3a3 (same
> problem with swig1.1).
> 
> I tested the application with "CodeGuard", which shows the memory leaks.
> For every call in the loop there is an entry like this (I translated it to
> English):
> 
> Error. 0x300010 (Thread 0x013B):
> resource leak: memory block (0x15422F0) was never released
> 
> memory leak (0x015422F0) [size: 36 Byte] was assigned with malloc
> call stack:
>    0x0045ED5D(=pythontest.exe:0x01:05DD5D)
> G:\Projects\src\fortuna\Python\Objects\stringobject.c#145
>    0x00401EFD(=pythontest.exe:0x01:000EFD)
> G:\Projects\src\fortuna\test\xmodule_wrap.c#769
>    0x0040255D(=pythontest.exe:0x01:00155D)
> G:\Projects\src\fortuna\test\xmodule_wrap.c#941
>    0x0041BA79(=pythontest.exe:0x01:01AA79)
> G:\Projects\src\fortuna\Python\Python\ceval.c#2359
>    0x0041B912(=pythontest.exe:0x01:01A912)
> G:\Projects\src\fortuna\Python\Python\ceval.c#2324
>    0x0040EE3E(=pythontest.exe:0x01:00DE3E)
> G:\Projects\src\fortuna\Python\Python\bltinmodule.c#12
> 
> The Code for line 941:
> 
> #define Y_getX(_swigobj)  (_swigobj->getX())
> static PyObject *_wrap_Y_getX(PyObject *self, PyObject *args) {
>     Y  *_arg0;
>     PyObject  *_resultobj,*_argo0=0;
>     X  *_result;
>     self = self;
>     if(!PyArg_ParseTuple(args,"O:Y_getX",&_argo0))
>         return NULL;
>     if ((SWIG_ConvertPtr(_argo0,(void **) &_arg0,SWIGTYPE_Y_p,1)) == -1) return
> NULL;
>     _result = (X *)Y_getX(_arg0);
> /*941*/ _resultobj = SWIG_NewPointerObj((void *) _result, SWIGTYPE_X_p);
>     return _resultobj;
> }
> 
> The Code for line 769:
> 
> SWIGSTATICRUNTIME(PyObject *)
> SWIG_NewPointerObj(void *ptr, _swig_type_info *type) {
>   char result[512];
>   PyObject *robj;
>   if (!ptr) {
>     Py_INCREF(Py_None);
>     return Py_None;
>   }
> #ifdef SWIG_COBJECT_TYPES
>   robj = PyCObject_FromVoidPtrAndDesc((void *) ptr, type->name, NULL);
> #else
>   SWIG_MakePtr(result,ptr,type);
> /*769*/  robj = PyString_FromString(result);
> #endif
>   return robj;
> }
> 
> Ingo Adler
> 
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Ingo Adler <ingo.adler@synacon.ch>
Subject: Re: [Python-bugs-list] memory leak in loops (PR#398)
Date: Fri, 14 Jul 2000 11:40:42 +0100

This is a multi-part message in MIME format.
--------------6D29988B97CCE77010389AE2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> > // The Loop
> >     PyRun_SimpleString(
> >         "y = Y()\n"
> >         "for i in range(1000):\n"
> >         "\tx = y.getX()\n"
> >         "\tx.getNumber()\n"
>
> Could be that SWIG doesn't get a chance to cleanup the shadow
> object for x and y. Try adding
>
> del x,y
>
> as final script line.
>
> Note that SWIG uses Python strings to represent pointers in
> C++. It uses an internal table to store these.
>

I changed the code to:

    PyRun_SimpleString(
        "y = Y()\n"
        "for i in range(1000):\n"
        "\tx = y.getX()\n"
        "\tx.getNumber()\n"
        "\tdel x\n"
    );

It doesn't change anything.

The memory leak only occurs when I call x.getNumber() in the loop. Otherwise x =
y.getX() is memory leak free.

Ingo Adler

--------------6D29988B97CCE77010389AE2
Content-Type: text/x-vcard; charset=us-ascii;
 name="ingo.adler.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ingo Adler
Content-Disposition: attachment;
 filename="ingo.adler.vcf"

begin:vcard 
n:Adler;Ingo
tel;cell:+41-79-3786792
tel;fax:+41-41-7103244
tel;home:+41-41-7103268
tel;work:+41-41-8111500
x-mozilla-html:FALSE
url:www.synacon.ch
org:Synacon GmbH
adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland
version:2.1
email;internet:ingo.adler@synacon.ch
title:Dipl.-Inform.
fn:Ingo Adler
end:vcard

--------------6D29988B97CCE77010389AE2--



-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: "M.-A. Lemburg" <mal@lemburg.com>
Subject: Re: [Python-bugs-list] memory leak in loops (PR#398)
Date: Fri, 14 Jul 2000 12:13:13 +0200

Ingo Adler wrote:
> 
> > > // The Loop
> > >     PyRun_SimpleString(
> > >         "y = Y()\n"
> > >         "for i in range(1000):\n"
> > >         "\tx = y.getX()\n"
> > >         "\tx.getNumber()\n"
> >
> > Could be that SWIG doesn't get a chance to cleanup the shadow
> > object for x and y. Try adding
> >
> > del x,y
> >
> > as final script line.
> >
> > Note that SWIG uses Python strings to represent pointers in
> > C++. It uses an internal table to store these.
> >
> 
> I changed the code to:
> 
>     PyRun_SimpleString(
>         "y = Y()\n"
>         "for i in range(1000):\n"
>         "\tx = y.getX()\n"
>         "\tx.getNumber()\n"
>         "\tdel x\n"
>     );
> 
> It doesn't change anything.
> 
> The memory leak only occurs when I call x.getNumber() in the loop. Otherwise x =
> y.getX() is memory leak free.

Two other possibilities:

1. Python interns the string object used by SWIG to represent
the point. It should then free the memory in the Py_Finalize()
call. If it doesn't, there's a bug to be found ;-)

2. SWIG has the leak. Try using the alternative method of
defining SWIG_COBJECT_TYPES (don't know how this is done --
it seems to be new in SWIG).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Ingo Adler <ingo.adler@synacon.ch>
Subject: Re: [Python-bugs-list] memory leak in loops (PR#398)
Date: Fri, 14 Jul 2000 12:45:02 +0100

This is a multi-part message in MIME format.
--------------82393A6779ADCFC3A2ADE19E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I could reproduce the problem with Developer Studio 6.0.

If anyone wants the project to test it - I can provide it.

Ingo Adler

--------------82393A6779ADCFC3A2ADE19E
Content-Type: text/x-vcard; charset=us-ascii;
 name="ingo.adler.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ingo Adler
Content-Disposition: attachment;
 filename="ingo.adler.vcf"

begin:vcard 
n:Adler;Ingo
tel;cell:+41-79-3786792
tel;fax:+41-41-7103244
tel;home:+41-41-7103268
tel;work:+41-41-8111500
x-mozilla-html:FALSE
url:www.synacon.ch
org:Synacon GmbH
adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland
version:2.1
email;internet:ingo.adler@synacon.ch
title:Dipl.-Inform.
fn:Ingo Adler
end:vcard

--------------82393A6779ADCFC3A2ADE19E--



-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: "Mark Hammond" <mhammond@skippinet.com.au>
Subject: RE: [Python-bugs-list] memory leak in loops (PR#398)
Date: Mon, 17 Jul 2000 22:16:54 -0400

> I could reproduce the problem with Developer Studio 6.0.
>
> If anyone wants the project to test it - I can provide it.

If you can repro the problem in just a few lines of C/C++ code but with no
SWIG generated code, I would be interested.  Otherwise, I suggest you do
some more work to narrow the problem down some more; as described, there is
still too much work to be done to narrow down the problem to the cause for
me to be interested (or anyone else given the feedback to date!)

Mark.



-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Ingo Adler <ingo.adler@synacon.ch>
Subject: Re: [Python-bugs-list] memory leak in loops (PR#398)
Date: Tue, 25 Jul 2000 01:34:22 +0200

This is a multi-part message in MIME format.
--------------72A23DA082087CB843E12C92
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Mark,

I could repro the memory leaks (they seem to be the same) with a much smaller
program:

int main(int argc, char* argv[])
{
    Py_SetProgramName("pythontest.exe");
    Py_Initialize();
    PyRun_SimpleString("print \"... Python started ...\"");
    PyRun_SimpleString("print \"... Python finished ...\"");
    Py_Finalize();

    return 0;
}

There seems to be a more general problem, which includes my special problem.

Output of Code Guard (translated to English). BoundsChecker shows the same
leaks.

Ingo

Output:

Memory Block (0x014EB9B4) [Size: 37 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043515A(=pythontest.exe:0x01:03415A)
D:\projects\Python\Objects\stringobject.c#95
   0x0043A8EB(=pythontest.exe:0x01:0398EB)
D:\projects\Python\Python\marshal.c#483
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504
   0x0043AB88(=pythontest.exe:0x01:039B88)
D:\projects\Python\Python\marshal.c#568
   0x0043AD37(=pythontest.exe:0x01:039D37)
D:\projects\Python\Python\marshal.c#624
   0x0042BC54(=pythontest.exe:0x01:02AC54)
D:\projects\Python\Python\import.c#575

------------------------------------------
Error 00078. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E4858) was never freed

Memory Block (0x014E4858) [Size: 31 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00425400(=pythontest.exe:0x01:024400)
D:\projects\Python\Objects\dictobject.c#1084
   0x00433896(=pythontest.exe:0x01:032896)
D:\projects\Python\Objects\moduleobject.c#56
   0x0042B993(=pythontest.exe:0x01:02A993)
D:\projects\Python\Python\import.c#428
   0x0043B0C9(=pythontest.exe:0x01:03A0C9)
D:\projects\Python\Python\modsupport.c#82
   0x0040C68A(=pythontest.exe:0x01:00B68A)
D:\projects\Python\Python\bltinmodule.c#2393

------------------------------------------
Error 00079. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E47D0) was never freed

Memory Block (0x014E47D0) [Size: 28 Byte] was assigned with malloc
Aufrufhierarchie:
   0x00433CB3(=pythontest.exe:0x01:032CB3)
D:\projects\Python\Objects\object.c#122
   0x00424115(=pythontest.exe:0x01:023115)
D:\projects\Python\Objects\dictobject.c#124
   0x004367D3(=pythontest.exe:0x01:0357D3)
D:\projects\Python\Objects\stringobject.c#1075
   0x00425418(=pythontest.exe:0x01:024418)
D:\projects\Python\Objects\dictobject.c#1087
   0x0043387A(=pythontest.exe:0x01:03287A)
D:\projects\Python\Objects\moduleobject.c#54
   0x0042B993(=pythontest.exe:0x01:02A993)
D:\projects\Python\Python\import.c#428

------------------------------------------
Error 00080. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E47AC) was never freed

Memory Block (0x014E47AC) [Size: 32 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00425400(=pythontest.exe:0x01:024400)
D:\projects\Python\Objects\dictobject.c#1084
   0x0043387A(=pythontest.exe:0x01:03287A)
D:\projects\Python\Objects\moduleobject.c#54
   0x0042B993(=pythontest.exe:0x01:02A993)
D:\projects\Python\Python\import.c#428
   0x0043B0C9(=pythontest.exe:0x01:03A0C9)
D:\projects\Python\Python\modsupport.c#82
   0x0040C68A(=pythontest.exe:0x01:00B68A)
D:\projects\Python\Python\bltinmodule.c#2393

------------------------------------------
Error 00081. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E46E4) was never freed

Memory Block (0x014E46E4) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x004240F7(=pythontest.exe:0x01:0230F7)
D:\projects\Python\Objects\dictobject.c#120
   0x0043C27B(=pythontest.exe:0x01:03B27B)
D:\projects\Python\Python\pythonrun.c#132
   0x00402934(=pythontest.exe:0x01:001934)
G:\Projects\src\test\pythonmain.cpp#15
   0x3257DC12(=CC3250MT.DLL:0x01:07CC12)

------------------------------------------
Error 00082. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x1524000) was never freed

Memory Block (0x01524000) [Size: 12288 Byte] was assigned with malloc
Aufrufhierarchie:
   0x004243A7(=pythontest.exe:0x01:0233A7)
D:\projects\Python\Objects\dictobject.c#280
   0x004245C4(=pythontest.exe:0x01:0235C4)
D:\projects\Python\Objects\dictobject.c#370
   0x00436837(=pythontest.exe:0x01:035837)
D:\projects\Python\Objects\stringobject.c#1086
   0x00415CA9(=pythontest.exe:0x01:014CA9)
D:\projects\Python\Python\compile.c#249
   0x0043AC12(=pythontest.exe:0x01:039C12)
D:\projects\Python\Python\marshal.c#578
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504

------------------------------------------
Error 00083. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFC9C) was never freed

Memory Block (0x014EFC9C) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411EE6(=pythontest.exe:0x01:010EE6)
D:\projects\Python\Objects\classobject.c#126
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00084. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFC74) was never freed

Memory Block (0x014EFC74) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411ED6(=pythontest.exe:0x01:010ED6)
D:\projects\Python\Objects\classobject.c#125
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00085. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFC4C) was never freed

Memory Block (0x014EFC4C) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411EC6(=pythontest.exe:0x01:010EC6)
D:\projects\Python\Objects\classobject.c#124
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00086. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14F19CC) was never freed

Memory Block (0x014F19CC) [Size: 47 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00431E97(=pythontest.exe:0x01:030E97)
D:\projects\Python\Objects\listobject.c#309
   0x0041137E(=pythontest.exe:0x01:01037E)
D:\projects\Python\Python\ceval.c#2512
   0x0040F906(=pythontest.exe:0x01:00E906)
D:\projects\Python\Python\ceval.c#1503
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324
   0x0042BAD4(=pythontest.exe:0x01:02AAD4)
D:\projects\Python\Python\import.c#485

------------------------------------------
Error 00087. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14F596C) was never freed

Memory Block (0x014F596C) [Size: 32 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x0042CED6(=pythontest.exe:0x01:02BED6)
D:\projects\Python\Python\import.c#1513
   0x0042CD19(=pythontest.exe:0x01:02BD19)
D:\projects\Python\Python\import.c#1441
   0x0042CE6A(=pythontest.exe:0x01:02BE6A)
D:\projects\Python\Python\import.c#1489
   0x00409B32(=pythontest.exe:0x01:008B32)
D:\projects\Python\Python\bltinmodule.c#65

------------------------------------------
Error 00088. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EB870) was never freed

Memory Block (0x014EB870) [Size: 32 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043515A(=pythontest.exe:0x01:03415A)
D:\projects\Python\Objects\stringobject.c#95
   0x0043A8EB(=pythontest.exe:0x01:0398EB)
D:\projects\Python\Python\marshal.c#483
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504
   0x0043AB88(=pythontest.exe:0x01:039B88)
D:\projects\Python\Python\marshal.c#568
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504
   0x0043AB76(=pythontest.exe:0x01:039B76)
D:\projects\Python\Python\marshal.c#567

------------------------------------------
Error 00089. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFBDC) was never freed

Memory Block (0x014EFBDC) [Size: 34 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411C9E(=pythontest.exe:0x01:010C9E)
D:\projects\Python\Objects\classobject.c#58
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00090. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E74C4) was never freed

Memory Block (0x014E74C4) [Size: 988 Byte] was assigned with malloc
Aufrufhierarchie:
   0x00430B62(=pythontest.exe:0x01:02FB62)
D:\projects\Python\Objects\intobject.c#113
   0x00430BFD(=pythontest.exe:0x01:02FBFD)
D:\projects\Python\Objects\intobject.c#163
   0x0040C6FC(=pythontest.exe:0x01:00B6FC)
D:\projects\Python\Python\bltinmodule.c#2404
   0x0043C29A(=pythontest.exe:0x01:03B29A)
D:\projects\Python\Python\pythonrun.c#136
   0x00402934(=pythontest.exe:0x01:001934)
G:\Projects\src\test\pythonmain.cpp#15
   0x3257DC12(=CC3250MT.DLL:0x01:07CC12)

------------------------------------------
Error 00091. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E96C4) was never freed

Memory Block (0x014E96C4) [Size: 174 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0042B0D9(=pythontest.exe:0x01:02A0D9) D:\projects\Python\PC\getpathp.c#403

   0x0042B2D5(=pythontest.exe:0x01:02A2D5) D:\projects\Python\PC\getpathp.c#508

   0x0043E40C(=pythontest.exe:0x01:03D40C)
D:\projects\Python\Python\sysmodule.c#413
   0x0043C2CA(=pythontest.exe:0x01:03B2CA)
D:\projects\Python\Python\pythonrun.c#142
   0x00402934(=pythontest.exe:0x01:001934)
G:\Projects\src\test\pythonmain.cpp#15
   0x3257DC12(=CC3250MT.DLL:0x01:07CC12)

------------------------------------------
Error 00092. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EF660) was never freed

Memory Block (0x014EF660) [Size: 36 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00425400(=pythontest.exe:0x01:024400)
D:\projects\Python\Objects\dictobject.c#1084
   0x0042BA54(=pythontest.exe:0x01:02AA54)
D:\projects\Python\Python\import.c#466
   0x0042BF73(=pythontest.exe:0x01:02AF73)
D:\projects\Python\Python\import.c#724
   0x0042C876(=pythontest.exe:0x01:02B876)
D:\projects\Python\Python\import.c#1202
   0x0042D51E(=pythontest.exe:0x01:02C51E)
D:\projects\Python\Python\import.c#1755

------------------------------------------
Error 00093. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x15211C8) was never freed

Memory Block (0x015211C8) [Size: 31 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x004129EE(=pythontest.exe:0x01:0119EE)
D:\projects\Python\Objects\classobject.c#517
   0x004246DD(=pythontest.exe:0x01:0236DD)
D:\projects\Python\Objects\dictobject.c#419
   0x0042546E(=pythontest.exe:0x01:02446E)
D:\projects\Python\Objects\dictobject.c#1103
   0x0043DF2E(=pythontest.exe:0x01:03CF2E)
D:\projects\Python\Python\sysmodule.c#95

------------------------------------------
Aufgerufene Funktionen:
 delete (35 Mal)
 getchar (1 Mal)
 fflush (2 Mal)
 fputs (2 Mal)
 fwrite (2 Mal)
 vsprintf (2 Mal)
 strrchr (14 Mal)
 fclose (14 Mal)
 strspn (251 Mal)
 fread (2021 Mal)
 _fgetc (40 Mal)
 fstat (7 Mal)
 fopen (72 Mal)
 strncmp (19 Mal)
 strcmp (423 Mal)
 stat (21 Mal)
 strncpy (32 Mal)
 strchr (125 Mal)
 sprintf (2 Mal)
 memcmp (1349 Mal)
 memset (133 Mal)
 strcpy (834 Mal)
 strlen (784 Mal)
 SysFreeMem (87 Mal)
 SysGetMem (87 Mal)
 realloc (88 Mal)
 memcpy (837 Mal)
 delete[] (2 Mal)
 free (4936 Mal)
 new[] (14 Mal)
 new (40 Mal)
 calloc (5 Mal)
 malloc (4946 Mal)
Verwendete Resource-Arten:
 Datei-Stream (14 Allocs, 5 max)
 Datei-Handle (14 Allocs, 5 max)
 Objekt-Array (14 Allocs, 13 max)
 Objekt (40 Allocs, 28 max)
 Memory Block (5039 Allocs, 2448 max)
Verwendete Module:
 00400000 07/25/2000 01:06:08 G:\Projects\src\bin\pythontest.exe
 0CD00000 02/03/2000 06:00:00 g:\programme\borland\cbuilder5\bin\CG32.DLL
 201A0000 02/22/2000 05:20:00 C:\WINNT.45\TRAYHOOK.dll
 32500000 02/03/2000 06:00:00 G:\Projects\src\bin\CC3250MT.DLL
 40000000 02/03/2000 05:01:00 C:\WINNT.45\System32\VCL50.BPL
 41000000 02/03/2000 06:00:00 G:\Projects\src\bin\BORLNDMM.DLL
 52180000 08/09/1996 00:00:00 C:\WINNT.45\system32\version.dll
 61220000 12/07/1999 16:03:46 G:\Programme\Microsoft
 Hardware\Mouse\MSH_ZWF.dll
 65340000 02/18/2000 16:16:02 C:\WINNT.45\system32\oleaut32.dll
 70970000 05/09/1998 13:57:06 C:\WINNT.45\system32\SHELL32.dll
 70BD0000 03/18/1999 00:00:00 C:\WINNT.45\system32\SHLWAPI.dll
 71190000 07/22/1999 21:09:08 C:\WINNT.45\system32\MSIDLE.DLL
 71590000 03/18/1999 00:00:00 C:\WINNT.45\system32\COMCTL32.dll
 73060000 05/13/1999 12:05:00 C:\WINNT.45\System32\winspool.drv
 77660000 05/13/1999 12:05:00 C:\WINNT.45\System32\MSWSOCK.dll
 77666C35 05/13/1999 12:05:00 C:\WINNT.45\system32\wsock32.dll
 77690000 05/13/1999 12:05:00 C:\WINNT.45\system32\WS2HELP.dll
 776A0000 05/13/1999 12:05:00 C:\WINNT.45\system32\WS2_32.dll
 77710000 05/13/1999 12:05:00 C:\WINNT.45\system32\mpr.dll
 77920000 05/13/1999 12:05:00 C:\WINNT.45\System32\oledlg.dll
 779B0000 08/09/1996 00:00:00 C:\WINNT.45\system32\LZ32.dll
 77B80000 05/13/1999 12:05:00 C:\WINNT.45\system32\ole32.dll
 77D80000 05/13/1999 12:05:00 C:\WINNT.45\system32\comdlg32.dll
 77DC0000 05/13/1999 12:05:00 C:\WINNT.45\system32\ADVAPI32.dll
 77E10000 05/13/1999 12:05:00 C:\WINNT.45\system32\RPCRT4.dll
 77E70000 05/13/1999 12:05:00 C:\WINNT.45\system32\user32.dll
 77ED0000 05/13/1999 12:05:00 C:\WINNT.45\system32\GDI32.dll
 77F00000 05/13/1999 12:05:00 C:\WINNT.45\system32\kernel32.dll
 77F70000 05/13/1999 12:05:00 C:\WINNT.45\System32\ntdll.dll
 78000000 12/07/1999 05:00:00 C:\WINNT.45\system32\MSVCRT.dll
==========================================



Mark Hammond wrote:

> > I could reproduce the problem with Developer Studio 6.0.
> >
> > If anyone wants the project to test it - I can provide it.
>
> If you can repro the problem in just a few lines of C/C++ code but with no
> SWIG generated code, I would be interested.  Otherwise, I suggest you do
> some more work to narrow the problem down some more; as described, there is
> still too much work to be done to narrow down the problem to the cause for
> me to be interested (or anyone else given the feedback to date!)
>
> Mark.

--------------72A23DA082087CB843E12C92
Content-Type: text/x-vcard; charset=us-ascii;
 name="ingo.adler.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ingo Adler
Content-Disposition: attachment;
 filename="ingo.adler.vcf"

begin:vcard 
n:Adler;Ingo
tel;fax:+41-41-7103244
tel;work:+41-41-8111500
x-mozilla-html:FALSE
org:Synacon GmbH
adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland
version:2.1
email;internet:ingo.adler@synacon.ch
fn:Ingo Adler
end:vcard

--------------72A23DA082087CB843E12C92--



-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
Actually, it's hard to say whether this is worth fixing...
Could it be a SWIG problem?
-------------------------------------------------------

Date: 2000-Sep-25 12:54
By: bwarsaw

Comment:
I don't believe there is a Python bug worth fixing here.  I've done some memory use testing with Python 2.0b2 using Insure++ on Linux, both with the regular interpreter, and with the small example embedded script given below.

There are "technical" memory leaks but they are almost all related to either leaks in the OS, or global memory still in use at the time Python exits.  An example of the former is leaks in strerror() - nothing we can do about that.  An example of the latter are leaks in the string intern dictionary, and we've already decided not to do anything about that.

There no identifiable chunks of memory leaked every time through the loop so I believe the problems reported below are either related to swig, have been fixed for Python 2.0, or are of the variety described above.
-------------------------------------------------------

Date: 2000-Oct-03 07:52
By: tregnago

Comment:
I'm working on an embedded application. I've looked with CodeGuard and it detect few memory leaks( similar as reported below ) only executing "Py_Initialize()" immediatly followed by "Py_Finalize()". Are you sure that this basic example is leaks free in your case?
I'm in big problems with that, and I can't find a way to escape from that.
-------------------------------------------------------

Date: 2000-Oct-03 09:00
By: bwarsaw

Comment:
Re-opening since there really are memory leaks we can fix.
-------------------------------------------------------

Date: 2000-Oct-03 09:35
By: bwarsaw

Comment:
I found a couple of leaks that aren't explained by valid in-reference memory at program exit, or leaks in OS libraries.  Fixes are found in the following files/versions: 

Python/import.c 2.153
Objects/unicodeobject.c 2.65

The last is probably the version that contains the patch.  I haven't actually checked it in yet -- I'm waiting for confirmation from the unicode expert.  I'm still closing this bug report as fixed.

With these patches, all memory leaks now are of the variety described previously.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110681&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 17:41:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 09:41:46 -0700
Subject: [Python-bugs-list] [Bug #110823] Tkinter missing button state symbols (PR#132)
Message-ID: <200010031641.JAA14998@delerium.i.sourceforge.net>

Bug #110823, was updated on 2000-Aug-01 14:10
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Closed
Resolution: Wont Fix
Bug Group: Feature Request
Priority: 5
Summary: Tkinter missing button state symbols (PR#132)

Details: Jitterbug-Id: 132
Submitted-By: aa8vb@yahoo.com
Date: Thu, 18 Nov 1999 08:16:55 -0500 (EST)
Version: 1.5.2
OS: IRIX 6.5


I have:

  picture.bind( "<ButtonPress-1>"  , click_cb )
  picture.bind( "<ButtonRelease-1>", click_cb )

In click_cb(), event.state is 0 for ButtonPress and 256 for ButtonRelease.

Where are the Tkinter constants for these?  Or how should one distinguish
between a press and release in a callback?

(I want to avoid having a separate callback for each type of event.)



====================================================================
Audit trail:
Thu Nov 18 10:42:46 1999	guido	changed notes
Thu Nov 18 10:42:46 1999	guido	moved from incoming to notabug
Thu Nov 18 14:07:59 1999	guido	changed notes
Thu Nov 18 14:07:59 1999	guido	moved from notabug to request

Follow-Ups:

Date: 2000-Aug-01 14:10
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] Tkinter missing button state symbols (PR#132)
Date: Thu, 18 Nov 1999 10:41:31 -0500

> Full_Name: Randall Hopper
> Version: 1.5.2
> OS: IRIX 6.5
> Submission from: ethyl-f.rtpfddi.epa.gov (134.67.65.11)
> 
> 
> I have:
> 
>   picture.bind( "<ButtonPress-1>"  , click_cb )
>   picture.bind( "<ButtonRelease-1>", click_cb )
> 
> In click_cb(), event.state is 0 for ButtonPress and 256 for ButtonRelease.
> 
> Where are the Tkinter constants for these?  Or how should one distinguish
> between a press and release in a callback?
> 
> (I want to avoid having a separate callback for each type of event.)

This is not a question for the bugs list.

Write to help@python.org or use the newsgroup for help.  I don't know
offhand what the answer is to your question; I suspect that the answer
is in the Tcl/Tk man page for the bind command though.

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:10
By: none

Comment:
From: Randall Hopper <Hopper.Randall@epa.gov>
Subject: Re: [Python-bugs-list] Tkinter missing button state symbols (PR#132)
Date: Thu, 18 Nov 1999 14:04:13 -0500

Guido van Rossum:
 |> Full_Name: Randall Hopper
 |> Version: 1.5.2
 |> OS: IRIX 6.5
 |> Submission from: ethyl-f.rtpfddi.epa.gov (134.67.65.11)
 |> 
 |> 
 |> I have:
 |> 
 |>   picture.bind( "<ButtonPress-1>"  , click_cb )
 |>   picture.bind( "<ButtonRelease-1>", click_cb )
 |> 
 |> In click_cb(), event.state is 0 for ButtonPress and 256 for ButtonRelease.
 |> 
 |> Where are the Tkinter constants for these?  Or how should one distinguish
 |> between a press and release in a callback?
 |> 
 |> (I want to avoid having a separate callback for each type of event.)
 |
 |This is not a question for the bugs list.
 |
 |Write to help@python.org or use the newsgroup for help.  I don't know
 |offhand what the answer is to your question; I suspect that the answer
 |is in the Tcl/Tk man page for the bind command though.

My fault.  I should have rephrased the question into a statement.  Tkinter
does not provide symbol defines for event.state values (%s keyword in Tcl).
Tcl doesn't either, but it would be useful if Tkinter did.

This is a small enhancement request rather than a hard bug, but I thought
the submission form was for probably applicable for both.

Thanks,

Randall

-------------------------------------------------------

Date: 2000-Aug-01 14:10
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] Tkinter missing button state symbols (PR#132)
Date: Thu, 18 Nov 1999 14:05:57 -0500

Yes, requests are okay.  Sorry for the confusion.

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:10
By: none

Comment:
Should add a symbol as he suggests.
-------------------------------------------------------

Date: 2000-Aug-09 02:21
By: effbot

Comment:
IIRC, these constants are platform (X library) dependent (they have to be exported from _tkinter.c, not Tkconstants.py).

I'll investigate.  Feel free to assign the bug to me if you like.

</F>
-------------------------------------------------------

Date: 2000-Aug-10 11:43
By: gvanrossum

Comment:
/F, go for it!
-------------------------------------------------------

Date: 2000-Sep-24 07:01
By: none

Comment:
LOL.I DON'T UNDERSTAND THIS SHIT BUT SOUNDS REALLY INTERESTING.WHERE CAN I LEARN HOW TO DO THIS??? SOME-ONE HELP ME!!
-------------------------------------------------------

Date: 2000-Sep-30 21:30
By: gvanrossum

Comment:
Fredrik, you promised to do this...  Do you have time?
-------------------------------------------------------

Date: 2000-Oct-03 08:22
By: gvanrossum

Comment:
I'll do this so Fredrik can do SRE.
-------------------------------------------------------

Date: 2000-Oct-03 09:41
By: gvanrossum

Comment:
Sorry, I won't fix this. Tcl/Tk doesn't document the values you get here, and I don't want to make assumptions about their undocumented features.

The proper solution is to be a man and use separate callbacks. :-)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110823&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 17:41:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 09:41:56 -0700
Subject: [Python-bugs-list] [Bug #115928] UserList.__getslice__ and co break previous behaviour
Message-ID: <200010031641.JAA15003@delerium.i.sourceforge.net>

Bug #115928, was updated on 2000-Oct-03 09:41
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: UserList.__getslice__ and co break previous behaviour

Details: When I make a class MyL derived from UserList, and a MyL instance named l, then l[:] returns a true list (in the sense that it responds to list operators).

Well, this is the behaviour in version 1.5.1. I recently upgraded to 1.5.2 (by switching my Linux distro to Debian Potato), and it breaks lots of my code, because the slice operator tries to create a new instance of MyL !

Unfortunately, MyL's constructor does not respond to UserList prototype expectance (no arguments), because MyL is a complex object that needs extra arguments at construction.

Additionally, it is not advisable, in that context, to create new MyL instances (or copies) like this, because of database connection / open files.

I triple checked the documentation of UserList/Sequences for 1.5.1, 1.5.2 and 1.6.0, and there is no such requirement that the slice operator should return a result of the same class as the operand, nor any specification on the constructor's arguments.

I understand anyway, that it has to return an object of the same sequence nature, be it tuple, list or string. But since I derive from a UserList, I expect it to look, smell and act like a python list... Hence the slice operator should return a plain list, that will in turn look, smell and act like a list, which it actually is !

The same reasonning holds for +/*/copy operators.

One could object, that if I do l=l[1:], or l=l+[x], then l would not be an MyL instance any more, and that is probably annoying.

That's perfectly true, but on one hand that's perhaps what I want, and on the other hand, it's my job to specify that + on a MyL instance should return a MyL instance, to specify how it should be done, and to implement it by overloading the adequate method. I don't want UserList implementation to decide for me !

If UserList is implemented the minimal way, then I'm free to overload it's methods to change its behaviour. That's what a class is for !
On the contrary, if it's implemented the current way, I have no choice. One solution is to bring back the old UserList implementation and put it in front of the python provided one in PYTHONPATH. Another is to overload methods to restore its generic behaviour.

Both solutions virtually make a library module useless, which I don't like. Why not making the default implementation the generic way, and provide another UserList2 implementation with different specification and requirements on its derived classes ?

Anyway, one of the implementation or the documentation/specification should be changed, so that they are in accordance to each other...


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115928&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 17:55:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 09:55:34 -0700
Subject: [Python-bugs-list] [Bug #115625] python2.0b2 test_pty fails on x86 Solaris 8
Message-ID: <200010031655.JAA23604@bush.i.sourceforge.net>

Bug #115625, was updated on 2000-Sep-28 16:20
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 7
Summary: python2.0b2 test_pty fails on x86 Solaris 8

Details: When I enable the termios module in Python 2.0b2 on x86
Solaris 8, the test_pty test fails with the following
message:

test test_pty failed -- master_fd is not a tty

I have no special interest in the termios module,
but I thought I'd report the problem since the README
file suggests enabling it if possible.  I have not tried
any other platforms so I cannot tell if the problem is
system-specific.

It would be worth checking the list of suggested Unix
modules in the README file against the Setup file, because
some files suggested in the README were already uncommented,
and others were marked as obsolete (e.g. soundex).

Follow-Ups:

Date: 2000-Sep-28 17:31
By: fdrake

Comment:
Updated the information about potentially interesting extensions in the README file, revision 1.100.

The test_pty failure remains.
-------------------------------------------------------

Date: 2000-Oct-03 08:35
By: jhylton

Comment:
I don't have Solaris (x86 or otherwise).  Can you help with this bug Thomas?

-------------------------------------------------------

Date: 2000-Oct-03 08:59
By: twouters

Comment:
I only have an aging, flukey, cranky old Sun box with Solaris 2.6 (and probably not properly installed at that;) but I'll give it a try. I suspect something goes wrong with the isatty test, but I'll see whether I can reproduce it on Sun hardware :P

-------------------------------------------------------

Date: 2000-Oct-03 09:55
By: twouters

Comment:
I was able to reproduce this bug, and found out what the problem is: Solaris does not consider the master end of a tty/pty pair (the pty) a terminal, apparently, and so os.isatty() returns false. The slave end is a terminal, however. I've checked in a fix for this, which just skips the master_fd test.


-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115625&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 18:01:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 10:01:54 -0700
Subject: [Python-bugs-list] [Bug #115919] Integer multiplication overflow
Message-ID: <200010031701.KAA23826@bush.i.sourceforge.net>

Bug #115919, was updated on 2000-Oct-03 08:01
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: Integer multiplication overflow

Details: roland@cachemir ~ $ python2.0 
Python 2.0b2 (#3, Oct  3 2000, 16:30:25) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> 1+1
2
>>> 1*1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>> 

Last CVS update 2000-10-03 around 14:00 UTC.  Last before that was some weeks ago, sorry for not being precise.  Compiled with ./configure --prefix=/usr/local/ && make, su and make install.  Only personal change is the use of readline in Modules/Setup.local.  Did I do something wrong?

Follow-Ups:

Date: 2000-Oct-03 08:25
By: jhylton

Comment:
What happens when you run "make test"?  It looks like there is something fundamentally broken, but I can't tell what it is.  If 1*1 fails, I expect the rest of the test suite to also report errors.


-------------------------------------------------------

Date: 2000-Oct-03 08:38
By: lo-lan-do

Comment:
make test shows me plenty of lines looking like this one (except the name of the test changes):

test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication

I also get messages along the lines of 'test test_dbm skipped --  No module named dbm', but I guess these ones are OK.
-------------------------------------------------------

Date: 2000-Oct-03 08:40
By: jhylton

Comment:
Can you include the complete output?

-------------------------------------------------------

Date: 2000-Oct-03 09:02
By: lo-lan-do

Comment:
[In case the bug would be caused by a recent upgrade to a beta glibc, I tried the '1*1' test with Python 1.5.2.  No bug visible there.]

$ make distclean && ./configure --prefix=/usr/local/ && make
$ make test &> test.log

It seems that 'make test' somehow hangs when testing threads, so I cut at that point.  I hope the relevant info is shown before that point.
Here goes...

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Unhandled exception in thread:
test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication
test_opcodes
test_operations
test_builtin
test test_builtin crashed -- exceptions.OverflowError: integer multiplication
test_exceptions
test_types
test test_types crashed -- exceptions.OverflowError: integer multiplication
test_MimeWriter
test_StringIO
test_al
test test_al skipped --  No module named al
test_array
test test_array crashed -- exceptions.OverflowError: integer multiplication
test_atexit
test_audioop
test test_audioop skipped --  No module named audioop
test_augassign
test test_augassign crashed -- exceptions.OverflowError: integer multiplication
test_binascii
test_binhex
test test_binhex crashed -- exceptions.OverflowError: integer multiplication
test_bsddb
test_cd
test test_cd skipped --  No module named cd
test_cfgparser
test test_cfgparser crashed -- exceptions.OverflowError: integer multiplication
test_cgi
test test_cgi crashed -- exceptions.OverflowError: integer multiplication
test_cl
test test_cl skipped --  No module named cl
test_class
test_cmath
test_compile
test_contains
test_cookie
test test_cookie crashed -- exceptions.OverflowError: integer multiplication
test_cpickle
test_crypt
test test_crypt skipped --  No module named crypt
test_dbm
test test_dbm skipped --  No module named dbm
test_dl
test test_dl skipped --  No module named dl
test_dospath
test_errno
test_extcall
test_fcntl
test_file
test_fork1
test_format
test_gc
test_gdbm
test test_gdbm skipped --  No module named gdbm
test_getopt
test_gettext
test test_gettext crashed -- exceptions.OverflowError: integer multiplication
test_gl
test test_gl skipped --  No module named gl
test_grp
test_gzip
test test_gzip skipped --  No module named zlib
test_hash
test_imageop
test test_imageop skipped --  No module named imageop
test_imgfile
test test_imgfile skipped --  No module named imgfile
test_largefile
test test_largefile skipped --  platform does not have largefile support
test_linuxaudiodev
test test_linuxaudiodev skipped --  No module named linuxaudiodev
test_long
test test_long crashed -- exceptions.OverflowError: integer multiplication
test_longexp
test_math
test_md5
test_mimetools
test test_mimetools crashed -- exceptions.AttributeError: encode
test_minidom
test test_minidom skipped --  No module named pyexpat
test_mmap
test test_mmap crashed -- exceptions.OverflowError: integer multiplication
test_new
test_nis
test test_nis skipped --  No module named nis
test_ntpath
test_openpty
test_operator
test test_operator failed -- Writing: 'mul(5, 2) = <class exceptions.OverflowError at 0x818f41c>: 10 expected', expected: 'testing:
 neg\012testing: or_\012testing: pos\012testing: repeat\012testing: rshift'
test_parser
test_pickle
test_pkg
test_poll
test test_poll crashed -- exceptions.OverflowError: integer multiplication
test_popen2
test_posixpath
test_pow
test test_pow crashed -- exceptions.OverflowError: integer multiplication
test_pty
test test_pty skipped --  No module named termios
test_pwd
test_pyexpat
test test_pyexpat skipped --  cannot import name expat
test_re
test test_re crashed -- exceptions.OverflowError: integer multiplication
test_regex
test_rfc822
test test_rfc822 crashed -- exceptions.OverflowError: integer multiplication
test_rgbimg
test test_rgbimg skipped --  No module named rgbimg
test_rotor
test_sax
test test_sax skipped --  cannot import name expat
test_select
test_sha
test_signal
test_socket
test_sre
test test_sre failed -- Writing: "sre.match(r'(a)|(b)', 'b').start(1)", expected: ''
test_strftime
test test_strftime crashed -- exceptions.OverflowError: integer multiplication
test_string
test_strop
test_struct
test test_struct crashed -- exceptions.OverflowError: integer multiplication
test_sunaudiodev
test test_sunaudiodev skipped --  No module named sunaudiodev
test_thread
Traceback (most recent call last):
  File "./Lib/test/test_thread.py", line 21, in task
    delay = random.random() * numtasks
  File "/home/roland/perso/src/sourceforge/python/dist/src/Lib/whrandom.py", line 71, in random
    x = (171 * x) % 30269
OverflowError: integer multiplication

-------------------------------------------------------

Date: 2000-Oct-03 09:03
By: jhylton

Comment:
Two more questions:
1) What platform?  Is this a 64-bit machine?  A regular x86?
2) Could you run this under gdb and report where exactly the error is being generated?  The exception is raised in Objects/intobject.c.  I would set a breakpoint at the top of int_mul() and step through the function.


-------------------------------------------------------

Date: 2000-Oct-03 09:32
By: lo-lan-do

Comment:
1) Regular i686 (sez uname).
2) It seems that ah and bh are 1 and not 0 like they should.
A bit of printf-debugging shows me that LONG_BIT/2 is 32,
so somehow 1 >> 32 != 0, which seems most strange and
bizarre to me.  On the other hand, gcc tells me the following
when I compile:

intobject.c: In function `int_mul':
intobject.c:327: warning: right shift count >= width of type

I hope he [gcc] still does the rshift, but I'm no gcc guru.
Hope this helps...
-------------------------------------------------------

Date: 2000-Oct-03 10:01
By: jhylton

Comment:
This does help.  The compiler warning is a bad sign.  I notice that you're using a more recent version of gcc than I have installed.  I'll try building with a newer gcc, but in the interim it may help if you compile the following test program:

#include <stdio.h>
#include <ctype.h>

#ifndef CHAR_BIT
#define CHAR_BIT 8
#endif

#ifndef LONG_BIT
#define LONG_BIT (CHAR_BIT * sizeof(long))
#endif

int main()
{
    int a, b;
    a = 1;
    b = a;
    a = a >> (LONG_BIT / 2);
    printf("CHAR_BIT = %d, LONG_BIT = %d\n", CHAR_BIT, LONG_BIT);
    printf("%d >> %d == %d\n", b, LONG_BIT/2, a);
    return 0;
}

On my system it compiles without warning using gcc -Wall and produces the following output:

CHAR_BIT = 8, LONG_BIT = 32
1 >> 16 == 0

What output do you get?  What is sizeof(long) on your platform?  Does ctype.h define CHAR_BIT or LONG_BIT?

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115919&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 18:03:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 10:03:55 -0700
Subject: [Python-bugs-list] [Bug #115928] UserList.__getslice__ and co break previous behaviour
Message-ID: <200010031703.KAA23956@bush.i.sourceforge.net>

Bug #115928, was updated on 2000-Oct-03 09:41
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: UserList.__getslice__ and co break previous behaviour

Details: When I make a class MyL derived from UserList, and a MyL instance named l, then l[:] returns a true list (in the sense that it responds to list operators).

Well, this is the behaviour in version 1.5.1. I recently upgraded to 1.5.2 (by switching my Linux distro to Debian Potato), and it breaks lots of my code, because the slice operator tries to create a new instance of MyL !

Unfortunately, MyL's constructor does not respond to UserList prototype expectance (no arguments), because MyL is a complex object that needs extra arguments at construction.

Additionally, it is not advisable, in that context, to create new MyL instances (or copies) like this, because of database connection / open files.

I triple checked the documentation of UserList/Sequences for 1.5.1, 1.5.2 and 1.6.0, and there is no such requirement that the slice operator should return a result of the same class as the operand, nor any specification on the constructor's arguments.

I understand anyway, that it has to return an object of the same sequence nature, be it tuple, list or string. But since I derive from a UserList, I expect it to look, smell and act like a python list... Hence the slice operator should return a plain list, that will in turn look, smell and act like a list, which it actually is !

The same reasonning holds for +/*/copy operators.

One could object, that if I do l=l[1:], or l=l+[x], then l would not be an MyL instance any more, and that is probably annoying.

That's perfectly true, but on one hand that's perhaps what I want, and on the other hand, it's my job to specify that + on a MyL instance should return a MyL instance, to specify how it should be done, and to implement it by overloading the adequate method. I don't want UserList implementation to decide for me !

If UserList is implemented the minimal way, then I'm free to overload it's methods to change its behaviour. That's what a class is for !
On the contrary, if it's implemented the current way, I have no choice. One solution is to bring back the old UserList implementation and put it in front of the python provided one in PYTHONPATH. Another is to overload methods to restore its generic behaviour.

Both solutions virtually make a library module useless, which I don't like. Why not making the default implementation the generic way, and provide another UserList2 implementation with different specification and requirements on its derived classes ?

Anyway, one of the implementation or the documentation/specification should be changed, so that they are in accordance to each other...


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115928&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 18:14:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 10:14:50 -0700
Subject: [Python-bugs-list] [Bug #115918] 2.0b2: print a_module.__dict__ also prints the license text
Message-ID: <200010031714.KAA16408@delerium.i.sourceforge.net>

Bug #115918, was updated on 2000-Oct-03 07:55
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: 2.0b2: print a_module.__dict__ also prints the license text

Details: When trying to print the dictionary of an imported module, say:

import a_module
print a_module.__dict__

Python 2.0b2 also prints the Python license text (intermingled
with the printing of the dictionary contents).


Follow-Ups:

Date: 2000-Oct-03 08:16
By: gvanrossum

Comment:
Hm. Yes, this is a problem. It's caused because __dict__ contains __builtins__ which contains the magic license object. Barry -- what to do? Maybe the license object should have a static repr which is the entire license text????
-------------------------------------------------------

Date: 2000-Oct-03 08:19
By: jhylton

Comment:
Is there any way to make the license builtin behave nicely in this context?

-------------------------------------------------------

Date: 2000-Oct-03 10:14
By: gvanrossum

Comment:
Fixed by latest checkin to site.py. __repr__ no longer prints and reads; __repr__ is the string you want to see if it's short, and a messages asking you to *call* the object if it needs paging. The printing and reading happens in __call__.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115918&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 18:23:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 10:23:44 -0700
Subject: [Python-bugs-list] [Bug #115690] Dr. Watson error on Python2.0b2 Idle 0.6 WinNT4.0 SP6
Message-ID: <200010031723.KAA16818@delerium.i.sourceforge.net>

Bug #115690, was updated on 2000-Sep-29 14:55
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: Dr. Watson error on Python2.0b2 Idle 0.6 WinNT4.0 SP6

Details: I get a Dr. Watson error:

    pythonw.exe
    Exception: access violation (0xc0000005), 
    Address: 0x00e31652

when I run the following code in Idle 0.6, using Edit->Run Script:

---%<---cut---%<---

import unicodedata
for c in range(0x10000):
    x=unichr(c)
    try:
        b = unicodedata.numeric(x)
        #print "numeric:", repr(x)
        try:
            a = unicodedata.digit(x)
            if a != b:
                print "bad" , repr(x)
        except:
            print "Numeric but not digit", hex(c), x.encode("utf8"), \
                  "numeric ->", b
    except:
        pass

---%<---cut---%<---

(This code was recently posted on python-dev)

I've modified my .idle file, adding 

    [EditorWindow]
    font-name=tahoma


Follow-Ups:

Date: 2000-Sep-29 21:42
By: jhylton

Comment:
Marc-Andre can you check whether this is a Unicode bug that is going to come up with or without idle.  If it seems Idle specific, please assign it to Guido or Tim.  If not, it's yours :-).


-------------------------------------------------------

Date: 2000-Oct-03 10:23
By: lemburg

Comment:
I can't reproduce this on Linux, so it seems that it is related to the way TCL/Tk
displays UTF-8 data. Another possibility would be an optimization error
which doesn't happen with gcc.

Tim, could you try this on Windows and possibly tell me where the segfault
occurs in the code ?

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115690&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 18:26:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 10:26:01 -0700
Subject: [Python-bugs-list] [Bug #115919] Integer multiplication overflow
Message-ID: <200010031726.KAA16864@delerium.i.sourceforge.net>

Bug #115919, was updated on 2000-Oct-03 08:01
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: Integer multiplication overflow

Details: roland@cachemir ~ $ python2.0 
Python 2.0b2 (#3, Oct  3 2000, 16:30:25) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> 1+1
2
>>> 1*1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>> 

Last CVS update 2000-10-03 around 14:00 UTC.  Last before that was some weeks ago, sorry for not being precise.  Compiled with ./configure --prefix=/usr/local/ && make, su and make install.  Only personal change is the use of readline in Modules/Setup.local.  Did I do something wrong?

Follow-Ups:

Date: 2000-Oct-03 08:25
By: jhylton

Comment:
What happens when you run "make test"?  It looks like there is something fundamentally broken, but I can't tell what it is.  If 1*1 fails, I expect the rest of the test suite to also report errors.


-------------------------------------------------------

Date: 2000-Oct-03 08:38
By: lo-lan-do

Comment:
make test shows me plenty of lines looking like this one (except the name of the test changes):

test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication

I also get messages along the lines of 'test test_dbm skipped --  No module named dbm', but I guess these ones are OK.
-------------------------------------------------------

Date: 2000-Oct-03 08:40
By: jhylton

Comment:
Can you include the complete output?

-------------------------------------------------------

Date: 2000-Oct-03 09:02
By: lo-lan-do

Comment:
[In case the bug would be caused by a recent upgrade to a beta glibc, I tried the '1*1' test with Python 1.5.2.  No bug visible there.]

$ make distclean && ./configure --prefix=/usr/local/ && make
$ make test &> test.log

It seems that 'make test' somehow hangs when testing threads, so I cut at that point.  I hope the relevant info is shown before that point.
Here goes...

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Unhandled exception in thread:
test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication
test_opcodes
test_operations
test_builtin
test test_builtin crashed -- exceptions.OverflowError: integer multiplication
test_exceptions
test_types
test test_types crashed -- exceptions.OverflowError: integer multiplication
test_MimeWriter
test_StringIO
test_al
test test_al skipped --  No module named al
test_array
test test_array crashed -- exceptions.OverflowError: integer multiplication
test_atexit
test_audioop
test test_audioop skipped --  No module named audioop
test_augassign
test test_augassign crashed -- exceptions.OverflowError: integer multiplication
test_binascii
test_binhex
test test_binhex crashed -- exceptions.OverflowError: integer multiplication
test_bsddb
test_cd
test test_cd skipped --  No module named cd
test_cfgparser
test test_cfgparser crashed -- exceptions.OverflowError: integer multiplication
test_cgi
test test_cgi crashed -- exceptions.OverflowError: integer multiplication
test_cl
test test_cl skipped --  No module named cl
test_class
test_cmath
test_compile
test_contains
test_cookie
test test_cookie crashed -- exceptions.OverflowError: integer multiplication
test_cpickle
test_crypt
test test_crypt skipped --  No module named crypt
test_dbm
test test_dbm skipped --  No module named dbm
test_dl
test test_dl skipped --  No module named dl
test_dospath
test_errno
test_extcall
test_fcntl
test_file
test_fork1
test_format
test_gc
test_gdbm
test test_gdbm skipped --  No module named gdbm
test_getopt
test_gettext
test test_gettext crashed -- exceptions.OverflowError: integer multiplication
test_gl
test test_gl skipped --  No module named gl
test_grp
test_gzip
test test_gzip skipped --  No module named zlib
test_hash
test_imageop
test test_imageop skipped --  No module named imageop
test_imgfile
test test_imgfile skipped --  No module named imgfile
test_largefile
test test_largefile skipped --  platform does not have largefile support
test_linuxaudiodev
test test_linuxaudiodev skipped --  No module named linuxaudiodev
test_long
test test_long crashed -- exceptions.OverflowError: integer multiplication
test_longexp
test_math
test_md5
test_mimetools
test test_mimetools crashed -- exceptions.AttributeError: encode
test_minidom
test test_minidom skipped --  No module named pyexpat
test_mmap
test test_mmap crashed -- exceptions.OverflowError: integer multiplication
test_new
test_nis
test test_nis skipped --  No module named nis
test_ntpath
test_openpty
test_operator
test test_operator failed -- Writing: 'mul(5, 2) = <class exceptions.OverflowError at 0x818f41c>: 10 expected', expected: 'testing:
 neg\012testing: or_\012testing: pos\012testing: repeat\012testing: rshift'
test_parser
test_pickle
test_pkg
test_poll
test test_poll crashed -- exceptions.OverflowError: integer multiplication
test_popen2
test_posixpath
test_pow
test test_pow crashed -- exceptions.OverflowError: integer multiplication
test_pty
test test_pty skipped --  No module named termios
test_pwd
test_pyexpat
test test_pyexpat skipped --  cannot import name expat
test_re
test test_re crashed -- exceptions.OverflowError: integer multiplication
test_regex
test_rfc822
test test_rfc822 crashed -- exceptions.OverflowError: integer multiplication
test_rgbimg
test test_rgbimg skipped --  No module named rgbimg
test_rotor
test_sax
test test_sax skipped --  cannot import name expat
test_select
test_sha
test_signal
test_socket
test_sre
test test_sre failed -- Writing: "sre.match(r'(a)|(b)', 'b').start(1)", expected: ''
test_strftime
test test_strftime crashed -- exceptions.OverflowError: integer multiplication
test_string
test_strop
test_struct
test test_struct crashed -- exceptions.OverflowError: integer multiplication
test_sunaudiodev
test test_sunaudiodev skipped --  No module named sunaudiodev
test_thread
Traceback (most recent call last):
  File "./Lib/test/test_thread.py", line 21, in task
    delay = random.random() * numtasks
  File "/home/roland/perso/src/sourceforge/python/dist/src/Lib/whrandom.py", line 71, in random
    x = (171 * x) % 30269
OverflowError: integer multiplication

-------------------------------------------------------

Date: 2000-Oct-03 09:03
By: jhylton

Comment:
Two more questions:
1) What platform?  Is this a 64-bit machine?  A regular x86?
2) Could you run this under gdb and report where exactly the error is being generated?  The exception is raised in Objects/intobject.c.  I would set a breakpoint at the top of int_mul() and step through the function.


-------------------------------------------------------

Date: 2000-Oct-03 09:32
By: lo-lan-do

Comment:
1) Regular i686 (sez uname).
2) It seems that ah and bh are 1 and not 0 like they should.
A bit of printf-debugging shows me that LONG_BIT/2 is 32,
so somehow 1 >> 32 != 0, which seems most strange and
bizarre to me.  On the other hand, gcc tells me the following
when I compile:

intobject.c: In function `int_mul':
intobject.c:327: warning: right shift count >= width of type

I hope he [gcc] still does the rshift, but I'm no gcc guru.
Hope this helps...
-------------------------------------------------------

Date: 2000-Oct-03 10:01
By: jhylton

Comment:
This does help.  The compiler warning is a bad sign.  I notice that you're using a more recent version of gcc than I have installed.  I'll try building with a newer gcc, but in the interim it may help if you compile the following test program:

#include <stdio.h>
#include <ctype.h>

#ifndef CHAR_BIT
#define CHAR_BIT 8
#endif

#ifndef LONG_BIT
#define LONG_BIT (CHAR_BIT * sizeof(long))
#endif

int main()
{
    int a, b;
    a = 1;
    b = a;
    a = a >> (LONG_BIT / 2);
    printf("CHAR_BIT = %d, LONG_BIT = %d\n", CHAR_BIT, LONG_BIT);
    printf("%d >> %d == %d\n", b, LONG_BIT/2, a);
    return 0;
}

On my system it compiles without warning using gcc -Wall and produces the following output:

CHAR_BIT = 8, LONG_BIT = 32
1 >> 16 == 0

What output do you get?  What is sizeof(long) on your platform?  Does ctype.h define CHAR_BIT or LONG_BIT?

-------------------------------------------------------

Date: 2000-Oct-03 10:23
By: lo-lan-do

Comment:
Your test program compiles without warning and
gives the same results as yours here.
sizeof(long) is 4, limits.h defines CHAR_BIT to be 8.
LONG_BIT is defined in bits/xopen_lim.h to be 32.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115919&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 18:30:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 10:30:30 -0700
Subject: [Python-bugs-list] [Bug #115844] OverflowError: integer multiplication
Message-ID: <200010031730.KAA25000@bush.i.sourceforge.net>

Bug #115844, was updated on 2000-Oct-02 06:27
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: OverflowError: integer multiplication

Details: 
Python2.0b2 compiled from source on a full RH7.0 install:


Python 2.0b2 (#2, Sep 27 2000, 11:40:58) 
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> a = 5 * 5
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>>

Follow-Ups:

Date: 2000-Oct-02 06:39
By: gvanrossum

Comment:
Something very basic is wrong. What output does the test suite give? ("make test"). Please see the README for digging into this.

Note that you submitted your bug report anonymously. We can't help you very effectively unless we can exchange email with you!
-------------------------------------------------------

Date: 2000-Oct-03 08:27
By: jhylton

Comment:
Strange! Another bug about integer multiplication overflow.  The other one is on a Debian install.

-------------------------------------------------------

Date: 2000-Oct-03 10:21
By: gvanrossum

Comment:
Could it be a 64-bit bug? Otherwise I suspect a GCC bug, or a 64-bit GCC bug. Note that GCC 2.96 is bleeding edge!
-------------------------------------------------------

Date: 2000-Oct-03 10:30
By: fdrake

Comment:
I don't see any reference to GCC 2.96 on the GCC website (http://gcc.gnu.org/).  PythonLabs should be a RH7.0 box to perform testing.

This may be a duplicate of #1159191.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115844&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 18:30:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 10:30:58 -0700
Subject: [Python-bugs-list] [Bug #115919] Integer multiplication overflow
Message-ID: <200010031730.KAA17076@delerium.i.sourceforge.net>

Bug #115919, was updated on 2000-Oct-03 08:01
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: Integer multiplication overflow

Details: roland@cachemir ~ $ python2.0 
Python 2.0b2 (#3, Oct  3 2000, 16:30:25) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> 1+1
2
>>> 1*1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>> 

Last CVS update 2000-10-03 around 14:00 UTC.  Last before that was some weeks ago, sorry for not being precise.  Compiled with ./configure --prefix=/usr/local/ && make, su and make install.  Only personal change is the use of readline in Modules/Setup.local.  Did I do something wrong?

Follow-Ups:

Date: 2000-Oct-03 08:25
By: jhylton

Comment:
What happens when you run "make test"?  It looks like there is something fundamentally broken, but I can't tell what it is.  If 1*1 fails, I expect the rest of the test suite to also report errors.


-------------------------------------------------------

Date: 2000-Oct-03 08:38
By: lo-lan-do

Comment:
make test shows me plenty of lines looking like this one (except the name of the test changes):

test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication

I also get messages along the lines of 'test test_dbm skipped --  No module named dbm', but I guess these ones are OK.
-------------------------------------------------------

Date: 2000-Oct-03 08:40
By: jhylton

Comment:
Can you include the complete output?

-------------------------------------------------------

Date: 2000-Oct-03 09:02
By: lo-lan-do

Comment:
[In case the bug would be caused by a recent upgrade to a beta glibc, I tried the '1*1' test with Python 1.5.2.  No bug visible there.]

$ make distclean && ./configure --prefix=/usr/local/ && make
$ make test &> test.log

It seems that 'make test' somehow hangs when testing threads, so I cut at that point.  I hope the relevant info is shown before that point.
Here goes...

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Unhandled exception in thread:
test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication
test_opcodes
test_operations
test_builtin
test test_builtin crashed -- exceptions.OverflowError: integer multiplication
test_exceptions
test_types
test test_types crashed -- exceptions.OverflowError: integer multiplication
test_MimeWriter
test_StringIO
test_al
test test_al skipped --  No module named al
test_array
test test_array crashed -- exceptions.OverflowError: integer multiplication
test_atexit
test_audioop
test test_audioop skipped --  No module named audioop
test_augassign
test test_augassign crashed -- exceptions.OverflowError: integer multiplication
test_binascii
test_binhex
test test_binhex crashed -- exceptions.OverflowError: integer multiplication
test_bsddb
test_cd
test test_cd skipped --  No module named cd
test_cfgparser
test test_cfgparser crashed -- exceptions.OverflowError: integer multiplication
test_cgi
test test_cgi crashed -- exceptions.OverflowError: integer multiplication
test_cl
test test_cl skipped --  No module named cl
test_class
test_cmath
test_compile
test_contains
test_cookie
test test_cookie crashed -- exceptions.OverflowError: integer multiplication
test_cpickle
test_crypt
test test_crypt skipped --  No module named crypt
test_dbm
test test_dbm skipped --  No module named dbm
test_dl
test test_dl skipped --  No module named dl
test_dospath
test_errno
test_extcall
test_fcntl
test_file
test_fork1
test_format
test_gc
test_gdbm
test test_gdbm skipped --  No module named gdbm
test_getopt
test_gettext
test test_gettext crashed -- exceptions.OverflowError: integer multiplication
test_gl
test test_gl skipped --  No module named gl
test_grp
test_gzip
test test_gzip skipped --  No module named zlib
test_hash
test_imageop
test test_imageop skipped --  No module named imageop
test_imgfile
test test_imgfile skipped --  No module named imgfile
test_largefile
test test_largefile skipped --  platform does not have largefile support
test_linuxaudiodev
test test_linuxaudiodev skipped --  No module named linuxaudiodev
test_long
test test_long crashed -- exceptions.OverflowError: integer multiplication
test_longexp
test_math
test_md5
test_mimetools
test test_mimetools crashed -- exceptions.AttributeError: encode
test_minidom
test test_minidom skipped --  No module named pyexpat
test_mmap
test test_mmap crashed -- exceptions.OverflowError: integer multiplication
test_new
test_nis
test test_nis skipped --  No module named nis
test_ntpath
test_openpty
test_operator
test test_operator failed -- Writing: 'mul(5, 2) = <class exceptions.OverflowError at 0x818f41c>: 10 expected', expected: 'testing:
 neg\012testing: or_\012testing: pos\012testing: repeat\012testing: rshift'
test_parser
test_pickle
test_pkg
test_poll
test test_poll crashed -- exceptions.OverflowError: integer multiplication
test_popen2
test_posixpath
test_pow
test test_pow crashed -- exceptions.OverflowError: integer multiplication
test_pty
test test_pty skipped --  No module named termios
test_pwd
test_pyexpat
test test_pyexpat skipped --  cannot import name expat
test_re
test test_re crashed -- exceptions.OverflowError: integer multiplication
test_regex
test_rfc822
test test_rfc822 crashed -- exceptions.OverflowError: integer multiplication
test_rgbimg
test test_rgbimg skipped --  No module named rgbimg
test_rotor
test_sax
test test_sax skipped --  cannot import name expat
test_select
test_sha
test_signal
test_socket
test_sre
test test_sre failed -- Writing: "sre.match(r'(a)|(b)', 'b').start(1)", expected: ''
test_strftime
test test_strftime crashed -- exceptions.OverflowError: integer multiplication
test_string
test_strop
test_struct
test test_struct crashed -- exceptions.OverflowError: integer multiplication
test_sunaudiodev
test test_sunaudiodev skipped --  No module named sunaudiodev
test_thread
Traceback (most recent call last):
  File "./Lib/test/test_thread.py", line 21, in task
    delay = random.random() * numtasks
  File "/home/roland/perso/src/sourceforge/python/dist/src/Lib/whrandom.py", line 71, in random
    x = (171 * x) % 30269
OverflowError: integer multiplication

-------------------------------------------------------

Date: 2000-Oct-03 09:03
By: jhylton

Comment:
Two more questions:
1) What platform?  Is this a 64-bit machine?  A regular x86?
2) Could you run this under gdb and report where exactly the error is being generated?  The exception is raised in Objects/intobject.c.  I would set a breakpoint at the top of int_mul() and step through the function.


-------------------------------------------------------

Date: 2000-Oct-03 09:32
By: lo-lan-do

Comment:
1) Regular i686 (sez uname).
2) It seems that ah and bh are 1 and not 0 like they should.
A bit of printf-debugging shows me that LONG_BIT/2 is 32,
so somehow 1 >> 32 != 0, which seems most strange and
bizarre to me.  On the other hand, gcc tells me the following
when I compile:

intobject.c: In function `int_mul':
intobject.c:327: warning: right shift count >= width of type

I hope he [gcc] still does the rshift, but I'm no gcc guru.
Hope this helps...
-------------------------------------------------------

Date: 2000-Oct-03 10:01
By: jhylton

Comment:
This does help.  The compiler warning is a bad sign.  I notice that you're using a more recent version of gcc than I have installed.  I'll try building with a newer gcc, but in the interim it may help if you compile the following test program:

#include <stdio.h>
#include <ctype.h>

#ifndef CHAR_BIT
#define CHAR_BIT 8
#endif

#ifndef LONG_BIT
#define LONG_BIT (CHAR_BIT * sizeof(long))
#endif

int main()
{
    int a, b;
    a = 1;
    b = a;
    a = a >> (LONG_BIT / 2);
    printf("CHAR_BIT = %d, LONG_BIT = %d\n", CHAR_BIT, LONG_BIT);
    printf("%d >> %d == %d\n", b, LONG_BIT/2, a);
    return 0;
}

On my system it compiles without warning using gcc -Wall and produces the following output:

CHAR_BIT = 8, LONG_BIT = 32
1 >> 16 == 0

What output do you get?  What is sizeof(long) on your platform?  Does ctype.h define CHAR_BIT or LONG_BIT?

-------------------------------------------------------

Date: 2000-Oct-03 10:23
By: lo-lan-do

Comment:
Your test program compiles without warning and
gives the same results as yours here.
sizeof(long) is 4, limits.h defines CHAR_BIT to be 8.
LONG_BIT is defined in bits/xopen_lim.h to be 32.
-------------------------------------------------------

Date: 2000-Oct-03 10:30
By: lo-lan-do

Comment:
Now if I replace LONG_BIT/2 by LONG_BIT in your test program:
roland@cachemir /tmp $ gcc -Wall test.c && ./a.out 
test.c: In function `main':
test.c:20: warning: right shift count >= width of type
CHAR_BIT = 8, LONG_BIT = 32
1 >> 32 == 1
roland@cachemir /tmp $ 

So I guess it's really something to do with gcc.  Drat.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115919&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 18:21:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 10:21:38 -0700
Subject: [Python-bugs-list] [Bug #115844] OverflowError: integer multiplication
Message-ID: <200010031721.KAA16676@delerium.i.sourceforge.net>

Bug #115844, was updated on 2000-Oct-02 06:27
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Irreproducible
Priority: 3
Summary: OverflowError: integer multiplication

Details: 
Python2.0b2 compiled from source on a full RH7.0 install:


Python 2.0b2 (#2, Sep 27 2000, 11:40:58) 
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> a = 5 * 5
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>>

Follow-Ups:

Date: 2000-Oct-02 06:39
By: gvanrossum

Comment:
Something very basic is wrong. What output does the test suite give? ("make test"). Please see the README for digging into this.

Note that you submitted your bug report anonymously. We can't help you very effectively unless we can exchange email with you!
-------------------------------------------------------

Date: 2000-Oct-03 08:27
By: jhylton

Comment:
Strange! Another bug about integer multiplication overflow.  The other one is on a Debian install.

-------------------------------------------------------

Date: 2000-Oct-03 10:21
By: gvanrossum

Comment:
Could it be a 64-bit bug? Otherwise I suspect a GCC bug, or a 64-bit GCC bug. Note that GCC 2.96 is bleeding edge!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115844&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 18:23:49 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 10:23:49 -0700
Subject: [Python-bugs-list] [Bug #115919] Integer multiplication overflow
Message-ID: <200010031723.KAA16819@delerium.i.sourceforge.net>

Bug #115919, was updated on 2000-Oct-03 08:01
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: Integer multiplication overflow

Details: roland@cachemir ~ $ python2.0 
Python 2.0b2 (#3, Oct  3 2000, 16:30:25) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> 1+1
2
>>> 1*1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>> 

Last CVS update 2000-10-03 around 14:00 UTC.  Last before that was some weeks ago, sorry for not being precise.  Compiled with ./configure --prefix=/usr/local/ && make, su and make install.  Only personal change is the use of readline in Modules/Setup.local.  Did I do something wrong?

Follow-Ups:

Date: 2000-Oct-03 08:25
By: jhylton

Comment:
What happens when you run "make test"?  It looks like there is something fundamentally broken, but I can't tell what it is.  If 1*1 fails, I expect the rest of the test suite to also report errors.


-------------------------------------------------------

Date: 2000-Oct-03 08:38
By: lo-lan-do

Comment:
make test shows me plenty of lines looking like this one (except the name of the test changes):

test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication

I also get messages along the lines of 'test test_dbm skipped --  No module named dbm', but I guess these ones are OK.
-------------------------------------------------------

Date: 2000-Oct-03 08:40
By: jhylton

Comment:
Can you include the complete output?

-------------------------------------------------------

Date: 2000-Oct-03 09:02
By: lo-lan-do

Comment:
[In case the bug would be caused by a recent upgrade to a beta glibc, I tried the '1*1' test with Python 1.5.2.  No bug visible there.]

$ make distclean && ./configure --prefix=/usr/local/ && make
$ make test &> test.log

It seems that 'make test' somehow hangs when testing threads, so I cut at that point.  I hope the relevant info is shown before that point.
Here goes...

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Unhandled exception in thread:
test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication
test_opcodes
test_operations
test_builtin
test test_builtin crashed -- exceptions.OverflowError: integer multiplication
test_exceptions
test_types
test test_types crashed -- exceptions.OverflowError: integer multiplication
test_MimeWriter
test_StringIO
test_al
test test_al skipped --  No module named al
test_array
test test_array crashed -- exceptions.OverflowError: integer multiplication
test_atexit
test_audioop
test test_audioop skipped --  No module named audioop
test_augassign
test test_augassign crashed -- exceptions.OverflowError: integer multiplication
test_binascii
test_binhex
test test_binhex crashed -- exceptions.OverflowError: integer multiplication
test_bsddb
test_cd
test test_cd skipped --  No module named cd
test_cfgparser
test test_cfgparser crashed -- exceptions.OverflowError: integer multiplication
test_cgi
test test_cgi crashed -- exceptions.OverflowError: integer multiplication
test_cl
test test_cl skipped --  No module named cl
test_class
test_cmath
test_compile
test_contains
test_cookie
test test_cookie crashed -- exceptions.OverflowError: integer multiplication
test_cpickle
test_crypt
test test_crypt skipped --  No module named crypt
test_dbm
test test_dbm skipped --  No module named dbm
test_dl
test test_dl skipped --  No module named dl
test_dospath
test_errno
test_extcall
test_fcntl
test_file
test_fork1
test_format
test_gc
test_gdbm
test test_gdbm skipped --  No module named gdbm
test_getopt
test_gettext
test test_gettext crashed -- exceptions.OverflowError: integer multiplication
test_gl
test test_gl skipped --  No module named gl
test_grp
test_gzip
test test_gzip skipped --  No module named zlib
test_hash
test_imageop
test test_imageop skipped --  No module named imageop
test_imgfile
test test_imgfile skipped --  No module named imgfile
test_largefile
test test_largefile skipped --  platform does not have largefile support
test_linuxaudiodev
test test_linuxaudiodev skipped --  No module named linuxaudiodev
test_long
test test_long crashed -- exceptions.OverflowError: integer multiplication
test_longexp
test_math
test_md5
test_mimetools
test test_mimetools crashed -- exceptions.AttributeError: encode
test_minidom
test test_minidom skipped --  No module named pyexpat
test_mmap
test test_mmap crashed -- exceptions.OverflowError: integer multiplication
test_new
test_nis
test test_nis skipped --  No module named nis
test_ntpath
test_openpty
test_operator
test test_operator failed -- Writing: 'mul(5, 2) = <class exceptions.OverflowError at 0x818f41c>: 10 expected', expected: 'testing:
 neg\012testing: or_\012testing: pos\012testing: repeat\012testing: rshift'
test_parser
test_pickle
test_pkg
test_poll
test test_poll crashed -- exceptions.OverflowError: integer multiplication
test_popen2
test_posixpath
test_pow
test test_pow crashed -- exceptions.OverflowError: integer multiplication
test_pty
test test_pty skipped --  No module named termios
test_pwd
test_pyexpat
test test_pyexpat skipped --  cannot import name expat
test_re
test test_re crashed -- exceptions.OverflowError: integer multiplication
test_regex
test_rfc822
test test_rfc822 crashed -- exceptions.OverflowError: integer multiplication
test_rgbimg
test test_rgbimg skipped --  No module named rgbimg
test_rotor
test_sax
test test_sax skipped --  cannot import name expat
test_select
test_sha
test_signal
test_socket
test_sre
test test_sre failed -- Writing: "sre.match(r'(a)|(b)', 'b').start(1)", expected: ''
test_strftime
test test_strftime crashed -- exceptions.OverflowError: integer multiplication
test_string
test_strop
test_struct
test test_struct crashed -- exceptions.OverflowError: integer multiplication
test_sunaudiodev
test test_sunaudiodev skipped --  No module named sunaudiodev
test_thread
Traceback (most recent call last):
  File "./Lib/test/test_thread.py", line 21, in task
    delay = random.random() * numtasks
  File "/home/roland/perso/src/sourceforge/python/dist/src/Lib/whrandom.py", line 71, in random
    x = (171 * x) % 30269
OverflowError: integer multiplication

-------------------------------------------------------

Date: 2000-Oct-03 09:03
By: jhylton

Comment:
Two more questions:
1) What platform?  Is this a 64-bit machine?  A regular x86?
2) Could you run this under gdb and report where exactly the error is being generated?  The exception is raised in Objects/intobject.c.  I would set a breakpoint at the top of int_mul() and step through the function.


-------------------------------------------------------

Date: 2000-Oct-03 09:32
By: lo-lan-do

Comment:
1) Regular i686 (sez uname).
2) It seems that ah and bh are 1 and not 0 like they should.
A bit of printf-debugging shows me that LONG_BIT/2 is 32,
so somehow 1 >> 32 != 0, which seems most strange and
bizarre to me.  On the other hand, gcc tells me the following
when I compile:

intobject.c: In function `int_mul':
intobject.c:327: warning: right shift count >= width of type

I hope he [gcc] still does the rshift, but I'm no gcc guru.
Hope this helps...
-------------------------------------------------------

Date: 2000-Oct-03 10:01
By: jhylton

Comment:
This does help.  The compiler warning is a bad sign.  I notice that you're using a more recent version of gcc than I have installed.  I'll try building with a newer gcc, but in the interim it may help if you compile the following test program:

#include <stdio.h>
#include <ctype.h>

#ifndef CHAR_BIT
#define CHAR_BIT 8
#endif

#ifndef LONG_BIT
#define LONG_BIT (CHAR_BIT * sizeof(long))
#endif

int main()
{
    int a, b;
    a = 1;
    b = a;
    a = a >> (LONG_BIT / 2);
    printf("CHAR_BIT = %d, LONG_BIT = %d\n", CHAR_BIT, LONG_BIT);
    printf("%d >> %d == %d\n", b, LONG_BIT/2, a);
    return 0;
}

On my system it compiles without warning using gcc -Wall and produces the following output:

CHAR_BIT = 8, LONG_BIT = 32
1 >> 16 == 0

What output do you get?  What is sizeof(long) on your platform?  Does ctype.h define CHAR_BIT or LONG_BIT?

-------------------------------------------------------

Date: 2000-Oct-03 10:23
By: lo-lan-do

Comment:
Your test program compiles without warning and
gives the same results as yours here.
sizeof(long) is 4, limits.h defines CHAR_BIT to be 8.
LONG_BIT is defined in bits/xopen_lim.h to be 32.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115919&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 19:06:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 11:06:18 -0700
Subject: [Python-bugs-list] [Bug #115143] Python sometimes complains about continue in an except
Message-ID: <200010031806.LAA18513@delerium.i.sourceforge.net>

Bug #115143, was updated on 2000-Sep-22 14:57
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Closed
Resolution: Duplicate
Bug Group: None
Priority: 4
Summary: Python sometimes complains about continue in an except

Details: If a continue statement occurs in the second try/except
statement nested within another try statement, it complains
about the second continue.  For example, this code generates a SyntaxError:

    for i in range(10):
        try:
            try:
                pass
            except:
                continue
            try:
                pass
            except:
                continue
        except:
            pass

while this is fine:

    for i in range(10):
        try:
            pass
        except:
            continue
        try:
            pass
        except:
            continue

This problem exists in both 1.5.2 and 2.0b1.

A workaround is to raise "continue" from the inner 
try/except statements and catch it in the outer try/except:

    for i in range(10):
        try:
            try:
                pass
            except:
                raise "continue"
            try:
                pass
            except:
                raise "continue"
        except "continue":
            continue
        except:
            pass



Follow-Ups:

Date: 2000-Oct-03 11:06
By: gvanrossum

Comment:
This really is a duplicate of #110830, which was "resolved" as a feature request (i.e. won't be fixed any time soon).

A 'continue' inside a 'try' clause is invalid (because it's too complicated to generate code for it that cleans up the try block). Your continue is still inside a 'try' clause -- it is inside the *outer* 'try' clause! So it's the same bug.

You don't need two inner try-except clauses with a continue stmt to reproduce this; one is enough (it complains about the last one due to the way the code generator signals errors).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115143&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 19:17:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 11:17:57 -0700
Subject: [Python-bugs-list] [Bug #115844] OverflowError: integer multiplication
Message-ID: <200010031817.LAA26864@bush.i.sourceforge.net>

Bug #115844, was updated on 2000-Oct-02 06:27
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: OverflowError: integer multiplication

Details: 
Python2.0b2 compiled from source on a full RH7.0 install:


Python 2.0b2 (#2, Sep 27 2000, 11:40:58) 
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> a = 5 * 5
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>>

Follow-Ups:

Date: 2000-Oct-02 06:39
By: gvanrossum

Comment:
Something very basic is wrong. What output does the test suite give? ("make test"). Please see the README for digging into this.

Note that you submitted your bug report anonymously. We can't help you very effectively unless we can exchange email with you!
-------------------------------------------------------

Date: 2000-Oct-03 08:27
By: jhylton

Comment:
Strange! Another bug about integer multiplication overflow.  The other one is on a Debian install.

-------------------------------------------------------

Date: 2000-Oct-03 10:21
By: gvanrossum

Comment:
Could it be a 64-bit bug? Otherwise I suspect a GCC bug, or a 64-bit GCC bug. Note that GCC 2.96 is bleeding edge!
-------------------------------------------------------

Date: 2000-Oct-03 10:30
By: fdrake

Comment:
I don't see any reference to GCC 2.96 on the GCC website (http://gcc.gnu.org/).  PythonLabs should be a RH7.0 box to perform testing.

This may be a duplicate of #1159191.
-------------------------------------------------------

Date: 2000-Oct-03 11:17
By: jhylton

Comment:
This bug has also been reported on a system using gcc2.95, so I'm going try with that version of GCC.  It doesn't sound like this is a 64-bit platform; does RH7 run on a 64-bit platform?  It does appear that the problem is caused by LONG_BIT being too big resulting in a bogus shift.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115844&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 19:19:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 11:19:56 -0700
Subject: [Python-bugs-list] [Bug #115919] Integer multiplication overflow
Message-ID: <200010031819.LAA27008@bush.i.sourceforge.net>

Bug #115919, was updated on 2000-Oct-03 08:01
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: Integer multiplication overflow

Details: roland@cachemir ~ $ python2.0 
Python 2.0b2 (#3, Oct  3 2000, 16:30:25) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> 1+1
2
>>> 1*1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>> 

Last CVS update 2000-10-03 around 14:00 UTC.  Last before that was some weeks ago, sorry for not being precise.  Compiled with ./configure --prefix=/usr/local/ && make, su and make install.  Only personal change is the use of readline in Modules/Setup.local.  Did I do something wrong?

Follow-Ups:

Date: 2000-Oct-03 08:25
By: jhylton

Comment:
What happens when you run "make test"?  It looks like there is something fundamentally broken, but I can't tell what it is.  If 1*1 fails, I expect the rest of the test suite to also report errors.


-------------------------------------------------------

Date: 2000-Oct-03 08:38
By: lo-lan-do

Comment:
make test shows me plenty of lines looking like this one (except the name of the test changes):

test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication

I also get messages along the lines of 'test test_dbm skipped --  No module named dbm', but I guess these ones are OK.
-------------------------------------------------------

Date: 2000-Oct-03 08:40
By: jhylton

Comment:
Can you include the complete output?

-------------------------------------------------------

Date: 2000-Oct-03 09:02
By: lo-lan-do

Comment:
[In case the bug would be caused by a recent upgrade to a beta glibc, I tried the '1*1' test with Python 1.5.2.  No bug visible there.]

$ make distclean && ./configure --prefix=/usr/local/ && make
$ make test &> test.log

It seems that 'make test' somehow hangs when testing threads, so I cut at that point.  I hope the relevant info is shown before that point.
Here goes...

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Unhandled exception in thread:
test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication
test_opcodes
test_operations
test_builtin
test test_builtin crashed -- exceptions.OverflowError: integer multiplication
test_exceptions
test_types
test test_types crashed -- exceptions.OverflowError: integer multiplication
test_MimeWriter
test_StringIO
test_al
test test_al skipped --  No module named al
test_array
test test_array crashed -- exceptions.OverflowError: integer multiplication
test_atexit
test_audioop
test test_audioop skipped --  No module named audioop
test_augassign
test test_augassign crashed -- exceptions.OverflowError: integer multiplication
test_binascii
test_binhex
test test_binhex crashed -- exceptions.OverflowError: integer multiplication
test_bsddb
test_cd
test test_cd skipped --  No module named cd
test_cfgparser
test test_cfgparser crashed -- exceptions.OverflowError: integer multiplication
test_cgi
test test_cgi crashed -- exceptions.OverflowError: integer multiplication
test_cl
test test_cl skipped --  No module named cl
test_class
test_cmath
test_compile
test_contains
test_cookie
test test_cookie crashed -- exceptions.OverflowError: integer multiplication
test_cpickle
test_crypt
test test_crypt skipped --  No module named crypt
test_dbm
test test_dbm skipped --  No module named dbm
test_dl
test test_dl skipped --  No module named dl
test_dospath
test_errno
test_extcall
test_fcntl
test_file
test_fork1
test_format
test_gc
test_gdbm
test test_gdbm skipped --  No module named gdbm
test_getopt
test_gettext
test test_gettext crashed -- exceptions.OverflowError: integer multiplication
test_gl
test test_gl skipped --  No module named gl
test_grp
test_gzip
test test_gzip skipped --  No module named zlib
test_hash
test_imageop
test test_imageop skipped --  No module named imageop
test_imgfile
test test_imgfile skipped --  No module named imgfile
test_largefile
test test_largefile skipped --  platform does not have largefile support
test_linuxaudiodev
test test_linuxaudiodev skipped --  No module named linuxaudiodev
test_long
test test_long crashed -- exceptions.OverflowError: integer multiplication
test_longexp
test_math
test_md5
test_mimetools
test test_mimetools crashed -- exceptions.AttributeError: encode
test_minidom
test test_minidom skipped --  No module named pyexpat
test_mmap
test test_mmap crashed -- exceptions.OverflowError: integer multiplication
test_new
test_nis
test test_nis skipped --  No module named nis
test_ntpath
test_openpty
test_operator
test test_operator failed -- Writing: 'mul(5, 2) = <class exceptions.OverflowError at 0x818f41c>: 10 expected', expected: 'testing:
 neg\012testing: or_\012testing: pos\012testing: repeat\012testing: rshift'
test_parser
test_pickle
test_pkg
test_poll
test test_poll crashed -- exceptions.OverflowError: integer multiplication
test_popen2
test_posixpath
test_pow
test test_pow crashed -- exceptions.OverflowError: integer multiplication
test_pty
test test_pty skipped --  No module named termios
test_pwd
test_pyexpat
test test_pyexpat skipped --  cannot import name expat
test_re
test test_re crashed -- exceptions.OverflowError: integer multiplication
test_regex
test_rfc822
test test_rfc822 crashed -- exceptions.OverflowError: integer multiplication
test_rgbimg
test test_rgbimg skipped --  No module named rgbimg
test_rotor
test_sax
test test_sax skipped --  cannot import name expat
test_select
test_sha
test_signal
test_socket
test_sre
test test_sre failed -- Writing: "sre.match(r'(a)|(b)', 'b').start(1)", expected: ''
test_strftime
test test_strftime crashed -- exceptions.OverflowError: integer multiplication
test_string
test_strop
test_struct
test test_struct crashed -- exceptions.OverflowError: integer multiplication
test_sunaudiodev
test test_sunaudiodev skipped --  No module named sunaudiodev
test_thread
Traceback (most recent call last):
  File "./Lib/test/test_thread.py", line 21, in task
    delay = random.random() * numtasks
  File "/home/roland/perso/src/sourceforge/python/dist/src/Lib/whrandom.py", line 71, in random
    x = (171 * x) % 30269
OverflowError: integer multiplication

-------------------------------------------------------

Date: 2000-Oct-03 09:03
By: jhylton

Comment:
Two more questions:
1) What platform?  Is this a 64-bit machine?  A regular x86?
2) Could you run this under gdb and report where exactly the error is being generated?  The exception is raised in Objects/intobject.c.  I would set a breakpoint at the top of int_mul() and step through the function.


-------------------------------------------------------

Date: 2000-Oct-03 09:32
By: lo-lan-do

Comment:
1) Regular i686 (sez uname).
2) It seems that ah and bh are 1 and not 0 like they should.
A bit of printf-debugging shows me that LONG_BIT/2 is 32,
so somehow 1 >> 32 != 0, which seems most strange and
bizarre to me.  On the other hand, gcc tells me the following
when I compile:

intobject.c: In function `int_mul':
intobject.c:327: warning: right shift count >= width of type

I hope he [gcc] still does the rshift, but I'm no gcc guru.
Hope this helps...
-------------------------------------------------------

Date: 2000-Oct-03 10:01
By: jhylton

Comment:
This does help.  The compiler warning is a bad sign.  I notice that you're using a more recent version of gcc than I have installed.  I'll try building with a newer gcc, but in the interim it may help if you compile the following test program:

#include <stdio.h>
#include <ctype.h>

#ifndef CHAR_BIT
#define CHAR_BIT 8
#endif

#ifndef LONG_BIT
#define LONG_BIT (CHAR_BIT * sizeof(long))
#endif

int main()
{
    int a, b;
    a = 1;
    b = a;
    a = a >> (LONG_BIT / 2);
    printf("CHAR_BIT = %d, LONG_BIT = %d\n", CHAR_BIT, LONG_BIT);
    printf("%d >> %d == %d\n", b, LONG_BIT/2, a);
    return 0;
}

On my system it compiles without warning using gcc -Wall and produces the following output:

CHAR_BIT = 8, LONG_BIT = 32
1 >> 16 == 0

What output do you get?  What is sizeof(long) on your platform?  Does ctype.h define CHAR_BIT or LONG_BIT?

-------------------------------------------------------

Date: 2000-Oct-03 10:23
By: lo-lan-do

Comment:
Your test program compiles without warning and
gives the same results as yours here.
sizeof(long) is 4, limits.h defines CHAR_BIT to be 8.
LONG_BIT is defined in bits/xopen_lim.h to be 32.
-------------------------------------------------------

Date: 2000-Oct-03 10:30
By: lo-lan-do

Comment:
Now if I replace LONG_BIT/2 by LONG_BIT in your test program:
roland@cachemir /tmp $ gcc -Wall test.c && ./a.out 
test.c: In function `main':
test.c:20: warning: right shift count >= width of type
CHAR_BIT = 8, LONG_BIT = 32
1 >> 32 == 1
roland@cachemir /tmp $ 

So I guess it's really something to do with gcc.  Drat.
-------------------------------------------------------

Date: 2000-Oct-03 11:19
By: jhylton

Comment:
I'll see if I can reproduce the problem with GCC 2.95.2

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115919&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 19:27:23 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 11:27:23 -0700
Subject: [Python-bugs-list] [Bug #115690] Dr. Watson error on Python2.0b2 Idle 0.6 WinNT4.0 SP6
Message-ID: <200010031827.LAA27251@bush.i.sourceforge.net>

Bug #115690, was updated on 2000-Sep-29 14:55
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: Dr. Watson error on Python2.0b2 Idle 0.6 WinNT4.0 SP6

Details: I get a Dr. Watson error:

    pythonw.exe
    Exception: access violation (0xc0000005), 
    Address: 0x00e31652

when I run the following code in Idle 0.6, using Edit->Run Script:

---%<---cut---%<---

import unicodedata
for c in range(0x10000):
    x=unichr(c)
    try:
        b = unicodedata.numeric(x)
        #print "numeric:", repr(x)
        try:
            a = unicodedata.digit(x)
            if a != b:
                print "bad" , repr(x)
        except:
            print "Numeric but not digit", hex(c), x.encode("utf8"), \
                  "numeric ->", b
    except:
        pass

---%<---cut---%<---

(This code was recently posted on python-dev)

I've modified my .idle file, adding 

    [EditorWindow]
    font-name=tahoma


Follow-Ups:

Date: 2000-Sep-29 21:42
By: jhylton

Comment:
Marc-Andre can you check whether this is a Unicode bug that is going to come up with or without idle.  If it seems Idle specific, please assign it to Guido or Tim.  If not, it's yours :-).


-------------------------------------------------------

Date: 2000-Oct-03 10:23
By: lemburg

Comment:
I can't reproduce this on Linux, so it seems that it is related to the way TCL/Tk
displays UTF-8 data. Another possibility would be an optimization error
which doesn't happen with gcc.

Tim, could you try this on Windows and possibly tell me where the segfault
occurs in the code ?

-------------------------------------------------------

Date: 2000-Oct-03 11:27
By: gvanrossum

Comment:
Can't reproduce it on Win98SE either. (And I did try setting font-name to tahoma.)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115690&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 19:36:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 11:36:01 -0700
Subject: [Python-bugs-list] [Bug #115143] Python sometimes complains about continue in an except
Message-ID: <200010031836.LAA19761@delerium.i.sourceforge.net>

Bug #115143, was updated on 2000-Sep-22 14:57
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Closed
Resolution: Duplicate
Bug Group: None
Priority: 4
Summary: Python sometimes complains about continue in an except

Details: If a continue statement occurs in the second try/except
statement nested within another try statement, it complains
about the second continue.  For example, this code generates a SyntaxError:

    for i in range(10):
        try:
            try:
                pass
            except:
                continue
            try:
                pass
            except:
                continue
        except:
            pass

while this is fine:

    for i in range(10):
        try:
            pass
        except:
            continue
        try:
            pass
        except:
            continue

This problem exists in both 1.5.2 and 2.0b1.

A workaround is to raise "continue" from the inner 
try/except statements and catch it in the outer try/except:

    for i in range(10):
        try:
            try:
                pass
            except:
                raise "continue"
            try:
                pass
            except:
                raise "continue"
        except "continue":
            continue
        except:
            pass



Follow-Ups:

Date: 2000-Oct-03 11:06
By: gvanrossum

Comment:
This really is a duplicate of #110830, which was "resolved" as a feature request (i.e. won't be fixed any time soon).

A 'continue' inside a 'try' clause is invalid (because it's too complicated to generate code for it that cleans up the try block). Your continue is still inside a 'try' clause -- it is inside the *outer* 'try' clause! So it's the same bug.

You don't need two inner try-except clauses with a continue stmt to reproduce this; one is enough (it complains about the last one due to the way the code generator signals errors).
-------------------------------------------------------

Date: 2000-Oct-03 11:36
By: montanaro

Comment:
I don't think I explained the problem properly.  The compiler should either complain about both of the continue statements or neither of them, not just the second one.  I believe that was what confused the person who originally described this problem on c.l.py.  He couldn't figure out why the first one was okay but the second one wasn't.

In any case, I added a reference to this bugid to the note in pep-0042, so whoever tackles the "continue inside a try block" problem will know to check this.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115143&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 20:09:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 12:09:26 -0700
Subject: [Python-bugs-list] [Bug #115040] sre behavior differes from pre
Message-ID: <200010031909.MAA28939@bush.i.sourceforge.net>

Bug #115040, was updated on 2000-Sep-21 19:53
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: sre behavior differes from pre

Details: This may not be a bug, but it caused some regexes of mine that match under pre to fail under sre.

With pre, an embeded flag like "(?x)" can appear anywhere within a regex and it affects the entire regex. In sre, the position of "(?x)" is important; only after it appears does VERBOSE mode seem to be in effect and whitespace is ignored. If people haven't been careful to place the "(?x)" at the very beginning of the regex, VERBOSE regexes with this defect in existing code may fail to match when sre is used as a drop-in replacement for pre.

Also, and in contrast, "(?s)" doen't seem sensitive to position under sre; wherever it appears in the regex, DOTALL seems to affect the entire regex.


Follow-Ups:

Date: 2000-Sep-21 20:15
By: tim_one

Comment:
Assigned to Fredrik.  FWIW, years ago I never did figure out Perl did in all cases simply by trying stuff; e.g., it's easy to construct cases where whether (?x) is recognized as such depends on whether you're assuming verbose mode or not while you're parsing!
-------------------------------------------------------

Date: 2000-Sep-30 21:38
By: gvanrossum

Comment:
Fredrik, any chance of fixing this?
-------------------------------------------------------

Date: 2000-Oct-03 12:09
By: effbot

Comment:
Changed SRE to *reparse* the (sub)pattern if the whitespace
flag changes.  This isn't optimal, but it appears to do the
right thing.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115040&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 21:34:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 13:34:48 -0700
Subject: [Python-bugs-list] [Bug #115143] Python sometimes complains about continue in an except
Message-ID: <200010032034.NAA24826@delerium.i.sourceforge.net>

Bug #115143, was updated on 2000-Sep-22 14:57
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Closed
Resolution: Duplicate
Bug Group: None
Priority: 4
Summary: Python sometimes complains about continue in an except

Details: If a continue statement occurs in the second try/except
statement nested within another try statement, it complains
about the second continue.  For example, this code generates a SyntaxError:

    for i in range(10):
        try:
            try:
                pass
            except:
                continue
            try:
                pass
            except:
                continue
        except:
            pass

while this is fine:

    for i in range(10):
        try:
            pass
        except:
            continue
        try:
            pass
        except:
            continue

This problem exists in both 1.5.2 and 2.0b1.

A workaround is to raise "continue" from the inner 
try/except statements and catch it in the outer try/except:

    for i in range(10):
        try:
            try:
                pass
            except:
                raise "continue"
            try:
                pass
            except:
                raise "continue"
        except "continue":
            continue
        except:
            pass



Follow-Ups:

Date: 2000-Oct-03 11:06
By: gvanrossum

Comment:
This really is a duplicate of #110830, which was "resolved" as a feature request (i.e. won't be fixed any time soon).

A 'continue' inside a 'try' clause is invalid (because it's too complicated to generate code for it that cleans up the try block). Your continue is still inside a 'try' clause -- it is inside the *outer* 'try' clause! So it's the same bug.

You don't need two inner try-except clauses with a continue stmt to reproduce this; one is enough (it complains about the last one due to the way the code generator signals errors).
-------------------------------------------------------

Date: 2000-Oct-03 11:36
By: montanaro

Comment:
I don't think I explained the problem properly.  The compiler should either complain about both of the continue statements or neither of them, not just the second one.  I believe that was what confused the person who originally described this problem on c.l.py.  He couldn't figure out why the first one was okay but the second one wasn't.

In any case, I added a reference to this bugid to the note in pep-0042, so whoever tackles the "continue inside a try block" problem will know to check this.

-------------------------------------------------------

Date: 2000-Oct-03 13:34
By: gvanrossum

Comment:
OK. That's a very different issue. Normally the compiler complains about the *first* problem it finds. In this case it complained about the *last* problem. That's a separate ToTo, and I'll add it to PEP-42 momentarily.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115143&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 21:36:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 13:36:52 -0700
Subject: [Python-bugs-list] [Bug #115845] sre: maxsplit as keyword argument
Message-ID: <200010032036.NAA32531@bush.i.sourceforge.net>

Bug #115845, was updated on 2000-Oct-02 06:31
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: sre: maxsplit as keyword argument

Details: Split gives TypeError when called as a method of compiled
regular expression object with maxsplit as keyword argument.
This error is only in sre, pre is OK.

Python 1.6 (#2, Sep  6 2000, 18:20:07) [C] on osf1V4
>>> import re
>>> patt = re.compile(' ')
>>> list = patt.split("a b c",50)              # OK
>>> list = re.split(' ',"a b c",maxsplit=50)   # OK     
>>> list = patt.split("a b c",maxsplit=50)     # ERROR
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: this function takes no keyword arguments

>>> import pre
>>> patt = pre.compile(' ')
>>> list = patt.split("a b c",maxsplit=50)     # OK



Follow-Ups:

Date: 2000-Oct-03 08:12
By: effbot

Comment:
maxcount is a positional argument, and you shouldn't
really use keyword arguments unless the documentation
*explicitly* tells you to...

(but we might fix this anyway -- stay tuned)
-------------------------------------------------------

Date: 2000-Oct-03 13:36
By: effbot

Comment:
fixed in 2.0c1.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115845&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 21:37:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 13:37:56 -0700
Subject: [Python-bugs-list] [Bug #115912] GC crashes in 2.0b1 and 2.0b2
Message-ID: <200010032037.NAA32570@bush.i.sourceforge.net>

Bug #115912, was updated on 2000-Oct-03 06:43
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 5
Summary: GC crashes in 2.0b1 and 2.0b2

Details: Forwarded message from Andrew Reutter at Origin:


We are experiencing crashes in both Python 2.0b1 and 2.0b2 that appear to be
related to cyclical garbage collection.
A summary of the scenario follows:

We have embedded Python as a .lib into a much larger project.  We build this
project in both Win32 and Solaris environments.
On Win32 _only_, we use custom memory management routines in order to
facilitate the tracking of memory.
The memory manager also fills memory with specific bit patterns upon both
allocation and deallocation in order to detect the use of uninitialized or
freed memory.

After several minutes of successful execution, we see a reproducible crash
in gc_list_remove.
It receives a node pointer which points to memory filled with our memory
initialization bit pattern (0xCD),
indicating to us that the allocation was successful, but the object was
never fully initialized or placed in a gc_list.
Although this crash occurs at the same point in our code each time, the
address of the node pointer varies with each execution,
making it impossible to set a breakpoint when the node allocation takes
place.

Since we only tweak memory management under Win32, our memory manager is
unlikely to be the culprit.
The crash disappears when Python is compiled without the WITH_CYCLE_GC
definition.

Unfortunately, the project is both extremely large and the source is closed,
so we are unable to send you a quick methodology for reproduction of our
crash.  We would nonetheless like to assist you in solving this problem in
any way we _are_ able, so let us know.
Are there any other reported bugs in gcmodule.c (we noted that some were
fixed when b2 was released)?
Is there any information you could provide us that would help us debug it
ourselves?  An example would be to direct us to the single method by which
all objects are allocated, if such a method exists.



Follow-Ups:

Date: 2000-Oct-03 13:37
By: loewis

Comment:
It might help to find out which C extension modules are used; i.e. printing sys.modules shortly before the crash. Have all extension modules been recompiled with the 2.0bx header files?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115912&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 21:41:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 13:41:08 -0700
Subject: [Python-bugs-list] [Bug #115341] Todays CVS python dumps core in gcmodule.c?!
Message-ID: <200010032041.NAA32728@bush.i.sourceforge.net>

Bug #115341, was updated on 2000-Sep-26 01:43
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Todays CVS python dumps core in gcmodule.c?!

Details: While tracing a bug in my own code, I got a core dump from python.
Since it is extremely difficult to find out WHERE in my 58k lines of code this
happens,  I can't just make a small test case. I thought at this stage it might
be useful to report anyway.

no203[204]lehmann%3% gdb =python core        
GNU gdb 19991004
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `/usr/local/nonius/bin/python /usr/local/nonius/app/gui/to
p.py new orient x.non'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdb.so.3...done.
Reading symbols from /lib/libpthread.so.0...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libutil.so.1...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/stropmodule.so.
..done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/timemodule.so..
.done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/_tkinter.so...
done.
---Type <return> to continue, or q <return> to quit---
Reading symbols from /usr/local/nonius/lib/libBLT24.so...done.
Reading symbols from /usr/local/nonius/lib/libtk8.3.so...done.
Reading symbols from /usr/local/nonius/lib/libtcl8.3.so...done.
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/mathmodule.so..
.done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/md5module.so...
done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/multi
array.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/_nump
y.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/umath
.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/structmodule.so
...done.
Reading symbols from /usr/local/nonius/app/misc/linux/_ntoolsmodule.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/_socketmodule.s
o...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/cStringIO.so...
done.
Reading symbols from /lib/libnss_files.so.2...done.
---Type <return> to continue, or q <return> to quit---
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/lapac
k_lite.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/selectmodule.so
...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/gdbmmodule.so..
.done.
Reading symbols from /usr/lib/libgdbm.so.2...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/cPickle.so...
done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/ranli
b.so...done.
#0  update_refs (containers=0x80bfec0) at ./gcmodule.c:150
150                     gc->gc_refs = PyObject_FROM_GC(gc)->ob_refcnt;
(gdb) where
#0  update_refs (containers=0x80bfec0) at ./gcmodule.c:150
#1  0x808ae9b in collect (young=0x80bfec0, old=0x80bfecc) at ./gcmodule.c:382
#2  0x808b0cc in collect_generations () at ./gcmodule.c:488
#3  0x808b10f in _PyGC_Insert (op=0x8703824) at ./gcmodule.c:507
#4  0x807fbe4 in PyTuple_New (size=3) at tupleobject.c:87
#5  0x80561df in eval_code2 (co=0x8260518, globals=0x823fcd4, locals=0x0, 
    args=0x824d258, argcount=2, kws=0x8780190, kwcount=5, defs=0x8268f50, 
    defcount=1, owner=0x82699e4) at ceval.c:1561
#6  0x8057e3b in call_function (func=0x8269a7c, arg=0x87616cc, kw=0x87743ac)
    at ceval.c:2744
#7  0x8057a4b in PyEval_CallObjectWithKeywords (func=0x87816bc, arg=0x87616cc, 
    kw=0x87743ac) at ceval.c:2588
#8  0x806df7b in PyInstance_New (class=0x82699e4, arg=0x87616cc, kw=0x87743ac)
    at classobject.c:463
#9  0x8057b51 in call_builtin (func=0x82699e4, arg=0x87616cc, kw=0x87743ac)
    at ceval.c:2625
#10 0x8057a58 in PyEval_CallObjectWithKeywords (func=0x82699e4, arg=0x87616cc, 
    kw=0x87743ac) at ceval.c:2590
#11 0x8056bab in eval_code2 (co=0x81f0c58, globals=0x8201b1c, locals=0x0, 
    args=0x875cd8c, argcount=2, kws=0x875cd94, kwcount=0, defs=0x8201248, 
    defcount=1, owner=0x81fe94c) at ceval.c:1923
#12 0x805687c in eval_code2 (co=0x81f2de8, globals=0x8201b1c, locals=0x0, 
    args=0x866e2b0, argcount=2, kws=0x866e2b8, kwcount=0, defs=0x0, 
---Type <return> to continue, or q <return> to quit---
    defcount=0, owner=0x8201a4c) at ceval.c:1822
#13 0x805687c in eval_code2 (co=0x81ef9d0, globals=0x8201b1c, locals=0x0, 
    args=0x8203314, argcount=2, kws=0x820331c, kwcount=0, defs=0x8201098, 
    defcount=1, owner=0x81f4e8c) at ceval.c:1822
#14 0x805687c in eval_code2 (co=0x83d1d10, globals=0x83d8044, locals=0x0, 
    args=0x8202840, argcount=2, kws=0x8202848, kwcount=0, defs=0x0, 
    defcount=0, owner=0x85fc974) at ceval.c:1822
#15 0x805687c in eval_code2 (co=0x83cff98, globals=0x83d8044, locals=0x0, 
    args=0x8202068, argcount=1, kws=0x820206c, kwcount=0, defs=0x0, 
    defcount=0, owner=0x85fc974) at ceval.c:1822
#16 0x805687c in eval_code2 (co=0x83af368, globals=0x83b2574, locals=0x0, 
    args=0x86134f0, argcount=2, kws=0x0, kwcount=0, defs=0x83b2120, 
    defcount=1, owner=0x83c8b8c) at ceval.c:1822
#17 0x8057e3b in call_function (func=0x83bcc7c, arg=0x860fcac, kw=0x0)
    at ceval.c:2744
#18 0x8057a4b in PyEval_CallObjectWithKeywords (func=0x8203194, arg=0x860fcac, 
    kw=0x0) at ceval.c:2588
#19 0x806df7b in PyInstance_New (class=0x85fc974, arg=0x860fcac, kw=0x0)
    at classobject.c:463
#20 0x8057b51 in call_builtin (func=0x85fc974, arg=0x860fcac, kw=0x0)
    at ceval.c:2625
#21 0x8057a58 in PyEval_CallObjectWithKeywords (func=0x85fc974, arg=0x860fcac, 
    kw=0x0) at ceval.c:2590
---Type <return> to continue, or q <return> to quit---
#22 0x8056bab in eval_code2 (co=0x8163568, globals=0x80caecc, locals=0x0, 
    args=0x80d562c, argcount=2, kws=0x80d5634, kwcount=0, defs=0x0, 
    defcount=0, owner=0x860e81c) at ceval.c:1923
#23 0x805687c in eval_code2 (co=0x810e8f8, globals=0x80caecc, 
    locals=0x80caecc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
    defcount=0, owner=0x0) at ceval.c:1822
#24 0x80545d7 in PyEval_EvalCode (co=0x810e8f8, globals=0x80caecc, 
    locals=0x80caecc) at ceval.c:319
#25 0x80660b4 in run_node (n=0x80d3cc8, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", globals=0x80caecc, 
    locals=0x80caecc) at pythonrun.c:886
#26 0x8066079 in run_err_node (n=0x80d3cc8, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", globals=0x80caecc, 
    locals=0x80caecc) at pythonrun.c:874
#27 0x8066057 in PyRun_FileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", start=257, 
    globals=0x80caecc, locals=0x80caecc, closeit=1) at pythonrun.c:866
#28 0x8065821 in PyRun_SimpleFileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", closeit=1)
    at pythonrun.c:579
#29 0x80654d0 in PyRun_AnyFileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", closeit=1)
    at pythonrun.c:459
---Type <return> to continue, or q <return> to quit---
#30 0x8051a40 in Py_Main (argc=4, argv=0xbffff814) at main.c:289
#31 0x8051566 in main (argc=5, argv=0xbffff814) at python.c:10
(gdb) 
(gdb) list
145     static void
146     update_refs(PyGC_Head *containers)
147     {
148             PyGC_Head *gc = containers->gc_next;
149             for (; gc != containers; gc=gc->gc_next) {
150                     gc->gc_refs = PyObject_FROM_GC(gc)->ob_refcnt;
151             }
152     }
153
154     static int
(gdb) print gc
$1 = (PyGC_Head *) 0x0


Follow-Ups:

Date: 2000-Sep-26 04:31
By: gvanrossum

Comment:
Neil, can you have a look at this?
-------------------------------------------------------

Date: 2000-Sep-26 09:44
By: nascheme

Comment:
Since I can't reproduce this bug here are some things to 
try:

- compile Python with Py_DEBUG defined
- compile Python with Py_DEBUG and without GC
- at the start of your application call
  gc.set_debug(gc.DEBUG_LEAK) and gc.set_threshold(1)
- at the start of your application disable GC with gc.disable()
- recompile your extension modules
-------------------------------------------------------

Date: 2000-Sep-26 09:45
By: nascheme

Comment:
Since I can't reproduce this bug here are some things to 
try:

- compile Python with Py_DEBUG defined
- compile Python with Py_DEBUG and without GC
- at the start of your application call
  gc.set_debug(gc.DEBUG_LEAK) and gc.set_threshold(1)
- at the start of your application disable GC with gc.disable()
- recompile your extension modules
- checkout Python from a few days ago (cvs -D option)
-------------------------------------------------------

Date: 2000-Sep-29 01:39
By: hooft

Comment:
Sorry that I have not been able to react quicker. Unfortunately I won't be here in the weekend either.

- Py_Debug didn't change anything, it still dumped core.
- set_debug and set_threshold(1) : it still dumps core.

#0  update_refs (containers=0x80be6f8) at ./gcmodule.c:150
150                     gc->gc_refs = PyObject_FROM_GC(gc)->ob_refcnt;
(gdb) where
#0  update_refs (containers=0x80be6f8) at ./gcmodule.c:150
#1  0x8079db3 in collect (young=0x80be6f8, old=0x80be6f8) at ./gcmodule.c:382
#2  0x8079f57 in collect_generations () at ./gcmodule.c:471
#3  0x807a044 in _PyGC_Insert (op=0x87b1c14) at ./gcmodule.c:507
#4  0x80589cb in PyTuple_New (size=3) at tupleobject.c:87

(gdb) print containers
$50 = (PyGC_Head *) 0x80be6f8
(gdb) print gc
$51 = (PyGC_Head *) 0x0

I checked the first 50 or so references, no NULL encountered yet.

- gc.disable makes it continue, but I get all kinds of weird trouble
   with Tk:
Error: 3
AttributeError Exception in Tk callback
  Function: <function <lambda> at 0x87cb8e4> (type: <type 'function'>)
  Args: ('3652', '1', '1', '0', '1', '0', '-449121110', '0', '102', '0', '??', '0', '??', '0', '.138093276.141021828.141028308.142397076.142399772.142400300.142414228', '7', '544', '454', '1')
Traceback (innermost last):
  File "/usr/local/nonius/lib/python2.0/site-packages/Pmw/Pmw_0_8_4/lib/PmwBase.py", line 1668, in __call__
    args = apply(self.subst, args)
  File "/usr/local/nonius/lib/python2.0/lib-tk/Tkinter.py", line 1048, in _substitute
    e.widget = self._nametowidget(W)
  File "/usr/local/nonius/lib/python2.0/lib-tk/Tkinter.py", line 973, in nametowidget
    w = w._root()
  File "/usr/local/nonius/lib/python2.0/lib-tk/Tkinter.py", line 1012, in _root
    while w.master: w = w.master
AttributeError: 'Frame' instance has no attribute 'master'

And when the program terminates:
  [73562 refs]
  Print left references? [ny] n
  zsh: segmentation fault (core dumped)  collect new orient
  collect new orient  6.18s user 0.33s system 2% cpu 4:06.65 total

(gdb) where
#0  0x400e7129 in chunk_free (ar_ptr=0x4017bd60, p=0x87ce2f8) at malloc.c:3111
#1  0x400e6fba in __libc_free (mem=0x87ce300) at malloc.c:3023
#2  0x805941e in PyTuple_Fini () at tupleobject.c:562
#3  0x80762b6 in Py_Finalize () at pythonrun.c:243
#4  0x80777f4 in Py_Exit (sts=0) at pythonrun.c:1120
#5  0x8076d5e in PyErr_PrintEx (set_sys_last_vars=1) at pythonrun.c:708
#6  0x8076c6a in PyErr_Print () at pythonrun.c:671
#7  0x80769c1 in PyRun_SimpleFileEx (fp=0x80ce428, filename=0xbffff9a3 "/usr/local/nonius/app/gui/top.py", closeit=1) at pythonrun.c:582
#8  0x8076610 in PyRun_AnyFileEx (fp=0x80ce428, filename=0xbffff9a3 "/usr/local/nonius/app/gui/top.py", closeit=1) at pythonrun.c:459
#9  0x8051c40 in Py_Main (argc=3, argv=0xbffff834) at main.c:289
#10 0x8051756 in main (argc=4, argv=0xbffff834) at python.c:10

- to be able to enable Py_DEBUG I had to recompile all extension modules, so that point I skipped.
- I don't think "cvs -D" will be very useful, it is just the first time I'm seeing
   this here, but it might have been present already for a long time.

I am at a loss. I really have no clue how to reduce the program while maintaining the problem to make a simple test case. I can't even trace where my program is failing?!?!?
-------------------------------------------------------

Date: 2000-Oct-03 13:41
By: loewis

Comment:
I notice a module _ntoolsmodule.so is used. Has this module been recompiled with the current header files? Is source code of this module available for review?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115341&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 21:46:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 13:46:06 -0700
Subject: [Python-bugs-list] [Bug #110681] memory leak in loops (PR#398)
Message-ID: <200010032046.NAA00479@bush.i.sourceforge.net>

Bug #110681, was updated on 2000-Jul-31 14:14
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: memory leak in loops (PR#398)

Details: Jitterbug-Id: 398
Submitted-By: ingo.adler@synacon.ch
Date: Fri, 14 Jul 2000 05:10:25 -0400 (EDT)
Version: 1.5.2
OS: win nt


I have a simple loop, which produces memory leaks at every call (36 bytes):

{
    Py_SetProgramName("pythontest.exe");
    Py_Initialize();

    initxmodulec();

    PyRun_SimpleString("print \"... Python started ...\"");

    PyRun_SimpleString("import xmodule");
    PyRun_SimpleString("from xmodule import *");

// The Loop
    PyRun_SimpleString(
        "y = Y()\n"
        "for i in range(1000):\n"
        "\tx = y.getX()\n"
        "\tx.getNumber()\n"
    );




    PyRun_SimpleString("print \"... Python finished ...\"");
    Py_Finalize();
}

X and Y are my classes implemented in C++, connected to Python via Swig Shadow
Classes:

class X {

public:
    float getNumber()
    {
        return 12.2;
    }
};

class Y {
    X* pX;

public:
    Y()
    {
        pX = new X;
    }

    ~Y()
    {
        delete pX;
    }

    X* getX()
    {
        return pX;
    }
};

The classes and python are compiled statically with CBuilder5.0, Swig1.3a3 (same
problem with swig1.1).

I tested the application with "CodeGuard", which shows the memory leaks.
For every call in the loop there is an entry like this (I translated it to
English):

Error. 0x300010 (Thread 0x013B):
resource leak: memory block (0x15422F0) was never released

memory leak (0x015422F0) [size: 36 Byte] was assigned with malloc
call stack:
   0x0045ED5D(=pythontest.exe:0x01:05DD5D)
G:\Projects\src\fortuna\Python\Objects\stringobject.c#145
   0x00401EFD(=pythontest.exe:0x01:000EFD)
G:\Projects\src\fortuna\test\xmodule_wrap.c#769
   0x0040255D(=pythontest.exe:0x01:00155D)
G:\Projects\src\fortuna\test\xmodule_wrap.c#941
   0x0041BA79(=pythontest.exe:0x01:01AA79)
G:\Projects\src\fortuna\Python\Python\ceval.c#2359
   0x0041B912(=pythontest.exe:0x01:01A912)
G:\Projects\src\fortuna\Python\Python\ceval.c#2324
   0x0040EE3E(=pythontest.exe:0x01:00DE3E)
G:\Projects\src\fortuna\Python\Python\bltinmodule.c#12


The Code for line 941:

#define Y_getX(_swigobj)  (_swigobj->getX())
static PyObject *_wrap_Y_getX(PyObject *self, PyObject *args) {
    Y  *_arg0;
    PyObject  *_resultobj,*_argo0=0;
    X  *_result;
    self = self;
    if(!PyArg_ParseTuple(args,"O:Y_getX",&_argo0)) 
        return NULL;
    if ((SWIG_ConvertPtr(_argo0,(void **) &_arg0,SWIGTYPE_Y_p,1)) == -1) return
NULL;
    _result = (X *)Y_getX(_arg0);
/*941*/ _resultobj = SWIG_NewPointerObj((void *) _result, SWIGTYPE_X_p);
    return _resultobj;
}

The Code for line 769:

SWIGSTATICRUNTIME(PyObject *)
SWIG_NewPointerObj(void *ptr, _swig_type_info *type) {
  char result[512];
  PyObject *robj;
  if (!ptr) {
    Py_INCREF(Py_None);
    return Py_None;
  }
#ifdef SWIG_COBJECT_TYPES
  robj = PyCObject_FromVoidPtrAndDesc((void *) ptr, type->name, NULL);
#else
  SWIG_MakePtr(result,ptr,type);
/*769*/  robj = PyString_FromString(result);
#endif
  return robj;
}


Ingo Adler



====================================================================
Audit trail:
Tue Jul 25 07:27:50 2000	guido	changed notes
Tue Jul 25 07:27:50 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-01 14:01
By: none

Comment:
From: "M.-A. Lemburg" <mal@lemburg.com>
Subject: Re: [Python-bugs-list] memory leak in loops (PR#398)
Date: Fri, 14 Jul 2000 11:22:51 +0200

ingo.adler@synacon.ch wrote:
> 
> Full_Name: ingo adler
> Version: 1.5.2
> OS: win nt
> Submission from: megazh-d-201.agrinet.ch (212.28.158.201)
> 
> I have a simple loop, which produces memory leaks at every call (36 bytes):
> 
> {
>     Py_SetProgramName("pythontest.exe");
>     Py_Initialize();
> 
>     initxmodulec();
> 
>     PyRun_SimpleString("print \"... Python started ...\"");
> 
>     PyRun_SimpleString("import xmodule");
>     PyRun_SimpleString("from xmodule import *");
> 
> // The Loop
>     PyRun_SimpleString(
>         "y = Y()\n"
>         "for i in range(1000):\n"
>         "\tx = y.getX()\n"
>         "\tx.getNumber()\n"

Could be that SWIG doesn't get a chance to cleanup the shadow
object for x and y. Try adding

del x,y

as final script line.

Note that SWIG uses Python strings to represent pointers in
C++. It uses an internal table to store these.

>     );
> 
>     PyRun_SimpleString("print \"... Python finished ...\"");
>     Py_Finalize();
> }
> 
> X and Y are my classes implemented in C++, connected to Python via Swig Shadow
> Classes:
> 
> class X {
> 
> public:
>     float getNumber()
>     {
>         return 12.2;
>     }
> };
> 
> class Y {
>     X* pX;
> 
> public:
>     Y()
>     {
>         pX = new X;
>     }
> 
>     ~Y()
>     {
>         delete pX;
>     }
> 
>     X* getX()
>     {
>         return pX;
>     }
> };
> 
> The classes and python are compiled statically with CBuilder5.0, Swig1.3a3 (same
> problem with swig1.1).
> 
> I tested the application with "CodeGuard", which shows the memory leaks.
> For every call in the loop there is an entry like this (I translated it to
> English):
> 
> Error. 0x300010 (Thread 0x013B):
> resource leak: memory block (0x15422F0) was never released
> 
> memory leak (0x015422F0) [size: 36 Byte] was assigned with malloc
> call stack:
>    0x0045ED5D(=pythontest.exe:0x01:05DD5D)
> G:\Projects\src\fortuna\Python\Objects\stringobject.c#145
>    0x00401EFD(=pythontest.exe:0x01:000EFD)
> G:\Projects\src\fortuna\test\xmodule_wrap.c#769
>    0x0040255D(=pythontest.exe:0x01:00155D)
> G:\Projects\src\fortuna\test\xmodule_wrap.c#941
>    0x0041BA79(=pythontest.exe:0x01:01AA79)
> G:\Projects\src\fortuna\Python\Python\ceval.c#2359
>    0x0041B912(=pythontest.exe:0x01:01A912)
> G:\Projects\src\fortuna\Python\Python\ceval.c#2324
>    0x0040EE3E(=pythontest.exe:0x01:00DE3E)
> G:\Projects\src\fortuna\Python\Python\bltinmodule.c#12
> 
> The Code for line 941:
> 
> #define Y_getX(_swigobj)  (_swigobj->getX())
> static PyObject *_wrap_Y_getX(PyObject *self, PyObject *args) {
>     Y  *_arg0;
>     PyObject  *_resultobj,*_argo0=0;
>     X  *_result;
>     self = self;
>     if(!PyArg_ParseTuple(args,"O:Y_getX",&_argo0))
>         return NULL;
>     if ((SWIG_ConvertPtr(_argo0,(void **) &_arg0,SWIGTYPE_Y_p,1)) == -1) return
> NULL;
>     _result = (X *)Y_getX(_arg0);
> /*941*/ _resultobj = SWIG_NewPointerObj((void *) _result, SWIGTYPE_X_p);
>     return _resultobj;
> }
> 
> The Code for line 769:
> 
> SWIGSTATICRUNTIME(PyObject *)
> SWIG_NewPointerObj(void *ptr, _swig_type_info *type) {
>   char result[512];
>   PyObject *robj;
>   if (!ptr) {
>     Py_INCREF(Py_None);
>     return Py_None;
>   }
> #ifdef SWIG_COBJECT_TYPES
>   robj = PyCObject_FromVoidPtrAndDesc((void *) ptr, type->name, NULL);
> #else
>   SWIG_MakePtr(result,ptr,type);
> /*769*/  robj = PyString_FromString(result);
> #endif
>   return robj;
> }
> 
> Ingo Adler
> 
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Ingo Adler <ingo.adler@synacon.ch>
Subject: Re: [Python-bugs-list] memory leak in loops (PR#398)
Date: Fri, 14 Jul 2000 11:40:42 +0100

This is a multi-part message in MIME format.
--------------6D29988B97CCE77010389AE2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> > // The Loop
> >     PyRun_SimpleString(
> >         "y = Y()\n"
> >         "for i in range(1000):\n"
> >         "\tx = y.getX()\n"
> >         "\tx.getNumber()\n"
>
> Could be that SWIG doesn't get a chance to cleanup the shadow
> object for x and y. Try adding
>
> del x,y
>
> as final script line.
>
> Note that SWIG uses Python strings to represent pointers in
> C++. It uses an internal table to store these.
>

I changed the code to:

    PyRun_SimpleString(
        "y = Y()\n"
        "for i in range(1000):\n"
        "\tx = y.getX()\n"
        "\tx.getNumber()\n"
        "\tdel x\n"
    );

It doesn't change anything.

The memory leak only occurs when I call x.getNumber() in the loop. Otherwise x =
y.getX() is memory leak free.

Ingo Adler

--------------6D29988B97CCE77010389AE2
Content-Type: text/x-vcard; charset=us-ascii;
 name="ingo.adler.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ingo Adler
Content-Disposition: attachment;
 filename="ingo.adler.vcf"

begin:vcard 
n:Adler;Ingo
tel;cell:+41-79-3786792
tel;fax:+41-41-7103244
tel;home:+41-41-7103268
tel;work:+41-41-8111500
x-mozilla-html:FALSE
url:www.synacon.ch
org:Synacon GmbH
adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland
version:2.1
email;internet:ingo.adler@synacon.ch
title:Dipl.-Inform.
fn:Ingo Adler
end:vcard

--------------6D29988B97CCE77010389AE2--



-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: "M.-A. Lemburg" <mal@lemburg.com>
Subject: Re: [Python-bugs-list] memory leak in loops (PR#398)
Date: Fri, 14 Jul 2000 12:13:13 +0200

Ingo Adler wrote:
> 
> > > // The Loop
> > >     PyRun_SimpleString(
> > >         "y = Y()\n"
> > >         "for i in range(1000):\n"
> > >         "\tx = y.getX()\n"
> > >         "\tx.getNumber()\n"
> >
> > Could be that SWIG doesn't get a chance to cleanup the shadow
> > object for x and y. Try adding
> >
> > del x,y
> >
> > as final script line.
> >
> > Note that SWIG uses Python strings to represent pointers in
> > C++. It uses an internal table to store these.
> >
> 
> I changed the code to:
> 
>     PyRun_SimpleString(
>         "y = Y()\n"
>         "for i in range(1000):\n"
>         "\tx = y.getX()\n"
>         "\tx.getNumber()\n"
>         "\tdel x\n"
>     );
> 
> It doesn't change anything.
> 
> The memory leak only occurs when I call x.getNumber() in the loop. Otherwise x =
> y.getX() is memory leak free.

Two other possibilities:

1. Python interns the string object used by SWIG to represent
the point. It should then free the memory in the Py_Finalize()
call. If it doesn't, there's a bug to be found ;-)

2. SWIG has the leak. Try using the alternative method of
defining SWIG_COBJECT_TYPES (don't know how this is done --
it seems to be new in SWIG).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Ingo Adler <ingo.adler@synacon.ch>
Subject: Re: [Python-bugs-list] memory leak in loops (PR#398)
Date: Fri, 14 Jul 2000 12:45:02 +0100

This is a multi-part message in MIME format.
--------------82393A6779ADCFC3A2ADE19E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I could reproduce the problem with Developer Studio 6.0.

If anyone wants the project to test it - I can provide it.

Ingo Adler

--------------82393A6779ADCFC3A2ADE19E
Content-Type: text/x-vcard; charset=us-ascii;
 name="ingo.adler.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ingo Adler
Content-Disposition: attachment;
 filename="ingo.adler.vcf"

begin:vcard 
n:Adler;Ingo
tel;cell:+41-79-3786792
tel;fax:+41-41-7103244
tel;home:+41-41-7103268
tel;work:+41-41-8111500
x-mozilla-html:FALSE
url:www.synacon.ch
org:Synacon GmbH
adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland
version:2.1
email;internet:ingo.adler@synacon.ch
title:Dipl.-Inform.
fn:Ingo Adler
end:vcard

--------------82393A6779ADCFC3A2ADE19E--



-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: "Mark Hammond" <mhammond@skippinet.com.au>
Subject: RE: [Python-bugs-list] memory leak in loops (PR#398)
Date: Mon, 17 Jul 2000 22:16:54 -0400

> I could reproduce the problem with Developer Studio 6.0.
>
> If anyone wants the project to test it - I can provide it.

If you can repro the problem in just a few lines of C/C++ code but with no
SWIG generated code, I would be interested.  Otherwise, I suggest you do
some more work to narrow the problem down some more; as described, there is
still too much work to be done to narrow down the problem to the cause for
me to be interested (or anyone else given the feedback to date!)

Mark.



-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Ingo Adler <ingo.adler@synacon.ch>
Subject: Re: [Python-bugs-list] memory leak in loops (PR#398)
Date: Tue, 25 Jul 2000 01:34:22 +0200

This is a multi-part message in MIME format.
--------------72A23DA082087CB843E12C92
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Mark,

I could repro the memory leaks (they seem to be the same) with a much smaller
program:

int main(int argc, char* argv[])
{
    Py_SetProgramName("pythontest.exe");
    Py_Initialize();
    PyRun_SimpleString("print \"... Python started ...\"");
    PyRun_SimpleString("print \"... Python finished ...\"");
    Py_Finalize();

    return 0;
}

There seems to be a more general problem, which includes my special problem.

Output of Code Guard (translated to English). BoundsChecker shows the same
leaks.

Ingo

Output:

Memory Block (0x014EB9B4) [Size: 37 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043515A(=pythontest.exe:0x01:03415A)
D:\projects\Python\Objects\stringobject.c#95
   0x0043A8EB(=pythontest.exe:0x01:0398EB)
D:\projects\Python\Python\marshal.c#483
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504
   0x0043AB88(=pythontest.exe:0x01:039B88)
D:\projects\Python\Python\marshal.c#568
   0x0043AD37(=pythontest.exe:0x01:039D37)
D:\projects\Python\Python\marshal.c#624
   0x0042BC54(=pythontest.exe:0x01:02AC54)
D:\projects\Python\Python\import.c#575

------------------------------------------
Error 00078. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E4858) was never freed

Memory Block (0x014E4858) [Size: 31 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00425400(=pythontest.exe:0x01:024400)
D:\projects\Python\Objects\dictobject.c#1084
   0x00433896(=pythontest.exe:0x01:032896)
D:\projects\Python\Objects\moduleobject.c#56
   0x0042B993(=pythontest.exe:0x01:02A993)
D:\projects\Python\Python\import.c#428
   0x0043B0C9(=pythontest.exe:0x01:03A0C9)
D:\projects\Python\Python\modsupport.c#82
   0x0040C68A(=pythontest.exe:0x01:00B68A)
D:\projects\Python\Python\bltinmodule.c#2393

------------------------------------------
Error 00079. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E47D0) was never freed

Memory Block (0x014E47D0) [Size: 28 Byte] was assigned with malloc
Aufrufhierarchie:
   0x00433CB3(=pythontest.exe:0x01:032CB3)
D:\projects\Python\Objects\object.c#122
   0x00424115(=pythontest.exe:0x01:023115)
D:\projects\Python\Objects\dictobject.c#124
   0x004367D3(=pythontest.exe:0x01:0357D3)
D:\projects\Python\Objects\stringobject.c#1075
   0x00425418(=pythontest.exe:0x01:024418)
D:\projects\Python\Objects\dictobject.c#1087
   0x0043387A(=pythontest.exe:0x01:03287A)
D:\projects\Python\Objects\moduleobject.c#54
   0x0042B993(=pythontest.exe:0x01:02A993)
D:\projects\Python\Python\import.c#428

------------------------------------------
Error 00080. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E47AC) was never freed

Memory Block (0x014E47AC) [Size: 32 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00425400(=pythontest.exe:0x01:024400)
D:\projects\Python\Objects\dictobject.c#1084
   0x0043387A(=pythontest.exe:0x01:03287A)
D:\projects\Python\Objects\moduleobject.c#54
   0x0042B993(=pythontest.exe:0x01:02A993)
D:\projects\Python\Python\import.c#428
   0x0043B0C9(=pythontest.exe:0x01:03A0C9)
D:\projects\Python\Python\modsupport.c#82
   0x0040C68A(=pythontest.exe:0x01:00B68A)
D:\projects\Python\Python\bltinmodule.c#2393

------------------------------------------
Error 00081. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E46E4) was never freed

Memory Block (0x014E46E4) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x004240F7(=pythontest.exe:0x01:0230F7)
D:\projects\Python\Objects\dictobject.c#120
   0x0043C27B(=pythontest.exe:0x01:03B27B)
D:\projects\Python\Python\pythonrun.c#132
   0x00402934(=pythontest.exe:0x01:001934)
G:\Projects\src\test\pythonmain.cpp#15
   0x3257DC12(=CC3250MT.DLL:0x01:07CC12)

------------------------------------------
Error 00082. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x1524000) was never freed

Memory Block (0x01524000) [Size: 12288 Byte] was assigned with malloc
Aufrufhierarchie:
   0x004243A7(=pythontest.exe:0x01:0233A7)
D:\projects\Python\Objects\dictobject.c#280
   0x004245C4(=pythontest.exe:0x01:0235C4)
D:\projects\Python\Objects\dictobject.c#370
   0x00436837(=pythontest.exe:0x01:035837)
D:\projects\Python\Objects\stringobject.c#1086
   0x00415CA9(=pythontest.exe:0x01:014CA9)
D:\projects\Python\Python\compile.c#249
   0x0043AC12(=pythontest.exe:0x01:039C12)
D:\projects\Python\Python\marshal.c#578
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504

------------------------------------------
Error 00083. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFC9C) was never freed

Memory Block (0x014EFC9C) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411EE6(=pythontest.exe:0x01:010EE6)
D:\projects\Python\Objects\classobject.c#126
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00084. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFC74) was never freed

Memory Block (0x014EFC74) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411ED6(=pythontest.exe:0x01:010ED6)
D:\projects\Python\Objects\classobject.c#125
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00085. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFC4C) was never freed

Memory Block (0x014EFC4C) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411EC6(=pythontest.exe:0x01:010EC6)
D:\projects\Python\Objects\classobject.c#124
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00086. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14F19CC) was never freed

Memory Block (0x014F19CC) [Size: 47 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00431E97(=pythontest.exe:0x01:030E97)
D:\projects\Python\Objects\listobject.c#309
   0x0041137E(=pythontest.exe:0x01:01037E)
D:\projects\Python\Python\ceval.c#2512
   0x0040F906(=pythontest.exe:0x01:00E906)
D:\projects\Python\Python\ceval.c#1503
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324
   0x0042BAD4(=pythontest.exe:0x01:02AAD4)
D:\projects\Python\Python\import.c#485

------------------------------------------
Error 00087. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14F596C) was never freed

Memory Block (0x014F596C) [Size: 32 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x0042CED6(=pythontest.exe:0x01:02BED6)
D:\projects\Python\Python\import.c#1513
   0x0042CD19(=pythontest.exe:0x01:02BD19)
D:\projects\Python\Python\import.c#1441
   0x0042CE6A(=pythontest.exe:0x01:02BE6A)
D:\projects\Python\Python\import.c#1489
   0x00409B32(=pythontest.exe:0x01:008B32)
D:\projects\Python\Python\bltinmodule.c#65

------------------------------------------
Error 00088. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EB870) was never freed

Memory Block (0x014EB870) [Size: 32 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043515A(=pythontest.exe:0x01:03415A)
D:\projects\Python\Objects\stringobject.c#95
   0x0043A8EB(=pythontest.exe:0x01:0398EB)
D:\projects\Python\Python\marshal.c#483
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504
   0x0043AB88(=pythontest.exe:0x01:039B88)
D:\projects\Python\Python\marshal.c#568
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504
   0x0043AB76(=pythontest.exe:0x01:039B76)
D:\projects\Python\Python\marshal.c#567

------------------------------------------
Error 00089. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFBDC) was never freed

Memory Block (0x014EFBDC) [Size: 34 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411C9E(=pythontest.exe:0x01:010C9E)
D:\projects\Python\Objects\classobject.c#58
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00090. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E74C4) was never freed

Memory Block (0x014E74C4) [Size: 988 Byte] was assigned with malloc
Aufrufhierarchie:
   0x00430B62(=pythontest.exe:0x01:02FB62)
D:\projects\Python\Objects\intobject.c#113
   0x00430BFD(=pythontest.exe:0x01:02FBFD)
D:\projects\Python\Objects\intobject.c#163
   0x0040C6FC(=pythontest.exe:0x01:00B6FC)
D:\projects\Python\Python\bltinmodule.c#2404
   0x0043C29A(=pythontest.exe:0x01:03B29A)
D:\projects\Python\Python\pythonrun.c#136
   0x00402934(=pythontest.exe:0x01:001934)
G:\Projects\src\test\pythonmain.cpp#15
   0x3257DC12(=CC3250MT.DLL:0x01:07CC12)

------------------------------------------
Error 00091. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E96C4) was never freed

Memory Block (0x014E96C4) [Size: 174 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0042B0D9(=pythontest.exe:0x01:02A0D9) D:\projects\Python\PC\getpathp.c#403

   0x0042B2D5(=pythontest.exe:0x01:02A2D5) D:\projects\Python\PC\getpathp.c#508

   0x0043E40C(=pythontest.exe:0x01:03D40C)
D:\projects\Python\Python\sysmodule.c#413
   0x0043C2CA(=pythontest.exe:0x01:03B2CA)
D:\projects\Python\Python\pythonrun.c#142
   0x00402934(=pythontest.exe:0x01:001934)
G:\Projects\src\test\pythonmain.cpp#15
   0x3257DC12(=CC3250MT.DLL:0x01:07CC12)

------------------------------------------
Error 00092. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EF660) was never freed

Memory Block (0x014EF660) [Size: 36 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00425400(=pythontest.exe:0x01:024400)
D:\projects\Python\Objects\dictobject.c#1084
   0x0042BA54(=pythontest.exe:0x01:02AA54)
D:\projects\Python\Python\import.c#466
   0x0042BF73(=pythontest.exe:0x01:02AF73)
D:\projects\Python\Python\import.c#724
   0x0042C876(=pythontest.exe:0x01:02B876)
D:\projects\Python\Python\import.c#1202
   0x0042D51E(=pythontest.exe:0x01:02C51E)
D:\projects\Python\Python\import.c#1755

------------------------------------------
Error 00093. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x15211C8) was never freed

Memory Block (0x015211C8) [Size: 31 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x004129EE(=pythontest.exe:0x01:0119EE)
D:\projects\Python\Objects\classobject.c#517
   0x004246DD(=pythontest.exe:0x01:0236DD)
D:\projects\Python\Objects\dictobject.c#419
   0x0042546E(=pythontest.exe:0x01:02446E)
D:\projects\Python\Objects\dictobject.c#1103
   0x0043DF2E(=pythontest.exe:0x01:03CF2E)
D:\projects\Python\Python\sysmodule.c#95

------------------------------------------
Aufgerufene Funktionen:
 delete (35 Mal)
 getchar (1 Mal)
 fflush (2 Mal)
 fputs (2 Mal)
 fwrite (2 Mal)
 vsprintf (2 Mal)
 strrchr (14 Mal)
 fclose (14 Mal)
 strspn (251 Mal)
 fread (2021 Mal)
 _fgetc (40 Mal)
 fstat (7 Mal)
 fopen (72 Mal)
 strncmp (19 Mal)
 strcmp (423 Mal)
 stat (21 Mal)
 strncpy (32 Mal)
 strchr (125 Mal)
 sprintf (2 Mal)
 memcmp (1349 Mal)
 memset (133 Mal)
 strcpy (834 Mal)
 strlen (784 Mal)
 SysFreeMem (87 Mal)
 SysGetMem (87 Mal)
 realloc (88 Mal)
 memcpy (837 Mal)
 delete[] (2 Mal)
 free (4936 Mal)
 new[] (14 Mal)
 new (40 Mal)
 calloc (5 Mal)
 malloc (4946 Mal)
Verwendete Resource-Arten:
 Datei-Stream (14 Allocs, 5 max)
 Datei-Handle (14 Allocs, 5 max)
 Objekt-Array (14 Allocs, 13 max)
 Objekt (40 Allocs, 28 max)
 Memory Block (5039 Allocs, 2448 max)
Verwendete Module:
 00400000 07/25/2000 01:06:08 G:\Projects\src\bin\pythontest.exe
 0CD00000 02/03/2000 06:00:00 g:\programme\borland\cbuilder5\bin\CG32.DLL
 201A0000 02/22/2000 05:20:00 C:\WINNT.45\TRAYHOOK.dll
 32500000 02/03/2000 06:00:00 G:\Projects\src\bin\CC3250MT.DLL
 40000000 02/03/2000 05:01:00 C:\WINNT.45\System32\VCL50.BPL
 41000000 02/03/2000 06:00:00 G:\Projects\src\bin\BORLNDMM.DLL
 52180000 08/09/1996 00:00:00 C:\WINNT.45\system32\version.dll
 61220000 12/07/1999 16:03:46 G:\Programme\Microsoft
 Hardware\Mouse\MSH_ZWF.dll
 65340000 02/18/2000 16:16:02 C:\WINNT.45\system32\oleaut32.dll
 70970000 05/09/1998 13:57:06 C:\WINNT.45\system32\SHELL32.dll
 70BD0000 03/18/1999 00:00:00 C:\WINNT.45\system32\SHLWAPI.dll
 71190000 07/22/1999 21:09:08 C:\WINNT.45\system32\MSIDLE.DLL
 71590000 03/18/1999 00:00:00 C:\WINNT.45\system32\COMCTL32.dll
 73060000 05/13/1999 12:05:00 C:\WINNT.45\System32\winspool.drv
 77660000 05/13/1999 12:05:00 C:\WINNT.45\System32\MSWSOCK.dll
 77666C35 05/13/1999 12:05:00 C:\WINNT.45\system32\wsock32.dll
 77690000 05/13/1999 12:05:00 C:\WINNT.45\system32\WS2HELP.dll
 776A0000 05/13/1999 12:05:00 C:\WINNT.45\system32\WS2_32.dll
 77710000 05/13/1999 12:05:00 C:\WINNT.45\system32\mpr.dll
 77920000 05/13/1999 12:05:00 C:\WINNT.45\System32\oledlg.dll
 779B0000 08/09/1996 00:00:00 C:\WINNT.45\system32\LZ32.dll
 77B80000 05/13/1999 12:05:00 C:\WINNT.45\system32\ole32.dll
 77D80000 05/13/1999 12:05:00 C:\WINNT.45\system32\comdlg32.dll
 77DC0000 05/13/1999 12:05:00 C:\WINNT.45\system32\ADVAPI32.dll
 77E10000 05/13/1999 12:05:00 C:\WINNT.45\system32\RPCRT4.dll
 77E70000 05/13/1999 12:05:00 C:\WINNT.45\system32\user32.dll
 77ED0000 05/13/1999 12:05:00 C:\WINNT.45\system32\GDI32.dll
 77F00000 05/13/1999 12:05:00 C:\WINNT.45\system32\kernel32.dll
 77F70000 05/13/1999 12:05:00 C:\WINNT.45\System32\ntdll.dll
 78000000 12/07/1999 05:00:00 C:\WINNT.45\system32\MSVCRT.dll
==========================================



Mark Hammond wrote:

> > I could reproduce the problem with Developer Studio 6.0.
> >
> > If anyone wants the project to test it - I can provide it.
>
> If you can repro the problem in just a few lines of C/C++ code but with no
> SWIG generated code, I would be interested.  Otherwise, I suggest you do
> some more work to narrow the problem down some more; as described, there is
> still too much work to be done to narrow down the problem to the cause for
> me to be interested (or anyone else given the feedback to date!)
>
> Mark.

--------------72A23DA082087CB843E12C92
Content-Type: text/x-vcard; charset=us-ascii;
 name="ingo.adler.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ingo Adler
Content-Disposition: attachment;
 filename="ingo.adler.vcf"

begin:vcard 
n:Adler;Ingo
tel;fax:+41-41-7103244
tel;work:+41-41-8111500
x-mozilla-html:FALSE
org:Synacon GmbH
adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland
version:2.1
email;internet:ingo.adler@synacon.ch
fn:Ingo Adler
end:vcard

--------------72A23DA082087CB843E12C92--



-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
Actually, it's hard to say whether this is worth fixing...
Could it be a SWIG problem?
-------------------------------------------------------

Date: 2000-Sep-25 12:54
By: bwarsaw

Comment:
I don't believe there is a Python bug worth fixing here.  I've done some memory use testing with Python 2.0b2 using Insure++ on Linux, both with the regular interpreter, and with the small example embedded script given below.

There are "technical" memory leaks but they are almost all related to either leaks in the OS, or global memory still in use at the time Python exits.  An example of the former is leaks in strerror() - nothing we can do about that.  An example of the latter are leaks in the string intern dictionary, and we've already decided not to do anything about that.

There no identifiable chunks of memory leaked every time through the loop so I believe the problems reported below are either related to swig, have been fixed for Python 2.0, or are of the variety described above.
-------------------------------------------------------

Date: 2000-Oct-03 07:52
By: tregnago

Comment:
I'm working on an embedded application. I've looked with CodeGuard and it detect few memory leaks( similar as reported below ) only executing "Py_Initialize()" immediatly followed by "Py_Finalize()". Are you sure that this basic example is leaks free in your case?
I'm in big problems with that, and I can't find a way to escape from that.
-------------------------------------------------------

Date: 2000-Oct-03 09:00
By: bwarsaw

Comment:
Re-opening since there really are memory leaks we can fix.
-------------------------------------------------------

Date: 2000-Oct-03 09:35
By: bwarsaw

Comment:
I found a couple of leaks that aren't explained by valid in-reference memory at program exit, or leaks in OS libraries.  Fixes are found in the following files/versions: 

Python/import.c 2.153
Objects/unicodeobject.c 2.65

The last is probably the version that contains the patch.  I haven't actually checked it in yet -- I'm waiting for confirmation from the unicode expert.  I'm still closing this bug report as fixed.

With these patches, all memory leaks now are of the variety described previously.
-------------------------------------------------------

Date: 2000-Oct-03 13:46
By: bwarsaw

Comment:
Just to update, the patch is contained in Objects/unicodeobject.c version 2.66
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110681&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 22:26:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 14:26:25 -0700
Subject: [Python-bugs-list] [Bug #115919] Integer multiplication overflow
Message-ID: <200010032126.OAA26992@delerium.i.sourceforge.net>

Bug #115919, was updated on 2000-Oct-03 08:01
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: Integer multiplication overflow

Details: roland@cachemir ~ $ python2.0 
Python 2.0b2 (#3, Oct  3 2000, 16:30:25) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> 1+1
2
>>> 1*1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>> 

Last CVS update 2000-10-03 around 14:00 UTC.  Last before that was some weeks ago, sorry for not being precise.  Compiled with ./configure --prefix=/usr/local/ && make, su and make install.  Only personal change is the use of readline in Modules/Setup.local.  Did I do something wrong?

Follow-Ups:

Date: 2000-Oct-03 08:25
By: jhylton

Comment:
What happens when you run "make test"?  It looks like there is something fundamentally broken, but I can't tell what it is.  If 1*1 fails, I expect the rest of the test suite to also report errors.


-------------------------------------------------------

Date: 2000-Oct-03 08:38
By: lo-lan-do

Comment:
make test shows me plenty of lines looking like this one (except the name of the test changes):

test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication

I also get messages along the lines of 'test test_dbm skipped --  No module named dbm', but I guess these ones are OK.
-------------------------------------------------------

Date: 2000-Oct-03 08:40
By: jhylton

Comment:
Can you include the complete output?

-------------------------------------------------------

Date: 2000-Oct-03 09:02
By: lo-lan-do

Comment:
[In case the bug would be caused by a recent upgrade to a beta glibc, I tried the '1*1' test with Python 1.5.2.  No bug visible there.]

$ make distclean && ./configure --prefix=/usr/local/ && make
$ make test &> test.log

It seems that 'make test' somehow hangs when testing threads, so I cut at that point.  I hope the relevant info is shown before that point.
Here goes...

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Unhandled exception in thread:
test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication
test_opcodes
test_operations
test_builtin
test test_builtin crashed -- exceptions.OverflowError: integer multiplication
test_exceptions
test_types
test test_types crashed -- exceptions.OverflowError: integer multiplication
test_MimeWriter
test_StringIO
test_al
test test_al skipped --  No module named al
test_array
test test_array crashed -- exceptions.OverflowError: integer multiplication
test_atexit
test_audioop
test test_audioop skipped --  No module named audioop
test_augassign
test test_augassign crashed -- exceptions.OverflowError: integer multiplication
test_binascii
test_binhex
test test_binhex crashed -- exceptions.OverflowError: integer multiplication
test_bsddb
test_cd
test test_cd skipped --  No module named cd
test_cfgparser
test test_cfgparser crashed -- exceptions.OverflowError: integer multiplication
test_cgi
test test_cgi crashed -- exceptions.OverflowError: integer multiplication
test_cl
test test_cl skipped --  No module named cl
test_class
test_cmath
test_compile
test_contains
test_cookie
test test_cookie crashed -- exceptions.OverflowError: integer multiplication
test_cpickle
test_crypt
test test_crypt skipped --  No module named crypt
test_dbm
test test_dbm skipped --  No module named dbm
test_dl
test test_dl skipped --  No module named dl
test_dospath
test_errno
test_extcall
test_fcntl
test_file
test_fork1
test_format
test_gc
test_gdbm
test test_gdbm skipped --  No module named gdbm
test_getopt
test_gettext
test test_gettext crashed -- exceptions.OverflowError: integer multiplication
test_gl
test test_gl skipped --  No module named gl
test_grp
test_gzip
test test_gzip skipped --  No module named zlib
test_hash
test_imageop
test test_imageop skipped --  No module named imageop
test_imgfile
test test_imgfile skipped --  No module named imgfile
test_largefile
test test_largefile skipped --  platform does not have largefile support
test_linuxaudiodev
test test_linuxaudiodev skipped --  No module named linuxaudiodev
test_long
test test_long crashed -- exceptions.OverflowError: integer multiplication
test_longexp
test_math
test_md5
test_mimetools
test test_mimetools crashed -- exceptions.AttributeError: encode
test_minidom
test test_minidom skipped --  No module named pyexpat
test_mmap
test test_mmap crashed -- exceptions.OverflowError: integer multiplication
test_new
test_nis
test test_nis skipped --  No module named nis
test_ntpath
test_openpty
test_operator
test test_operator failed -- Writing: 'mul(5, 2) = <class exceptions.OverflowError at 0x818f41c>: 10 expected', expected: 'testing:
 neg\012testing: or_\012testing: pos\012testing: repeat\012testing: rshift'
test_parser
test_pickle
test_pkg
test_poll
test test_poll crashed -- exceptions.OverflowError: integer multiplication
test_popen2
test_posixpath
test_pow
test test_pow crashed -- exceptions.OverflowError: integer multiplication
test_pty
test test_pty skipped --  No module named termios
test_pwd
test_pyexpat
test test_pyexpat skipped --  cannot import name expat
test_re
test test_re crashed -- exceptions.OverflowError: integer multiplication
test_regex
test_rfc822
test test_rfc822 crashed -- exceptions.OverflowError: integer multiplication
test_rgbimg
test test_rgbimg skipped --  No module named rgbimg
test_rotor
test_sax
test test_sax skipped --  cannot import name expat
test_select
test_sha
test_signal
test_socket
test_sre
test test_sre failed -- Writing: "sre.match(r'(a)|(b)', 'b').start(1)", expected: ''
test_strftime
test test_strftime crashed -- exceptions.OverflowError: integer multiplication
test_string
test_strop
test_struct
test test_struct crashed -- exceptions.OverflowError: integer multiplication
test_sunaudiodev
test test_sunaudiodev skipped --  No module named sunaudiodev
test_thread
Traceback (most recent call last):
  File "./Lib/test/test_thread.py", line 21, in task
    delay = random.random() * numtasks
  File "/home/roland/perso/src/sourceforge/python/dist/src/Lib/whrandom.py", line 71, in random
    x = (171 * x) % 30269
OverflowError: integer multiplication

-------------------------------------------------------

Date: 2000-Oct-03 09:03
By: jhylton

Comment:
Two more questions:
1) What platform?  Is this a 64-bit machine?  A regular x86?
2) Could you run this under gdb and report where exactly the error is being generated?  The exception is raised in Objects/intobject.c.  I would set a breakpoint at the top of int_mul() and step through the function.


-------------------------------------------------------

Date: 2000-Oct-03 09:32
By: lo-lan-do

Comment:
1) Regular i686 (sez uname).
2) It seems that ah and bh are 1 and not 0 like they should.
A bit of printf-debugging shows me that LONG_BIT/2 is 32,
so somehow 1 >> 32 != 0, which seems most strange and
bizarre to me.  On the other hand, gcc tells me the following
when I compile:

intobject.c: In function `int_mul':
intobject.c:327: warning: right shift count >= width of type

I hope he [gcc] still does the rshift, but I'm no gcc guru.
Hope this helps...
-------------------------------------------------------

Date: 2000-Oct-03 10:01
By: jhylton

Comment:
This does help.  The compiler warning is a bad sign.  I notice that you're using a more recent version of gcc than I have installed.  I'll try building with a newer gcc, but in the interim it may help if you compile the following test program:

#include <stdio.h>
#include <ctype.h>

#ifndef CHAR_BIT
#define CHAR_BIT 8
#endif

#ifndef LONG_BIT
#define LONG_BIT (CHAR_BIT * sizeof(long))
#endif

int main()
{
    int a, b;
    a = 1;
    b = a;
    a = a >> (LONG_BIT / 2);
    printf("CHAR_BIT = %d, LONG_BIT = %d\n", CHAR_BIT, LONG_BIT);
    printf("%d >> %d == %d\n", b, LONG_BIT/2, a);
    return 0;
}

On my system it compiles without warning using gcc -Wall and produces the following output:

CHAR_BIT = 8, LONG_BIT = 32
1 >> 16 == 0

What output do you get?  What is sizeof(long) on your platform?  Does ctype.h define CHAR_BIT or LONG_BIT?

-------------------------------------------------------

Date: 2000-Oct-03 10:23
By: lo-lan-do

Comment:
Your test program compiles without warning and
gives the same results as yours here.
sizeof(long) is 4, limits.h defines CHAR_BIT to be 8.
LONG_BIT is defined in bits/xopen_lim.h to be 32.
-------------------------------------------------------

Date: 2000-Oct-03 10:30
By: lo-lan-do

Comment:
Now if I replace LONG_BIT/2 by LONG_BIT in your test program:
roland@cachemir /tmp $ gcc -Wall test.c && ./a.out 
test.c: In function `main':
test.c:20: warning: right shift count >= width of type
CHAR_BIT = 8, LONG_BIT = 32
1 >> 32 == 1
roland@cachemir /tmp $ 

So I guess it's really something to do with gcc.  Drat.
-------------------------------------------------------

Date: 2000-Oct-03 11:19
By: jhylton

Comment:
I'll see if I can reproduce the problem with GCC 2.95.2

-------------------------------------------------------

Date: 2000-Oct-03 14:26
By: jhylton

Comment:
I can't reproduce this on my system with gcc-2.95.2

I'm puzzled by your last comment about replacing LONG_BIT/2 with LONG_BIT and getting the warning.  I really don't understand why the code is generating a warning at compile time.

line 327 of Object/intobject.c is this right:
	ah = a >> (LONG_BIT/2);
And on your platform LONG_BIT == 32?  And it generates the warning?
Can you print the value of LONG_BIT/2 at just the time it is used in int_mul?

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115919&group_id=5470


From noreply@sourceforge.net  Tue Oct  3 23:46:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 15:46:13 -0700
Subject: [Python-bugs-list] [Bug #115919] Integer multiplication overflow
Message-ID: <200010032246.PAA05081@bush.i.sourceforge.net>

Bug #115919, was updated on 2000-Oct-03 08:01
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: Integer multiplication overflow

Details: roland@cachemir ~ $ python2.0 
Python 2.0b2 (#3, Oct  3 2000, 16:30:25) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> 1+1
2
>>> 1*1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>> 

Last CVS update 2000-10-03 around 14:00 UTC.  Last before that was some weeks ago, sorry for not being precise.  Compiled with ./configure --prefix=/usr/local/ && make, su and make install.  Only personal change is the use of readline in Modules/Setup.local.  Did I do something wrong?

Follow-Ups:

Date: 2000-Oct-03 08:25
By: jhylton

Comment:
What happens when you run "make test"?  It looks like there is something fundamentally broken, but I can't tell what it is.  If 1*1 fails, I expect the rest of the test suite to also report errors.


-------------------------------------------------------

Date: 2000-Oct-03 08:38
By: lo-lan-do

Comment:
make test shows me plenty of lines looking like this one (except the name of the test changes):

test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication

I also get messages along the lines of 'test test_dbm skipped --  No module named dbm', but I guess these ones are OK.
-------------------------------------------------------

Date: 2000-Oct-03 08:40
By: jhylton

Comment:
Can you include the complete output?

-------------------------------------------------------

Date: 2000-Oct-03 09:02
By: lo-lan-do

Comment:
[In case the bug would be caused by a recent upgrade to a beta glibc, I tried the '1*1' test with Python 1.5.2.  No bug visible there.]

$ make distclean && ./configure --prefix=/usr/local/ && make
$ make test &> test.log

It seems that 'make test' somehow hangs when testing threads, so I cut at that point.  I hope the relevant info is shown before that point.
Here goes...

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Unhandled exception in thread:
test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication
test_opcodes
test_operations
test_builtin
test test_builtin crashed -- exceptions.OverflowError: integer multiplication
test_exceptions
test_types
test test_types crashed -- exceptions.OverflowError: integer multiplication
test_MimeWriter
test_StringIO
test_al
test test_al skipped --  No module named al
test_array
test test_array crashed -- exceptions.OverflowError: integer multiplication
test_atexit
test_audioop
test test_audioop skipped --  No module named audioop
test_augassign
test test_augassign crashed -- exceptions.OverflowError: integer multiplication
test_binascii
test_binhex
test test_binhex crashed -- exceptions.OverflowError: integer multiplication
test_bsddb
test_cd
test test_cd skipped --  No module named cd
test_cfgparser
test test_cfgparser crashed -- exceptions.OverflowError: integer multiplication
test_cgi
test test_cgi crashed -- exceptions.OverflowError: integer multiplication
test_cl
test test_cl skipped --  No module named cl
test_class
test_cmath
test_compile
test_contains
test_cookie
test test_cookie crashed -- exceptions.OverflowError: integer multiplication
test_cpickle
test_crypt
test test_crypt skipped --  No module named crypt
test_dbm
test test_dbm skipped --  No module named dbm
test_dl
test test_dl skipped --  No module named dl
test_dospath
test_errno
test_extcall
test_fcntl
test_file
test_fork1
test_format
test_gc
test_gdbm
test test_gdbm skipped --  No module named gdbm
test_getopt
test_gettext
test test_gettext crashed -- exceptions.OverflowError: integer multiplication
test_gl
test test_gl skipped --  No module named gl
test_grp
test_gzip
test test_gzip skipped --  No module named zlib
test_hash
test_imageop
test test_imageop skipped --  No module named imageop
test_imgfile
test test_imgfile skipped --  No module named imgfile
test_largefile
test test_largefile skipped --  platform does not have largefile support
test_linuxaudiodev
test test_linuxaudiodev skipped --  No module named linuxaudiodev
test_long
test test_long crashed -- exceptions.OverflowError: integer multiplication
test_longexp
test_math
test_md5
test_mimetools
test test_mimetools crashed -- exceptions.AttributeError: encode
test_minidom
test test_minidom skipped --  No module named pyexpat
test_mmap
test test_mmap crashed -- exceptions.OverflowError: integer multiplication
test_new
test_nis
test test_nis skipped --  No module named nis
test_ntpath
test_openpty
test_operator
test test_operator failed -- Writing: 'mul(5, 2) = <class exceptions.OverflowError at 0x818f41c>: 10 expected', expected: 'testing:
 neg\012testing: or_\012testing: pos\012testing: repeat\012testing: rshift'
test_parser
test_pickle
test_pkg
test_poll
test test_poll crashed -- exceptions.OverflowError: integer multiplication
test_popen2
test_posixpath
test_pow
test test_pow crashed -- exceptions.OverflowError: integer multiplication
test_pty
test test_pty skipped --  No module named termios
test_pwd
test_pyexpat
test test_pyexpat skipped --  cannot import name expat
test_re
test test_re crashed -- exceptions.OverflowError: integer multiplication
test_regex
test_rfc822
test test_rfc822 crashed -- exceptions.OverflowError: integer multiplication
test_rgbimg
test test_rgbimg skipped --  No module named rgbimg
test_rotor
test_sax
test test_sax skipped --  cannot import name expat
test_select
test_sha
test_signal
test_socket
test_sre
test test_sre failed -- Writing: "sre.match(r'(a)|(b)', 'b').start(1)", expected: ''
test_strftime
test test_strftime crashed -- exceptions.OverflowError: integer multiplication
test_string
test_strop
test_struct
test test_struct crashed -- exceptions.OverflowError: integer multiplication
test_sunaudiodev
test test_sunaudiodev skipped --  No module named sunaudiodev
test_thread
Traceback (most recent call last):
  File "./Lib/test/test_thread.py", line 21, in task
    delay = random.random() * numtasks
  File "/home/roland/perso/src/sourceforge/python/dist/src/Lib/whrandom.py", line 71, in random
    x = (171 * x) % 30269
OverflowError: integer multiplication

-------------------------------------------------------

Date: 2000-Oct-03 09:03
By: jhylton

Comment:
Two more questions:
1) What platform?  Is this a 64-bit machine?  A regular x86?
2) Could you run this under gdb and report where exactly the error is being generated?  The exception is raised in Objects/intobject.c.  I would set a breakpoint at the top of int_mul() and step through the function.


-------------------------------------------------------

Date: 2000-Oct-03 09:32
By: lo-lan-do

Comment:
1) Regular i686 (sez uname).
2) It seems that ah and bh are 1 and not 0 like they should.
A bit of printf-debugging shows me that LONG_BIT/2 is 32,
so somehow 1 >> 32 != 0, which seems most strange and
bizarre to me.  On the other hand, gcc tells me the following
when I compile:

intobject.c: In function `int_mul':
intobject.c:327: warning: right shift count >= width of type

I hope he [gcc] still does the rshift, but I'm no gcc guru.
Hope this helps...
-------------------------------------------------------

Date: 2000-Oct-03 10:01
By: jhylton

Comment:
This does help.  The compiler warning is a bad sign.  I notice that you're using a more recent version of gcc than I have installed.  I'll try building with a newer gcc, but in the interim it may help if you compile the following test program:

#include <stdio.h>
#include <ctype.h>

#ifndef CHAR_BIT
#define CHAR_BIT 8
#endif

#ifndef LONG_BIT
#define LONG_BIT (CHAR_BIT * sizeof(long))
#endif

int main()
{
    int a, b;
    a = 1;
    b = a;
    a = a >> (LONG_BIT / 2);
    printf("CHAR_BIT = %d, LONG_BIT = %d\n", CHAR_BIT, LONG_BIT);
    printf("%d >> %d == %d\n", b, LONG_BIT/2, a);
    return 0;
}

On my system it compiles without warning using gcc -Wall and produces the following output:

CHAR_BIT = 8, LONG_BIT = 32
1 >> 16 == 0

What output do you get?  What is sizeof(long) on your platform?  Does ctype.h define CHAR_BIT or LONG_BIT?

-------------------------------------------------------

Date: 2000-Oct-03 10:23
By: lo-lan-do

Comment:
Your test program compiles without warning and
gives the same results as yours here.
sizeof(long) is 4, limits.h defines CHAR_BIT to be 8.
LONG_BIT is defined in bits/xopen_lim.h to be 32.
-------------------------------------------------------

Date: 2000-Oct-03 10:30
By: lo-lan-do

Comment:
Now if I replace LONG_BIT/2 by LONG_BIT in your test program:
roland@cachemir /tmp $ gcc -Wall test.c && ./a.out 
test.c: In function `main':
test.c:20: warning: right shift count >= width of type
CHAR_BIT = 8, LONG_BIT = 32
1 >> 32 == 1
roland@cachemir /tmp $ 

So I guess it's really something to do with gcc.  Drat.
-------------------------------------------------------

Date: 2000-Oct-03 11:19
By: jhylton

Comment:
I'll see if I can reproduce the problem with GCC 2.95.2

-------------------------------------------------------

Date: 2000-Oct-03 14:26
By: jhylton

Comment:
I can't reproduce this on my system with gcc-2.95.2

I'm puzzled by your last comment about replacing LONG_BIT/2 with LONG_BIT and getting the warning.  I really don't understand why the code is generating a warning at compile time.

line 327 of Object/intobject.c is this right:
	ah = a >> (LONG_BIT/2);
And on your platform LONG_BIT == 32?  And it generates the warning?
Can you print the value of LONG_BIT/2 at just the time it is used in int_mul?

-------------------------------------------------------

Date: 2000-Oct-03 15:46
By: loewis

Comment:
Instead of printing the value of LONG_BIT, I recommend to compile intobject with --save-temps. When invoking make, catch the line that compiles intobject.c, copy it and add --save-temps. Then report the fragment of intobject.i that corresponds to int_mul.

Please also report the exact version of glibc you are using. 2.1.93 sometimes gets the order of includes wrong, so that LONG_BIT ends up being defined as 64.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115919&group_id=5470


From noreply@sourceforge.net  Wed Oct  4 04:40:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 20:40:09 -0700
Subject: [Python-bugs-list] [Bug #115973] Cygwin Fixes
Message-ID: <200010040340.UAA08901@delerium.i.sourceforge.net>

Bug #115973, was updated on 2000-Oct-03 20:40
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Cygwin Fixes

Details: With the following changes
Cygwin compiled Python supports dynamic libraries and can support Tkinter

===========
Python / dynload_shlib.c
~line 24
===========

const struct filedescr _PyImport_DynLoadFiletab[] = {
#ifdef __CYGWIN__
	{".pyd", "rb", C_EXTENSION},
	{".dll", "rb", C_EXTENSION},
#else
	{".so", "rb", C_EXTENSION},
	{"module.so", "rb", C_EXTENSION},
#endif
	{0, 0}
};


==========
Modules / _tkinker.c
~line 60
==========

#if !(defined(MS_WINDOWS) || defined(__CYGWIN__))
#define HAVE_CREATEFILEHANDLER
#endif



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115973&group_id=5470


From noreply@sourceforge.net  Wed Oct  4 04:53:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 3 Oct 2000 20:53:17 -0700
Subject: [Python-bugs-list] [Bug #115974] utf-16 codec problems with multiple file write
Message-ID: <200010040353.UAA09366@delerium.i.sourceforge.net>

Bug #115974, was updated on 2000-Oct-03 20:53
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: utf-16 codec problems with multiple file write

Details: In following example, I would expect to write 14 bytes long file. However, 16 bytes are written, with FF FE inserted in the start of each write. I might be wrong, and this is intentional, however I can not find other way to write/read Unicode file (except as whole, which often is incovenient/impossible).

Vadim

----------------------------------------------------


import codecs

fout = codecs.open("test.utf-16", "wb", 'UTF-16')
fout.write(u"ABC")
fout.write(u"DEF")
fout.close()


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115974&group_id=5470


From noreply@sourceforge.net  Wed Oct  4 09:26:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 4 Oct 2000 01:26:48 -0700
Subject: [Python-bugs-list] [Bug #115987] Crash in __coerce__ (2.0b2)
Message-ID: <200010040826.BAA19102@delerium.i.sourceforge.net>

Bug #115987, was updated on 2000-Oct-04 01:26
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Crash in __coerce__ (2.0b2)

Details: The example below results in a hard crash (Application Error) on w2k.

Python 2.0b2 (#6, Sep 26 2000, 14:59:21) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> class A:
...     def __init__(self, v):
...         self.v = v
...     def __iadd__(self, v):
...         return self.v + v
...     def __coerce__(self, x):
...         print "__coerce__", v
...
>>> a = A(5)
>>> a += 6
__coerce__


The instruction at "0x1e127647" referenced memory as 0x00000046". The memory could not be "read".


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115987&group_id=5470


From noreply@sourceforge.net  Wed Oct  4 09:46:49 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 4 Oct 2000 01:46:49 -0700
Subject: [Python-bugs-list] [Bug #115919] Integer multiplication overflow
Message-ID: <200010040846.BAA19806@delerium.i.sourceforge.net>

Bug #115919, was updated on 2000-Oct-03 08:01
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: Integer multiplication overflow

Details: roland@cachemir ~ $ python2.0 
Python 2.0b2 (#3, Oct  3 2000, 16:30:25) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> 1+1
2
>>> 1*1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>> 

Last CVS update 2000-10-03 around 14:00 UTC.  Last before that was some weeks ago, sorry for not being precise.  Compiled with ./configure --prefix=/usr/local/ && make, su and make install.  Only personal change is the use of readline in Modules/Setup.local.  Did I do something wrong?

Follow-Ups:

Date: 2000-Oct-03 08:25
By: jhylton

Comment:
What happens when you run "make test"?  It looks like there is something fundamentally broken, but I can't tell what it is.  If 1*1 fails, I expect the rest of the test suite to also report errors.


-------------------------------------------------------

Date: 2000-Oct-03 08:38
By: lo-lan-do

Comment:
make test shows me plenty of lines looking like this one (except the name of the test changes):

test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication

I also get messages along the lines of 'test test_dbm skipped --  No module named dbm', but I guess these ones are OK.
-------------------------------------------------------

Date: 2000-Oct-03 08:40
By: jhylton

Comment:
Can you include the complete output?

-------------------------------------------------------

Date: 2000-Oct-03 09:02
By: lo-lan-do

Comment:
[In case the bug would be caused by a recent upgrade to a beta glibc, I tried the '1*1' test with Python 1.5.2.  No bug visible there.]

$ make distclean && ./configure --prefix=/usr/local/ && make
$ make test &> test.log

It seems that 'make test' somehow hangs when testing threads, so I cut at that point.  I hope the relevant info is shown before that point.
Here goes...

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Unhandled exception in thread:
test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication
test_opcodes
test_operations
test_builtin
test test_builtin crashed -- exceptions.OverflowError: integer multiplication
test_exceptions
test_types
test test_types crashed -- exceptions.OverflowError: integer multiplication
test_MimeWriter
test_StringIO
test_al
test test_al skipped --  No module named al
test_array
test test_array crashed -- exceptions.OverflowError: integer multiplication
test_atexit
test_audioop
test test_audioop skipped --  No module named audioop
test_augassign
test test_augassign crashed -- exceptions.OverflowError: integer multiplication
test_binascii
test_binhex
test test_binhex crashed -- exceptions.OverflowError: integer multiplication
test_bsddb
test_cd
test test_cd skipped --  No module named cd
test_cfgparser
test test_cfgparser crashed -- exceptions.OverflowError: integer multiplication
test_cgi
test test_cgi crashed -- exceptions.OverflowError: integer multiplication
test_cl
test test_cl skipped --  No module named cl
test_class
test_cmath
test_compile
test_contains
test_cookie
test test_cookie crashed -- exceptions.OverflowError: integer multiplication
test_cpickle
test_crypt
test test_crypt skipped --  No module named crypt
test_dbm
test test_dbm skipped --  No module named dbm
test_dl
test test_dl skipped --  No module named dl
test_dospath
test_errno
test_extcall
test_fcntl
test_file
test_fork1
test_format
test_gc
test_gdbm
test test_gdbm skipped --  No module named gdbm
test_getopt
test_gettext
test test_gettext crashed -- exceptions.OverflowError: integer multiplication
test_gl
test test_gl skipped --  No module named gl
test_grp
test_gzip
test test_gzip skipped --  No module named zlib
test_hash
test_imageop
test test_imageop skipped --  No module named imageop
test_imgfile
test test_imgfile skipped --  No module named imgfile
test_largefile
test test_largefile skipped --  platform does not have largefile support
test_linuxaudiodev
test test_linuxaudiodev skipped --  No module named linuxaudiodev
test_long
test test_long crashed -- exceptions.OverflowError: integer multiplication
test_longexp
test_math
test_md5
test_mimetools
test test_mimetools crashed -- exceptions.AttributeError: encode
test_minidom
test test_minidom skipped --  No module named pyexpat
test_mmap
test test_mmap crashed -- exceptions.OverflowError: integer multiplication
test_new
test_nis
test test_nis skipped --  No module named nis
test_ntpath
test_openpty
test_operator
test test_operator failed -- Writing: 'mul(5, 2) = <class exceptions.OverflowError at 0x818f41c>: 10 expected', expected: 'testing:
 neg\012testing: or_\012testing: pos\012testing: repeat\012testing: rshift'
test_parser
test_pickle
test_pkg
test_poll
test test_poll crashed -- exceptions.OverflowError: integer multiplication
test_popen2
test_posixpath
test_pow
test test_pow crashed -- exceptions.OverflowError: integer multiplication
test_pty
test test_pty skipped --  No module named termios
test_pwd
test_pyexpat
test test_pyexpat skipped --  cannot import name expat
test_re
test test_re crashed -- exceptions.OverflowError: integer multiplication
test_regex
test_rfc822
test test_rfc822 crashed -- exceptions.OverflowError: integer multiplication
test_rgbimg
test test_rgbimg skipped --  No module named rgbimg
test_rotor
test_sax
test test_sax skipped --  cannot import name expat
test_select
test_sha
test_signal
test_socket
test_sre
test test_sre failed -- Writing: "sre.match(r'(a)|(b)', 'b').start(1)", expected: ''
test_strftime
test test_strftime crashed -- exceptions.OverflowError: integer multiplication
test_string
test_strop
test_struct
test test_struct crashed -- exceptions.OverflowError: integer multiplication
test_sunaudiodev
test test_sunaudiodev skipped --  No module named sunaudiodev
test_thread
Traceback (most recent call last):
  File "./Lib/test/test_thread.py", line 21, in task
    delay = random.random() * numtasks
  File "/home/roland/perso/src/sourceforge/python/dist/src/Lib/whrandom.py", line 71, in random
    x = (171 * x) % 30269
OverflowError: integer multiplication

-------------------------------------------------------

Date: 2000-Oct-03 09:03
By: jhylton

Comment:
Two more questions:
1) What platform?  Is this a 64-bit machine?  A regular x86?
2) Could you run this under gdb and report where exactly the error is being generated?  The exception is raised in Objects/intobject.c.  I would set a breakpoint at the top of int_mul() and step through the function.


-------------------------------------------------------

Date: 2000-Oct-03 09:32
By: lo-lan-do

Comment:
1) Regular i686 (sez uname).
2) It seems that ah and bh are 1 and not 0 like they should.
A bit of printf-debugging shows me that LONG_BIT/2 is 32,
so somehow 1 >> 32 != 0, which seems most strange and
bizarre to me.  On the other hand, gcc tells me the following
when I compile:

intobject.c: In function `int_mul':
intobject.c:327: warning: right shift count >= width of type

I hope he [gcc] still does the rshift, but I'm no gcc guru.
Hope this helps...
-------------------------------------------------------

Date: 2000-Oct-03 10:01
By: jhylton

Comment:
This does help.  The compiler warning is a bad sign.  I notice that you're using a more recent version of gcc than I have installed.  I'll try building with a newer gcc, but in the interim it may help if you compile the following test program:

#include <stdio.h>
#include <ctype.h>

#ifndef CHAR_BIT
#define CHAR_BIT 8
#endif

#ifndef LONG_BIT
#define LONG_BIT (CHAR_BIT * sizeof(long))
#endif

int main()
{
    int a, b;
    a = 1;
    b = a;
    a = a >> (LONG_BIT / 2);
    printf("CHAR_BIT = %d, LONG_BIT = %d\n", CHAR_BIT, LONG_BIT);
    printf("%d >> %d == %d\n", b, LONG_BIT/2, a);
    return 0;
}

On my system it compiles without warning using gcc -Wall and produces the following output:

CHAR_BIT = 8, LONG_BIT = 32
1 >> 16 == 0

What output do you get?  What is sizeof(long) on your platform?  Does ctype.h define CHAR_BIT or LONG_BIT?

-------------------------------------------------------

Date: 2000-Oct-03 10:23
By: lo-lan-do

Comment:
Your test program compiles without warning and
gives the same results as yours here.
sizeof(long) is 4, limits.h defines CHAR_BIT to be 8.
LONG_BIT is defined in bits/xopen_lim.h to be 32.
-------------------------------------------------------

Date: 2000-Oct-03 10:30
By: lo-lan-do

Comment:
Now if I replace LONG_BIT/2 by LONG_BIT in your test program:
roland@cachemir /tmp $ gcc -Wall test.c && ./a.out 
test.c: In function `main':
test.c:20: warning: right shift count >= width of type
CHAR_BIT = 8, LONG_BIT = 32
1 >> 32 == 1
roland@cachemir /tmp $ 

So I guess it's really something to do with gcc.  Drat.
-------------------------------------------------------

Date: 2000-Oct-03 11:19
By: jhylton

Comment:
I'll see if I can reproduce the problem with GCC 2.95.2

-------------------------------------------------------

Date: 2000-Oct-03 14:26
By: jhylton

Comment:
I can't reproduce this on my system with gcc-2.95.2

I'm puzzled by your last comment about replacing LONG_BIT/2 with LONG_BIT and getting the warning.  I really don't understand why the code is generating a warning at compile time.

line 327 of Object/intobject.c is this right:
	ah = a >> (LONG_BIT/2);
And on your platform LONG_BIT == 32?  And it generates the warning?
Can you print the value of LONG_BIT/2 at just the time it is used in int_mul?

-------------------------------------------------------

Date: 2000-Oct-03 15:46
By: loewis

Comment:
Instead of printing the value of LONG_BIT, I recommend to compile intobject with --save-temps. When invoking make, catch the line that compiles intobject.c, copy it and add --save-temps. Then report the fragment of intobject.i that corresponds to int_mul.

Please also report the exact version of glibc you are using. 2.1.93 sometimes gets the order of includes wrong, so that LONG_BIT ends up being defined as 64.
-------------------------------------------------------

Date: 2000-Oct-04 01:46
By: lo-lan-do

Comment:
You're [Martin v. Löwis] probably right about the libc stuff.
I'm using 2.1.94 (as installed by the Debian unstable
distribution).  After inserting

printf ("ah: %d, LONG_BIT: %d, LONG_BIT/2: %d\n", ah, LONG_BIT, LONG_BIT/2);

I can clearly see that LONG_BIT is 64.  The appropriate
intobject.i section reads:

int_mul(PyIntObject *v, PyIntObject *w)
{
        long a, b, ah, bh, x, y;
        int s = 1;

        a = v->ob_ival;
        b = w->ob_ival;
        ah = a >> (64 /2);
        bh = b >> (64 /2);
        printf ("ah: %d, LONG_BIT: %d, LONG_BIT/2: %d\n", ah, 64 , 64 /2);

Does this give enough confirmation for me
to submit a Debian bug on the libc6 package?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115919&group_id=5470


From noreply@sourceforge.net  Wed Oct  4 14:10:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 4 Oct 2000 06:10:55 -0700
Subject: [Python-bugs-list] [Bug #115974] utf-16 codec problems with multiple file write
Message-ID: <200010041310.GAA29672@delerium.i.sourceforge.net>

Bug #115974, was updated on 2000-Oct-03 20:53
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: utf-16 codec problems with multiple file write

Details: In following example, I would expect to write 14 bytes long file. However, 16 bytes are written, with FF FE inserted in the start of each write. I might be wrong, and this is intentional, however I can not find other way to write/read Unicode file (except as whole, which often is incovenient/impossible).

Vadim

----------------------------------------------------


import codecs

fout = codecs.open("test.utf-16", "wb", 'UTF-16')
fout.write(u"ABC")
fout.write(u"DEF")
fout.close()


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115974&group_id=5470


From noreply@sourceforge.net  Wed Oct  4 14:11:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 4 Oct 2000 06:11:59 -0700
Subject: [Python-bugs-list] [Bug #115973] Cygwin Fixes
Message-ID: <200010041311.GAA29712@delerium.i.sourceforge.net>

Bug #115973, was updated on 2000-Oct-03 20:40
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Cygwin Fixes

Details: With the following changes
Cygwin compiled Python supports dynamic libraries and can support Tkinter

===========
Python / dynload_shlib.c
~line 24
===========

const struct filedescr _PyImport_DynLoadFiletab[] = {
#ifdef __CYGWIN__
	{".pyd", "rb", C_EXTENSION},
	{".dll", "rb", C_EXTENSION},
#else
	{".so", "rb", C_EXTENSION},
	{"module.so", "rb", C_EXTENSION},
#endif
	{0, 0}
};


==========
Modules / _tkinker.c
~line 60
==========

#if !(defined(MS_WINDOWS) || defined(__CYGWIN__))
#define HAVE_CREATEFILEHANDLER
#endif



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115973&group_id=5470


From noreply@sourceforge.net  Wed Oct  4 14:18:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 4 Oct 2000 06:18:55 -0700
Subject: [Python-bugs-list] [Bug #115987] Crash in __coerce__ (2.0b2)
Message-ID: <200010041318.GAA29958@delerium.i.sourceforge.net>

Bug #115987, was updated on 2000-Oct-04 01:26
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: Crash in __coerce__ (2.0b2)

Details: The example below results in a hard crash (Application Error) on w2k.

Python 2.0b2 (#6, Sep 26 2000, 14:59:21) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> class A:
...     def __init__(self, v):
...         self.v = v
...     def __iadd__(self, v):
...         return self.v + v
...     def __coerce__(self, x):
...         print "__coerce__", v
...
>>> a = A(5)
>>> a += 6
__coerce__


The instruction at "0x1e127647" referenced memory as 0x00000046". The memory could not be "read".


Follow-Ups:

Date: 2000-Oct-04 06:18
By: fdrake

Comment:
On Linux, I get the expected NameError after it prints "__coerce__".

Assigned to TIm since this appears to be Windows-specific.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115987&group_id=5470


From noreply@sourceforge.net  Wed Oct  4 14:53:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 4 Oct 2000 06:53:05 -0700
Subject: [Python-bugs-list] [Bug #115974] utf-16 codec problems with multiple file write
Message-ID: <200010041353.GAA31406@delerium.i.sourceforge.net>

Bug #115974, was updated on 2000-Oct-03 20:53
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Wont Fix
Bug Group: None
Priority: 7
Summary: utf-16 codec problems with multiple file write

Details: In following example, I would expect to write 14 bytes long file. However, 16 bytes are written, with FF FE inserted in the start of each write. I might be wrong, and this is intentional, however I can not find other way to write/read Unicode file (except as whole, which often is incovenient/impossible).

Vadim

----------------------------------------------------


import codecs

fout = codecs.open("test.utf-16", "wb", 'UTF-16')
fout.write(u"ABC")
fout.write(u"DEF")
fout.close()


Follow-Ups:

Date: 2000-Oct-04 06:53
By: lemburg

Comment:
It could be argued whether this is a bug or not. 

Fact is that byte order
marks can be inserted anywhere in a UTF-16 file without harming
the contents. BOM marks are removed from the input stream by the
Python UTF-16 codec, so there should be no problem there.

If you plan to write a UTF-16 file in chunks rather than as whole, use
the UTF-16-BE or UTF-16-LE codec and add the BOM mark at
the start of the file manually. The codecs.py module defines BOM mark
symbols which you can use for this task.


-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115974&group_id=5470


From noreply@sourceforge.net  Wed Oct  4 15:33:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 4 Oct 2000 07:33:44 -0700
Subject: [Python-bugs-list] [Bug #116008] Subsection Hypertext Links are broken in HTML Docs
Message-ID: <200010041433.HAA00748@delerium.i.sourceforge.net>

Bug #116008, was updated on 2000-Oct-04 07:33
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Subsection Hypertext Links are broken in HTML Docs

Details: For example load 
 
   ftp://python.beopen.com/pub/docco/devel/tut/node3.html
 
into your favorite HTML browser and click on the link labeled "1.1 Where From Here".  
It doesn't work as it used to work before in the 1.5.2 docs.  

Unfortunately I can't tell which change to the latex2html engine broke this.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116008&group_id=5470


From noreply@sourceforge.net  Wed Oct  4 16:23:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 4 Oct 2000 08:23:54 -0700
Subject: [Python-bugs-list] [Bug #116011] PyPort.h backward compatibility issues missing
Message-ID: <200010041523.IAA02886@delerium.i.sourceforge.net>

Bug #116011, was updated on 2000-Oct-04 08:23
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: PyPort.h backward compatibility issues missing

Details: PyPort.h contain only Py_PROTO for backward compatibility.
I'm thinking about add also the "Py_FPROTO" ghost macro, this may speed up code porting to the new version.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116011&group_id=5470


From noreply@sourceforge.net  Wed Oct  4 16:34:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 4 Oct 2000 08:34:20 -0700
Subject: [Python-bugs-list] [Bug #115919] Integer multiplication overflow
Message-ID: <200010041534.IAA10000@bush.i.sourceforge.net>

Bug #115919, was updated on 2000-Oct-03 08:01
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: Integer multiplication overflow

Details: roland@cachemir ~ $ python2.0 
Python 2.0b2 (#3, Oct  3 2000, 16:30:25) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> 1+1
2
>>> 1*1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>> 

Last CVS update 2000-10-03 around 14:00 UTC.  Last before that was some weeks ago, sorry for not being precise.  Compiled with ./configure --prefix=/usr/local/ && make, su and make install.  Only personal change is the use of readline in Modules/Setup.local.  Did I do something wrong?

Follow-Ups:

Date: 2000-Oct-03 08:25
By: jhylton

Comment:
What happens when you run "make test"?  It looks like there is something fundamentally broken, but I can't tell what it is.  If 1*1 fails, I expect the rest of the test suite to also report errors.


-------------------------------------------------------

Date: 2000-Oct-03 08:38
By: lo-lan-do

Comment:
make test shows me plenty of lines looking like this one (except the name of the test changes):

test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication

I also get messages along the lines of 'test test_dbm skipped --  No module named dbm', but I guess these ones are OK.
-------------------------------------------------------

Date: 2000-Oct-03 08:40
By: jhylton

Comment:
Can you include the complete output?

-------------------------------------------------------

Date: 2000-Oct-03 09:02
By: lo-lan-do

Comment:
[In case the bug would be caused by a recent upgrade to a beta glibc, I tried the '1*1' test with Python 1.5.2.  No bug visible there.]

$ make distclean && ./configure --prefix=/usr/local/ && make
$ make test &> test.log

It seems that 'make test' somehow hangs when testing threads, so I cut at that point.  I hope the relevant info is shown before that point.
Here goes...

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Unhandled exception in thread:
test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication
test_opcodes
test_operations
test_builtin
test test_builtin crashed -- exceptions.OverflowError: integer multiplication
test_exceptions
test_types
test test_types crashed -- exceptions.OverflowError: integer multiplication
test_MimeWriter
test_StringIO
test_al
test test_al skipped --  No module named al
test_array
test test_array crashed -- exceptions.OverflowError: integer multiplication
test_atexit
test_audioop
test test_audioop skipped --  No module named audioop
test_augassign
test test_augassign crashed -- exceptions.OverflowError: integer multiplication
test_binascii
test_binhex
test test_binhex crashed -- exceptions.OverflowError: integer multiplication
test_bsddb
test_cd
test test_cd skipped --  No module named cd
test_cfgparser
test test_cfgparser crashed -- exceptions.OverflowError: integer multiplication
test_cgi
test test_cgi crashed -- exceptions.OverflowError: integer multiplication
test_cl
test test_cl skipped --  No module named cl
test_class
test_cmath
test_compile
test_contains
test_cookie
test test_cookie crashed -- exceptions.OverflowError: integer multiplication
test_cpickle
test_crypt
test test_crypt skipped --  No module named crypt
test_dbm
test test_dbm skipped --  No module named dbm
test_dl
test test_dl skipped --  No module named dl
test_dospath
test_errno
test_extcall
test_fcntl
test_file
test_fork1
test_format
test_gc
test_gdbm
test test_gdbm skipped --  No module named gdbm
test_getopt
test_gettext
test test_gettext crashed -- exceptions.OverflowError: integer multiplication
test_gl
test test_gl skipped --  No module named gl
test_grp
test_gzip
test test_gzip skipped --  No module named zlib
test_hash
test_imageop
test test_imageop skipped --  No module named imageop
test_imgfile
test test_imgfile skipped --  No module named imgfile
test_largefile
test test_largefile skipped --  platform does not have largefile support
test_linuxaudiodev
test test_linuxaudiodev skipped --  No module named linuxaudiodev
test_long
test test_long crashed -- exceptions.OverflowError: integer multiplication
test_longexp
test_math
test_md5
test_mimetools
test test_mimetools crashed -- exceptions.AttributeError: encode
test_minidom
test test_minidom skipped --  No module named pyexpat
test_mmap
test test_mmap crashed -- exceptions.OverflowError: integer multiplication
test_new
test_nis
test test_nis skipped --  No module named nis
test_ntpath
test_openpty
test_operator
test test_operator failed -- Writing: 'mul(5, 2) = <class exceptions.OverflowError at 0x818f41c>: 10 expected', expected: 'testing:
 neg\012testing: or_\012testing: pos\012testing: repeat\012testing: rshift'
test_parser
test_pickle
test_pkg
test_poll
test test_poll crashed -- exceptions.OverflowError: integer multiplication
test_popen2
test_posixpath
test_pow
test test_pow crashed -- exceptions.OverflowError: integer multiplication
test_pty
test test_pty skipped --  No module named termios
test_pwd
test_pyexpat
test test_pyexpat skipped --  cannot import name expat
test_re
test test_re crashed -- exceptions.OverflowError: integer multiplication
test_regex
test_rfc822
test test_rfc822 crashed -- exceptions.OverflowError: integer multiplication
test_rgbimg
test test_rgbimg skipped --  No module named rgbimg
test_rotor
test_sax
test test_sax skipped --  cannot import name expat
test_select
test_sha
test_signal
test_socket
test_sre
test test_sre failed -- Writing: "sre.match(r'(a)|(b)', 'b').start(1)", expected: ''
test_strftime
test test_strftime crashed -- exceptions.OverflowError: integer multiplication
test_string
test_strop
test_struct
test test_struct crashed -- exceptions.OverflowError: integer multiplication
test_sunaudiodev
test test_sunaudiodev skipped --  No module named sunaudiodev
test_thread
Traceback (most recent call last):
  File "./Lib/test/test_thread.py", line 21, in task
    delay = random.random() * numtasks
  File "/home/roland/perso/src/sourceforge/python/dist/src/Lib/whrandom.py", line 71, in random
    x = (171 * x) % 30269
OverflowError: integer multiplication

-------------------------------------------------------

Date: 2000-Oct-03 09:03
By: jhylton

Comment:
Two more questions:
1) What platform?  Is this a 64-bit machine?  A regular x86?
2) Could you run this under gdb and report where exactly the error is being generated?  The exception is raised in Objects/intobject.c.  I would set a breakpoint at the top of int_mul() and step through the function.


-------------------------------------------------------

Date: 2000-Oct-03 09:32
By: lo-lan-do

Comment:
1) Regular i686 (sez uname).
2) It seems that ah and bh are 1 and not 0 like they should.
A bit of printf-debugging shows me that LONG_BIT/2 is 32,
so somehow 1 >> 32 != 0, which seems most strange and
bizarre to me.  On the other hand, gcc tells me the following
when I compile:

intobject.c: In function `int_mul':
intobject.c:327: warning: right shift count >= width of type

I hope he [gcc] still does the rshift, but I'm no gcc guru.
Hope this helps...
-------------------------------------------------------

Date: 2000-Oct-03 10:01
By: jhylton

Comment:
This does help.  The compiler warning is a bad sign.  I notice that you're using a more recent version of gcc than I have installed.  I'll try building with a newer gcc, but in the interim it may help if you compile the following test program:

#include <stdio.h>
#include <ctype.h>

#ifndef CHAR_BIT
#define CHAR_BIT 8
#endif

#ifndef LONG_BIT
#define LONG_BIT (CHAR_BIT * sizeof(long))
#endif

int main()
{
    int a, b;
    a = 1;
    b = a;
    a = a >> (LONG_BIT / 2);
    printf("CHAR_BIT = %d, LONG_BIT = %d\n", CHAR_BIT, LONG_BIT);
    printf("%d >> %d == %d\n", b, LONG_BIT/2, a);
    return 0;
}

On my system it compiles without warning using gcc -Wall and produces the following output:

CHAR_BIT = 8, LONG_BIT = 32
1 >> 16 == 0

What output do you get?  What is sizeof(long) on your platform?  Does ctype.h define CHAR_BIT or LONG_BIT?

-------------------------------------------------------

Date: 2000-Oct-03 10:23
By: lo-lan-do

Comment:
Your test program compiles without warning and
gives the same results as yours here.
sizeof(long) is 4, limits.h defines CHAR_BIT to be 8.
LONG_BIT is defined in bits/xopen_lim.h to be 32.
-------------------------------------------------------

Date: 2000-Oct-03 10:30
By: lo-lan-do

Comment:
Now if I replace LONG_BIT/2 by LONG_BIT in your test program:
roland@cachemir /tmp $ gcc -Wall test.c && ./a.out 
test.c: In function `main':
test.c:20: warning: right shift count >= width of type
CHAR_BIT = 8, LONG_BIT = 32
1 >> 32 == 1
roland@cachemir /tmp $ 

So I guess it's really something to do with gcc.  Drat.
-------------------------------------------------------

Date: 2000-Oct-03 11:19
By: jhylton

Comment:
I'll see if I can reproduce the problem with GCC 2.95.2

-------------------------------------------------------

Date: 2000-Oct-03 14:26
By: jhylton

Comment:
I can't reproduce this on my system with gcc-2.95.2

I'm puzzled by your last comment about replacing LONG_BIT/2 with LONG_BIT and getting the warning.  I really don't understand why the code is generating a warning at compile time.

line 327 of Object/intobject.c is this right:
	ah = a >> (LONG_BIT/2);
And on your platform LONG_BIT == 32?  And it generates the warning?
Can you print the value of LONG_BIT/2 at just the time it is used in int_mul?

-------------------------------------------------------

Date: 2000-Oct-03 15:46
By: loewis

Comment:
Instead of printing the value of LONG_BIT, I recommend to compile intobject with --save-temps. When invoking make, catch the line that compiles intobject.c, copy it and add --save-temps. Then report the fragment of intobject.i that corresponds to int_mul.

Please also report the exact version of glibc you are using. 2.1.93 sometimes gets the order of includes wrong, so that LONG_BIT ends up being defined as 64.
-------------------------------------------------------

Date: 2000-Oct-04 01:46
By: lo-lan-do

Comment:
You're [Martin v. Löwis] probably right about the libc stuff.
I'm using 2.1.94 (as installed by the Debian unstable
distribution).  After inserting

printf ("ah: %d, LONG_BIT: %d, LONG_BIT/2: %d\n", ah, LONG_BIT, LONG_BIT/2);

I can clearly see that LONG_BIT is 64.  The appropriate
intobject.i section reads:

int_mul(PyIntObject *v, PyIntObject *w)
{
        long a, b, ah, bh, x, y;
        int s = 1;

        a = v->ob_ival;
        b = w->ob_ival;
        ah = a >> (64 /2);
        bh = b >> (64 /2);
        printf ("ah: %d, LONG_BIT: %d, LONG_BIT/2: %d\n", ah, 64 , 64 /2);

Does this give enough confirmation for me
to submit a Debian bug on the libc6 package?
-------------------------------------------------------

Date: 2000-Oct-04 08:34
By: lo-lan-do

Comment:
After a bit of investigation (thanks to the Debian maintainer
of libc6) it appears that #define'ing _GNU_SOURCE causes
some include file or other to do Not The Right Thing.  Namely,
#define'ing LONG_BIT to 64 while LONG_MAX is correct
(0x7FFFFFFFL).

I'll continue investigating (though maybe not as intensively, I'm
getting a bit flummoxed...)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115919&group_id=5470


From noreply@sourceforge.net  Wed Oct  4 16:53:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 4 Oct 2000 08:53:52 -0700
Subject: [Python-bugs-list] [Bug #116008] Subsection Hypertext Links are broken in HTML Docs
Message-ID: <200010041553.IAA04158@delerium.i.sourceforge.net>

Bug #116008, was updated on 2000-Oct-04 07:33
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Subsection Hypertext Links are broken in HTML Docs

Details: For example load 
 
   ftp://python.beopen.com/pub/docco/devel/tut/node3.html
 
into your favorite HTML browser and click on the link labeled "1.1 Where From Here".  
It doesn't work as it used to work before in the 1.5.2 docs.  

Unfortunately I can't tell which change to the latex2html engine broke this.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116008&group_id=5470


From noreply@sourceforge.net  Wed Oct  4 17:01:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 4 Oct 2000 09:01:03 -0700
Subject: [Python-bugs-list] [Bug #110924] support Unicode for Python source code
Message-ID: <200010041601.JAA11124@bush.i.sourceforge.net>

Bug #110924, was updated on 2000-Aug-02 08:17
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Closed
Resolution: Fixed
Bug Group: Feature Request
Priority: 1
Summary: support Unicode for Python source code

Details: exec u"print 42"
doesn't work.

Follow-Ups:

Date: 2000-Aug-09 02:35
By: effbot

Comment:
python doesn't support 16-bit source code -- so what exactly do you want exec to do?
-------------------------------------------------------

Date: 2000-Aug-17 05:17
By: none

Comment:
That's exactly my point. Python should support Unicode
everywhere, in __str__ and __repr__, exec and eval, in open(), as a format for the source code (which would result in all variable names to be Unicode)...

Currenly working with Unicode (e.g. for XML) is a mess, because it's supported nowhere.

exec "a='ü'" seems to work and seems to treat the string as iso-8859-1 (or not at all)

-------------------------------------------------------

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 05:21
By: lemburg

Comment:
I don't think that the situation is that bad. You can't program
Python in Unicode, but this doesn't stop you from using it
in your Python programs.

Note that __str__ and __repr__ do support Unicode (it gets converted
to an 8-bit string using the default encoding).

There's currently not much need to have exec or eval() automatically
apply any conversion... you can always use str() around the argument
to make it support both 8-bit strings and Unicode.

-------------------------------------------------------

Date: 2000-Sep-16 15:18
By: bwarsaw

Comment:
Reassigning to Guido for final disposal, but I believe this should be marked either as "not a bug" or added to PEP 42.
-------------------------------------------------------

Date: 2000-Sep-16 19:51
By: gvanrossum

Comment:
There's an Accepted patch for this by Marc-Andre Lemburg.
Assigned to Marc-Andre so he can close the bug when he applies the patch.

(Marc-Andre: if you don't have time to apply the patch, let me know and I'll take care of it.)
-------------------------------------------------------

Date: 2000-Sep-19 14:07
By: lemburg

Comment:
exec and eval() now also accept Unicode as code parameter.

This is implemented by having the two APIs convert Unicode
to a string using the default encoding prior to processing the
code string.

-------------------------------------------------------

Date: 2000-Oct-04 09:01
By: none

Comment:
This doesn't solve the problem,
it only hides it.

When I set the defaultencoding to
"utf16" in site.py, I get the following error:

>>> exec u"a = 42"
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: expected string without null bytes

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110924&group_id=5470


From noreply@sourceforge.net  Wed Oct  4 19:39:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 4 Oct 2000 11:39:20 -0700
Subject: [Python-bugs-list] [Bug #115732] Linking fails with old versions of readline
Message-ID: <200010041839.LAA10994@delerium.i.sourceforge.net>

Bug #115732, was updated on 2000-Sep-30 11:36
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: None
Bug Group: None
Priority: 7
Summary: Linking fails with old versions of readline

Details: Python 2.0b2 introduced a new variable into the readline module 'library_version'. This relies on a feature not present in all versions of readline - 'rl_library_version' -  such as the one shipped with OpenBSD 2.7. The latest CVS version fails to link correctly against readlines that don't contain this variable:

[laurie /usr/local/src/Python-2.0b2]$ uname -a
OpenBSD droptop 2.7 GENERIC#25 i386
[laurie /usr/local/src/Python-2.0b2]$ make
<standard make output ... >
gcc   python.o  ../libpython2.0.a -lreadline -ltermcap  -lc_r -lutil -lm  -o python 
./readline.c:504: Undefined symbol `_rl_library_version' referenced from text segment
collect2: ld returned 1 exit status

The only obvious fix to this is to test for the presence of the variable in the configure file and have a HAS_READLINE_VERSION #define or similar which doesn't reference the readline variable, although that doesn't suggest what the library_version should be set to in its absence... None?

This is effectively a followup to bug #11487 which reported compilation problems with the aforementioned variable. It seems likely that the original bug submitter didn't get as far as linking Python due to other compilation problems so the original fix would have appeared to work.

Follow-Ups:

Date: 2000-Oct-02 06:44
By: jhylton

Comment:
It looks like we should just back out the last change to readline.c.

-------------------------------------------------------

Date: 2000-Oct-02 17:56
By: gvanrossum

Comment:
Closed. I took out the reference to rl_library_version. It's not worth the hassle.
-------------------------------------------------------

Date: 2000-Oct-04 11:39
By: ltratt

Comment:
It now links on OBSD 2.7
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115732&group_id=5470


From noreply@sourceforge.net  Wed Oct  4 21:42:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 4 Oct 2000 13:42:43 -0700
Subject: [Python-bugs-list] [Bug #116048] BeOpen Python 2.0b2 RPM does not include python2.0 binary
Message-ID: <200010042042.NAA15955@delerium.i.sourceforge.net>

Bug #116048, was updated on 2000-Oct-04 13:42
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: BeOpen Python 2.0b2 RPM does not include python2.0 binary

Details: When installing Python from the source distribution, 'make install' provides a 'python2.0' binary. Being able to rely on that is convenient for script authors, as they can express that a certain script needs python2 to work.

The BeOpen Linux RPM does not include that binary, so scripts expecting it won't work with it.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116048&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 00:54:36 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 4 Oct 2000 16:54:36 -0700
Subject: [Python-bugs-list] [Bug #110924] support Unicode for Python source code
Message-ID: <200010042354.QAA30212@bush.i.sourceforge.net>

Bug #110924, was updated on 2000-Aug-02 08:17
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Closed
Resolution: Fixed
Bug Group: Feature Request
Priority: 1
Summary: support Unicode for Python source code

Details: exec u"print 42"
doesn't work.

Follow-Ups:

Date: 2000-Aug-09 02:35
By: effbot

Comment:
python doesn't support 16-bit source code -- so what exactly do you want exec to do?
-------------------------------------------------------

Date: 2000-Aug-17 05:17
By: none

Comment:
That's exactly my point. Python should support Unicode
everywhere, in __str__ and __repr__, exec and eval, in open(), as a format for the source code (which would result in all variable names to be Unicode)...

Currenly working with Unicode (e.g. for XML) is a mess, because it's supported nowhere.

exec "a='ü'" seems to work and seems to treat the string as iso-8859-1 (or not at all)

-------------------------------------------------------

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 05:21
By: lemburg

Comment:
I don't think that the situation is that bad. You can't program
Python in Unicode, but this doesn't stop you from using it
in your Python programs.

Note that __str__ and __repr__ do support Unicode (it gets converted
to an 8-bit string using the default encoding).

There's currently not much need to have exec or eval() automatically
apply any conversion... you can always use str() around the argument
to make it support both 8-bit strings and Unicode.

-------------------------------------------------------

Date: 2000-Sep-16 15:18
By: bwarsaw

Comment:
Reassigning to Guido for final disposal, but I believe this should be marked either as "not a bug" or added to PEP 42.
-------------------------------------------------------

Date: 2000-Sep-16 19:51
By: gvanrossum

Comment:
There's an Accepted patch for this by Marc-Andre Lemburg.
Assigned to Marc-Andre so he can close the bug when he applies the patch.

(Marc-Andre: if you don't have time to apply the patch, let me know and I'll take care of it.)
-------------------------------------------------------

Date: 2000-Sep-19 14:07
By: lemburg

Comment:
exec and eval() now also accept Unicode as code parameter.

This is implemented by having the two APIs convert Unicode
to a string using the default encoding prior to processing the
code string.

-------------------------------------------------------

Date: 2000-Oct-04 09:01
By: none

Comment:
This doesn't solve the problem,
it only hides it.

When I set the defaultencoding to
"utf16" in site.py, I get the following error:

>>> exec u"a = 42"
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: expected string without null bytes

-------------------------------------------------------

Date: 2000-Oct-04 16:54
By: lemburg

Comment:
Setting the default encoding to anything which doesn't extend
ASCII is not a good idea. If you want to make Python more
Unicode aware you should test drive setting the default
encoding to UTF-8.

The patches to eval() and exec only provide coercion of Unicode
objects to normal 8-bit strings which the Python parser can handle.

There currently is no Unicode support in the Python compiler.
Patches are welcome ;-) ... and then the "bug" should be opened
again.

Perhaps this should go into the PEP-042 file ?!


-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110924&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 02:53:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 4 Oct 2000 18:53:50 -0700
Subject: [Python-bugs-list] [Bug #114780] Rare hangs in w9xpopen.exe
Message-ID: <200010050153.SAA27148@delerium.i.sourceforge.net>

Bug #114780, was updated on 2000-Sep-19 01:50
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 2
Summary: Rare hangs in w9xpopen.exe

Details: Every two or three days, when I'm running the std test suite on my Win98SE box, test_popen2 just hangs.  wintop shows that w9xpopen.exe is alive, but not consuming any cycles.  test_popen2.py is waiting on a .read().

No other clues.  It *may* be the case that I'm establishing a modem connection near the time test_popen2 starts to run.  I'll try to provoke that.

Assigned to MarkH simply to share the misery <wink>.  Mark, I don't expect you to "fix this", but I don't expect me to either -- it's just something we should both be aware of.


Follow-Ups:

Date: 2000-Sep-19 05:51
By: gvanrossum

Comment:
Tim, do you remember the problem I had with using popen() from IDLE? I had code that essentially did os.popen("start "+url).close(). This worked fine in a DOS box but hung inexplicably for 30 seconds before returning and starting the browser when used in IDLE. The problem went away (the call returned immediately and the browser was started within 2-3 seconds) when I saved the pipe object in an instance variable. We never fixed this, but I tracked it down to probably something having to do with the need to pump events. Mark will understand. I don't doubt that popen2, popen3, popen4 all share this problem. (Check webbrowser.py, class WindowsDefault, for the current solution.)
-------------------------------------------------------

Date: 2000-Sep-25 15:07
By: tim_one

Comment:
Just noting that I've been building and testing Python a *lot* since I entered this bug report, and haven't seen the problem again.
-------------------------------------------------------

Date: 2000-Oct-04 18:53
By: tim_one

Comment:
A (useless, alas) clue:  every now & again, doing a Batch Build under MSVC hangs in midstream:  Never makes progress, and Stop Build has no effect.  Have to kill DevStudio via the task manager.  Then things get *really* screwed up unless I also kill a leftover "vcspawn" task from the task manager.  This suggests that Win98SE (or, at least, my copy of it) simply screws up spawning from time to time.  I reduced the priority on this bug again, reflecting that I now suspect it's a platform bug we're not causing and can't cure.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114780&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 02:55:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 4 Oct 2000 18:55:34 -0700
Subject: [Python-bugs-list] [Bug #115919] Integer multiplication overflow
Message-ID: <200010050155.SAA27192@delerium.i.sourceforge.net>

Bug #115919, was updated on 2000-Oct-03 08:01
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: Integer multiplication overflow

Details: roland@cachemir ~ $ python2.0 
Python 2.0b2 (#3, Oct  3 2000, 16:30:25) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> 1+1
2
>>> 1*1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>> 

Last CVS update 2000-10-03 around 14:00 UTC.  Last before that was some weeks ago, sorry for not being precise.  Compiled with ./configure --prefix=/usr/local/ && make, su and make install.  Only personal change is the use of readline in Modules/Setup.local.  Did I do something wrong?

Follow-Ups:

Date: 2000-Oct-03 08:25
By: jhylton

Comment:
What happens when you run "make test"?  It looks like there is something fundamentally broken, but I can't tell what it is.  If 1*1 fails, I expect the rest of the test suite to also report errors.


-------------------------------------------------------

Date: 2000-Oct-03 08:38
By: lo-lan-do

Comment:
make test shows me plenty of lines looking like this one (except the name of the test changes):

test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication

I also get messages along the lines of 'test test_dbm skipped --  No module named dbm', but I guess these ones are OK.
-------------------------------------------------------

Date: 2000-Oct-03 08:40
By: jhylton

Comment:
Can you include the complete output?

-------------------------------------------------------

Date: 2000-Oct-03 09:02
By: lo-lan-do

Comment:
[In case the bug would be caused by a recent upgrade to a beta glibc, I tried the '1*1' test with Python 1.5.2.  No bug visible there.]

$ make distclean && ./configure --prefix=/usr/local/ && make
$ make test &> test.log

It seems that 'make test' somehow hangs when testing threads, so I cut at that point.  I hope the relevant info is shown before that point.
Here goes...

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Unhandled exception in thread:
test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication
test_opcodes
test_operations
test_builtin
test test_builtin crashed -- exceptions.OverflowError: integer multiplication
test_exceptions
test_types
test test_types crashed -- exceptions.OverflowError: integer multiplication
test_MimeWriter
test_StringIO
test_al
test test_al skipped --  No module named al
test_array
test test_array crashed -- exceptions.OverflowError: integer multiplication
test_atexit
test_audioop
test test_audioop skipped --  No module named audioop
test_augassign
test test_augassign crashed -- exceptions.OverflowError: integer multiplication
test_binascii
test_binhex
test test_binhex crashed -- exceptions.OverflowError: integer multiplication
test_bsddb
test_cd
test test_cd skipped --  No module named cd
test_cfgparser
test test_cfgparser crashed -- exceptions.OverflowError: integer multiplication
test_cgi
test test_cgi crashed -- exceptions.OverflowError: integer multiplication
test_cl
test test_cl skipped --  No module named cl
test_class
test_cmath
test_compile
test_contains
test_cookie
test test_cookie crashed -- exceptions.OverflowError: integer multiplication
test_cpickle
test_crypt
test test_crypt skipped --  No module named crypt
test_dbm
test test_dbm skipped --  No module named dbm
test_dl
test test_dl skipped --  No module named dl
test_dospath
test_errno
test_extcall
test_fcntl
test_file
test_fork1
test_format
test_gc
test_gdbm
test test_gdbm skipped --  No module named gdbm
test_getopt
test_gettext
test test_gettext crashed -- exceptions.OverflowError: integer multiplication
test_gl
test test_gl skipped --  No module named gl
test_grp
test_gzip
test test_gzip skipped --  No module named zlib
test_hash
test_imageop
test test_imageop skipped --  No module named imageop
test_imgfile
test test_imgfile skipped --  No module named imgfile
test_largefile
test test_largefile skipped --  platform does not have largefile support
test_linuxaudiodev
test test_linuxaudiodev skipped --  No module named linuxaudiodev
test_long
test test_long crashed -- exceptions.OverflowError: integer multiplication
test_longexp
test_math
test_md5
test_mimetools
test test_mimetools crashed -- exceptions.AttributeError: encode
test_minidom
test test_minidom skipped --  No module named pyexpat
test_mmap
test test_mmap crashed -- exceptions.OverflowError: integer multiplication
test_new
test_nis
test test_nis skipped --  No module named nis
test_ntpath
test_openpty
test_operator
test test_operator failed -- Writing: 'mul(5, 2) = <class exceptions.OverflowError at 0x818f41c>: 10 expected', expected: 'testing:
 neg\012testing: or_\012testing: pos\012testing: repeat\012testing: rshift'
test_parser
test_pickle
test_pkg
test_poll
test test_poll crashed -- exceptions.OverflowError: integer multiplication
test_popen2
test_posixpath
test_pow
test test_pow crashed -- exceptions.OverflowError: integer multiplication
test_pty
test test_pty skipped --  No module named termios
test_pwd
test_pyexpat
test test_pyexpat skipped --  cannot import name expat
test_re
test test_re crashed -- exceptions.OverflowError: integer multiplication
test_regex
test_rfc822
test test_rfc822 crashed -- exceptions.OverflowError: integer multiplication
test_rgbimg
test test_rgbimg skipped --  No module named rgbimg
test_rotor
test_sax
test test_sax skipped --  cannot import name expat
test_select
test_sha
test_signal
test_socket
test_sre
test test_sre failed -- Writing: "sre.match(r'(a)|(b)', 'b').start(1)", expected: ''
test_strftime
test test_strftime crashed -- exceptions.OverflowError: integer multiplication
test_string
test_strop
test_struct
test test_struct crashed -- exceptions.OverflowError: integer multiplication
test_sunaudiodev
test test_sunaudiodev skipped --  No module named sunaudiodev
test_thread
Traceback (most recent call last):
  File "./Lib/test/test_thread.py", line 21, in task
    delay = random.random() * numtasks
  File "/home/roland/perso/src/sourceforge/python/dist/src/Lib/whrandom.py", line 71, in random
    x = (171 * x) % 30269
OverflowError: integer multiplication

-------------------------------------------------------

Date: 2000-Oct-03 09:03
By: jhylton

Comment:
Two more questions:
1) What platform?  Is this a 64-bit machine?  A regular x86?
2) Could you run this under gdb and report where exactly the error is being generated?  The exception is raised in Objects/intobject.c.  I would set a breakpoint at the top of int_mul() and step through the function.


-------------------------------------------------------

Date: 2000-Oct-03 09:32
By: lo-lan-do

Comment:
1) Regular i686 (sez uname).
2) It seems that ah and bh are 1 and not 0 like they should.
A bit of printf-debugging shows me that LONG_BIT/2 is 32,
so somehow 1 >> 32 != 0, which seems most strange and
bizarre to me.  On the other hand, gcc tells me the following
when I compile:

intobject.c: In function `int_mul':
intobject.c:327: warning: right shift count >= width of type

I hope he [gcc] still does the rshift, but I'm no gcc guru.
Hope this helps...
-------------------------------------------------------

Date: 2000-Oct-03 10:01
By: jhylton

Comment:
This does help.  The compiler warning is a bad sign.  I notice that you're using a more recent version of gcc than I have installed.  I'll try building with a newer gcc, but in the interim it may help if you compile the following test program:

#include <stdio.h>
#include <ctype.h>

#ifndef CHAR_BIT
#define CHAR_BIT 8
#endif

#ifndef LONG_BIT
#define LONG_BIT (CHAR_BIT * sizeof(long))
#endif

int main()
{
    int a, b;
    a = 1;
    b = a;
    a = a >> (LONG_BIT / 2);
    printf("CHAR_BIT = %d, LONG_BIT = %d\n", CHAR_BIT, LONG_BIT);
    printf("%d >> %d == %d\n", b, LONG_BIT/2, a);
    return 0;
}

On my system it compiles without warning using gcc -Wall and produces the following output:

CHAR_BIT = 8, LONG_BIT = 32
1 >> 16 == 0

What output do you get?  What is sizeof(long) on your platform?  Does ctype.h define CHAR_BIT or LONG_BIT?

-------------------------------------------------------

Date: 2000-Oct-03 10:23
By: lo-lan-do

Comment:
Your test program compiles without warning and
gives the same results as yours here.
sizeof(long) is 4, limits.h defines CHAR_BIT to be 8.
LONG_BIT is defined in bits/xopen_lim.h to be 32.
-------------------------------------------------------

Date: 2000-Oct-03 10:30
By: lo-lan-do

Comment:
Now if I replace LONG_BIT/2 by LONG_BIT in your test program:
roland@cachemir /tmp $ gcc -Wall test.c && ./a.out 
test.c: In function `main':
test.c:20: warning: right shift count >= width of type
CHAR_BIT = 8, LONG_BIT = 32
1 >> 32 == 1
roland@cachemir /tmp $ 

So I guess it's really something to do with gcc.  Drat.
-------------------------------------------------------

Date: 2000-Oct-03 11:19
By: jhylton

Comment:
I'll see if I can reproduce the problem with GCC 2.95.2

-------------------------------------------------------

Date: 2000-Oct-03 14:26
By: jhylton

Comment:
I can't reproduce this on my system with gcc-2.95.2

I'm puzzled by your last comment about replacing LONG_BIT/2 with LONG_BIT and getting the warning.  I really don't understand why the code is generating a warning at compile time.

line 327 of Object/intobject.c is this right:
	ah = a >> (LONG_BIT/2);
And on your platform LONG_BIT == 32?  And it generates the warning?
Can you print the value of LONG_BIT/2 at just the time it is used in int_mul?

-------------------------------------------------------

Date: 2000-Oct-03 15:46
By: loewis

Comment:
Instead of printing the value of LONG_BIT, I recommend to compile intobject with --save-temps. When invoking make, catch the line that compiles intobject.c, copy it and add --save-temps. Then report the fragment of intobject.i that corresponds to int_mul.

Please also report the exact version of glibc you are using. 2.1.93 sometimes gets the order of includes wrong, so that LONG_BIT ends up being defined as 64.
-------------------------------------------------------

Date: 2000-Oct-04 01:46
By: lo-lan-do

Comment:
You're [Martin v. Löwis] probably right about the libc stuff.
I'm using 2.1.94 (as installed by the Debian unstable
distribution).  After inserting

printf ("ah: %d, LONG_BIT: %d, LONG_BIT/2: %d\n", ah, LONG_BIT, LONG_BIT/2);

I can clearly see that LONG_BIT is 64.  The appropriate
intobject.i section reads:

int_mul(PyIntObject *v, PyIntObject *w)
{
        long a, b, ah, bh, x, y;
        int s = 1;

        a = v->ob_ival;
        b = w->ob_ival;
        ah = a >> (64 /2);
        bh = b >> (64 /2);
        printf ("ah: %d, LONG_BIT: %d, LONG_BIT/2: %d\n", ah, 64 , 64 /2);

Does this give enough confirmation for me
to submit a Debian bug on the libc6 package?
-------------------------------------------------------

Date: 2000-Oct-04 08:34
By: lo-lan-do

Comment:
After a bit of investigation (thanks to the Debian maintainer
of libc6) it appears that #define'ing _GNU_SOURCE causes
some include file or other to do Not The Right Thing.  Namely,
#define'ing LONG_BIT to 64 while LONG_MAX is correct
(0x7FFFFFFFL).

I'll continue investigating (though maybe not as intensively, I'm
getting a bit flummoxed...)
-------------------------------------------------------

Date: 2000-Oct-04 18:55
By: tim_one

Comment:
Note that I just checked in changes to intobject.c and pyport.h to do a compile-time #error if LONG_BIT appears to be insanely defined by the platform.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115919&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 02:59:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 4 Oct 2000 18:59:24 -0700
Subject: [Python-bugs-list] [Bug #115844] OverflowError: integer multiplication
Message-ID: <200010050159.SAA27339@delerium.i.sourceforge.net>

Bug #115844, was updated on 2000-Oct-02 06:27
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: OverflowError: integer multiplication

Details: 
Python2.0b2 compiled from source on a full RH7.0 install:


Python 2.0b2 (#2, Sep 27 2000, 11:40:58) 
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> a = 5 * 5
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>>

Follow-Ups:

Date: 2000-Oct-02 06:39
By: gvanrossum

Comment:
Something very basic is wrong. What output does the test suite give? ("make test"). Please see the README for digging into this.

Note that you submitted your bug report anonymously. We can't help you very effectively unless we can exchange email with you!
-------------------------------------------------------

Date: 2000-Oct-03 08:27
By: jhylton

Comment:
Strange! Another bug about integer multiplication overflow.  The other one is on a Debian install.

-------------------------------------------------------

Date: 2000-Oct-03 10:21
By: gvanrossum

Comment:
Could it be a 64-bit bug? Otherwise I suspect a GCC bug, or a 64-bit GCC bug. Note that GCC 2.96 is bleeding edge!
-------------------------------------------------------

Date: 2000-Oct-03 10:30
By: fdrake

Comment:
I don't see any reference to GCC 2.96 on the GCC website (http://gcc.gnu.org/).  PythonLabs should be a RH7.0 box to perform testing.

This may be a duplicate of #1159191.
-------------------------------------------------------

Date: 2000-Oct-03 11:17
By: jhylton

Comment:
This bug has also been reported on a system using gcc2.95, so I'm going try with that version of GCC.  It doesn't sound like this is a 64-bit platform; does RH7 run on a 64-bit platform?  It does appear that the problem is caused by LONG_BIT being too big resulting in a bogus shift.

-------------------------------------------------------

Date: 2000-Oct-04 18:59
By: tim_one

Comment:
Note that I just checked in changes to intobject.c and pyport.h to do a compile-time #error if LONG_BIT appears to be insanely defined by the platform.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115844&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 04:02:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 4 Oct 2000 20:02:09 -0700
Subject: [Python-bugs-list] [Bug #115987] Crash in __coerce__ (2.0b2)
Message-ID: <200010050302.UAA04621@bush.i.sourceforge.net>

Bug #115987, was updated on 2000-Oct-04 01:26
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: Crash in __coerce__ (2.0b2)

Details: The example below results in a hard crash (Application Error) on w2k.

Python 2.0b2 (#6, Sep 26 2000, 14:59:21) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> class A:
...     def __init__(self, v):
...         self.v = v
...     def __iadd__(self, v):
...         return self.v + v
...     def __coerce__(self, x):
...         print "__coerce__", v
...
>>> a = A(5)
>>> a += 6
__coerce__


The instruction at "0x1e127647" referenced memory as 0x00000046". The memory could not be "read".


Follow-Ups:

Date: 2000-Oct-04 06:18
By: fdrake

Comment:
On Linux, I get the expected NameError after it prints "__coerce__".

Assigned to TIm since this appears to be Windows-specific.
-------------------------------------------------------

Date: 2000-Oct-04 20:02
By: tim_one

Comment:
Reassigned to Thomas, removed Platform-Specific.

INPLACE_ADD is leaving trash on the eval stack here, so what happens after that is a crap shoot (Windows just happens to blow up doing Py_INCREF(that_trash) later).

INPLACE_ADD calls PyNumber_InPlaceAdd.
That calls PyInstance_HalfBinOp.
That calls the __coerce__ method, which prints "__coerce__", wants to raise a NameError, and "coerced" is NULL.
So PyInstance_HalfBinOp returns -1, but has never stored into its **r_result argument.
Its **r_result argument was PyNumber_InPlaceAdd's &x, where x is an uninitialized local PyObject*.
PyNumber_InPlaceAdd returns this stack trash as its result.
INPLACE_ADD then pushes the trash on Python's stack.
Since the trash didn't happen to be NULL on Windows, ceval thinks everything is fine and continues on to the STORE_NAME opcode (which eventually leads to the blowup).

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115987&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 04:42:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 4 Oct 2000 20:42:53 -0700
Subject: [Python-bugs-list] [Bug #115690] Dr. Watson error on Python2.0b2 Idle 0.6 WinNT4.0 SP6
Message-ID: <200010050342.UAA06025@bush.i.sourceforge.net>

Bug #115690, was updated on 2000-Sep-29 14:55
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: Dr. Watson error on Python2.0b2 Idle 0.6 WinNT4.0 SP6

Details: I get a Dr. Watson error:

    pythonw.exe
    Exception: access violation (0xc0000005), 
    Address: 0x00e31652

when I run the following code in Idle 0.6, using Edit->Run Script:

---%<---cut---%<---

import unicodedata
for c in range(0x10000):
    x=unichr(c)
    try:
        b = unicodedata.numeric(x)
        #print "numeric:", repr(x)
        try:
            a = unicodedata.digit(x)
            if a != b:
                print "bad" , repr(x)
        except:
            print "Numeric but not digit", hex(c), x.encode("utf8"), \
                  "numeric ->", b
    except:
        pass

---%<---cut---%<---

(This code was recently posted on python-dev)

I've modified my .idle file, adding 

    [EditorWindow]
    font-name=tahoma


Follow-Ups:

Date: 2000-Sep-29 21:42
By: jhylton

Comment:
Marc-Andre can you check whether this is a Unicode bug that is going to come up with or without idle.  If it seems Idle specific, please assign it to Guido or Tim.  If not, it's yours :-).


-------------------------------------------------------

Date: 2000-Oct-03 10:23
By: lemburg

Comment:
I can't reproduce this on Linux, so it seems that it is related to the way TCL/Tk
displays UTF-8 data. Another possibility would be an optimization error
which doesn't happen with gcc.

Tim, could you try this on Windows and possibly tell me where the segfault
occurs in the code ?

-------------------------------------------------------

Date: 2000-Oct-03 11:27
By: gvanrossum

Comment:
Can't reproduce it on Win98SE either. (And I did try setting font-name to tahoma.)
-------------------------------------------------------

Date: 2000-Oct-04 20:42
By: tim_one

Comment:
Assigned back to Guido, because it appears identical to bug 113803, which Guido assigned to himself.

Guido, I can reproduce the problem, and regardless of font (e.g., let it use the default) on Win98SE by letting the program run to completion, and then hitting the ENTER key *twice* (first time gets an IDLE prompt, second time blows up).  It's in exactly the same place then as 113803, trying to decref a NULL pointer in _tkinter.c's AsString.

Note that there *may* be another bug here specific to NT and/or W2K too, in that W9x have much feebler Unicode support.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115690&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 09:24:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 01:24:24 -0700
Subject: [Python-bugs-list] [Bug #115919] Integer multiplication overflow
Message-ID: <200010050824.BAA15951@bush.i.sourceforge.net>

Bug #115919, was updated on 2000-Oct-03 08:01
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: Integer multiplication overflow

Details: roland@cachemir ~ $ python2.0 
Python 2.0b2 (#3, Oct  3 2000, 16:30:25) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> 1+1
2
>>> 1*1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>> 

Last CVS update 2000-10-03 around 14:00 UTC.  Last before that was some weeks ago, sorry for not being precise.  Compiled with ./configure --prefix=/usr/local/ && make, su and make install.  Only personal change is the use of readline in Modules/Setup.local.  Did I do something wrong?

Follow-Ups:

Date: 2000-Oct-03 08:25
By: jhylton

Comment:
What happens when you run "make test"?  It looks like there is something fundamentally broken, but I can't tell what it is.  If 1*1 fails, I expect the rest of the test suite to also report errors.


-------------------------------------------------------

Date: 2000-Oct-03 08:38
By: lo-lan-do

Comment:
make test shows me plenty of lines looking like this one (except the name of the test changes):

test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication

I also get messages along the lines of 'test test_dbm skipped --  No module named dbm', but I guess these ones are OK.
-------------------------------------------------------

Date: 2000-Oct-03 08:40
By: jhylton

Comment:
Can you include the complete output?

-------------------------------------------------------

Date: 2000-Oct-03 09:02
By: lo-lan-do

Comment:
[In case the bug would be caused by a recent upgrade to a beta glibc, I tried the '1*1' test with Python 1.5.2.  No bug visible there.]

$ make distclean && ./configure --prefix=/usr/local/ && make
$ make test &> test.log

It seems that 'make test' somehow hangs when testing threads, so I cut at that point.  I hope the relevant info is shown before that point.
Here goes...

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Unhandled exception in thread:
test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication
test_opcodes
test_operations
test_builtin
test test_builtin crashed -- exceptions.OverflowError: integer multiplication
test_exceptions
test_types
test test_types crashed -- exceptions.OverflowError: integer multiplication
test_MimeWriter
test_StringIO
test_al
test test_al skipped --  No module named al
test_array
test test_array crashed -- exceptions.OverflowError: integer multiplication
test_atexit
test_audioop
test test_audioop skipped --  No module named audioop
test_augassign
test test_augassign crashed -- exceptions.OverflowError: integer multiplication
test_binascii
test_binhex
test test_binhex crashed -- exceptions.OverflowError: integer multiplication
test_bsddb
test_cd
test test_cd skipped --  No module named cd
test_cfgparser
test test_cfgparser crashed -- exceptions.OverflowError: integer multiplication
test_cgi
test test_cgi crashed -- exceptions.OverflowError: integer multiplication
test_cl
test test_cl skipped --  No module named cl
test_class
test_cmath
test_compile
test_contains
test_cookie
test test_cookie crashed -- exceptions.OverflowError: integer multiplication
test_cpickle
test_crypt
test test_crypt skipped --  No module named crypt
test_dbm
test test_dbm skipped --  No module named dbm
test_dl
test test_dl skipped --  No module named dl
test_dospath
test_errno
test_extcall
test_fcntl
test_file
test_fork1
test_format
test_gc
test_gdbm
test test_gdbm skipped --  No module named gdbm
test_getopt
test_gettext
test test_gettext crashed -- exceptions.OverflowError: integer multiplication
test_gl
test test_gl skipped --  No module named gl
test_grp
test_gzip
test test_gzip skipped --  No module named zlib
test_hash
test_imageop
test test_imageop skipped --  No module named imageop
test_imgfile
test test_imgfile skipped --  No module named imgfile
test_largefile
test test_largefile skipped --  platform does not have largefile support
test_linuxaudiodev
test test_linuxaudiodev skipped --  No module named linuxaudiodev
test_long
test test_long crashed -- exceptions.OverflowError: integer multiplication
test_longexp
test_math
test_md5
test_mimetools
test test_mimetools crashed -- exceptions.AttributeError: encode
test_minidom
test test_minidom skipped --  No module named pyexpat
test_mmap
test test_mmap crashed -- exceptions.OverflowError: integer multiplication
test_new
test_nis
test test_nis skipped --  No module named nis
test_ntpath
test_openpty
test_operator
test test_operator failed -- Writing: 'mul(5, 2) = <class exceptions.OverflowError at 0x818f41c>: 10 expected', expected: 'testing:
 neg\012testing: or_\012testing: pos\012testing: repeat\012testing: rshift'
test_parser
test_pickle
test_pkg
test_poll
test test_poll crashed -- exceptions.OverflowError: integer multiplication
test_popen2
test_posixpath
test_pow
test test_pow crashed -- exceptions.OverflowError: integer multiplication
test_pty
test test_pty skipped --  No module named termios
test_pwd
test_pyexpat
test test_pyexpat skipped --  cannot import name expat
test_re
test test_re crashed -- exceptions.OverflowError: integer multiplication
test_regex
test_rfc822
test test_rfc822 crashed -- exceptions.OverflowError: integer multiplication
test_rgbimg
test test_rgbimg skipped --  No module named rgbimg
test_rotor
test_sax
test test_sax skipped --  cannot import name expat
test_select
test_sha
test_signal
test_socket
test_sre
test test_sre failed -- Writing: "sre.match(r'(a)|(b)', 'b').start(1)", expected: ''
test_strftime
test test_strftime crashed -- exceptions.OverflowError: integer multiplication
test_string
test_strop
test_struct
test test_struct crashed -- exceptions.OverflowError: integer multiplication
test_sunaudiodev
test test_sunaudiodev skipped --  No module named sunaudiodev
test_thread
Traceback (most recent call last):
  File "./Lib/test/test_thread.py", line 21, in task
    delay = random.random() * numtasks
  File "/home/roland/perso/src/sourceforge/python/dist/src/Lib/whrandom.py", line 71, in random
    x = (171 * x) % 30269
OverflowError: integer multiplication

-------------------------------------------------------

Date: 2000-Oct-03 09:03
By: jhylton

Comment:
Two more questions:
1) What platform?  Is this a 64-bit machine?  A regular x86?
2) Could you run this under gdb and report where exactly the error is being generated?  The exception is raised in Objects/intobject.c.  I would set a breakpoint at the top of int_mul() and step through the function.


-------------------------------------------------------

Date: 2000-Oct-03 09:32
By: lo-lan-do

Comment:
1) Regular i686 (sez uname).
2) It seems that ah and bh are 1 and not 0 like they should.
A bit of printf-debugging shows me that LONG_BIT/2 is 32,
so somehow 1 >> 32 != 0, which seems most strange and
bizarre to me.  On the other hand, gcc tells me the following
when I compile:

intobject.c: In function `int_mul':
intobject.c:327: warning: right shift count >= width of type

I hope he [gcc] still does the rshift, but I'm no gcc guru.
Hope this helps...
-------------------------------------------------------

Date: 2000-Oct-03 10:01
By: jhylton

Comment:
This does help.  The compiler warning is a bad sign.  I notice that you're using a more recent version of gcc than I have installed.  I'll try building with a newer gcc, but in the interim it may help if you compile the following test program:

#include <stdio.h>
#include <ctype.h>

#ifndef CHAR_BIT
#define CHAR_BIT 8
#endif

#ifndef LONG_BIT
#define LONG_BIT (CHAR_BIT * sizeof(long))
#endif

int main()
{
    int a, b;
    a = 1;
    b = a;
    a = a >> (LONG_BIT / 2);
    printf("CHAR_BIT = %d, LONG_BIT = %d\n", CHAR_BIT, LONG_BIT);
    printf("%d >> %d == %d\n", b, LONG_BIT/2, a);
    return 0;
}

On my system it compiles without warning using gcc -Wall and produces the following output:

CHAR_BIT = 8, LONG_BIT = 32
1 >> 16 == 0

What output do you get?  What is sizeof(long) on your platform?  Does ctype.h define CHAR_BIT or LONG_BIT?

-------------------------------------------------------

Date: 2000-Oct-03 10:23
By: lo-lan-do

Comment:
Your test program compiles without warning and
gives the same results as yours here.
sizeof(long) is 4, limits.h defines CHAR_BIT to be 8.
LONG_BIT is defined in bits/xopen_lim.h to be 32.
-------------------------------------------------------

Date: 2000-Oct-03 10:30
By: lo-lan-do

Comment:
Now if I replace LONG_BIT/2 by LONG_BIT in your test program:
roland@cachemir /tmp $ gcc -Wall test.c && ./a.out 
test.c: In function `main':
test.c:20: warning: right shift count >= width of type
CHAR_BIT = 8, LONG_BIT = 32
1 >> 32 == 1
roland@cachemir /tmp $ 

So I guess it's really something to do with gcc.  Drat.
-------------------------------------------------------

Date: 2000-Oct-03 11:19
By: jhylton

Comment:
I'll see if I can reproduce the problem with GCC 2.95.2

-------------------------------------------------------

Date: 2000-Oct-03 14:26
By: jhylton

Comment:
I can't reproduce this on my system with gcc-2.95.2

I'm puzzled by your last comment about replacing LONG_BIT/2 with LONG_BIT and getting the warning.  I really don't understand why the code is generating a warning at compile time.

line 327 of Object/intobject.c is this right:
	ah = a >> (LONG_BIT/2);
And on your platform LONG_BIT == 32?  And it generates the warning?
Can you print the value of LONG_BIT/2 at just the time it is used in int_mul?

-------------------------------------------------------

Date: 2000-Oct-03 15:46
By: loewis

Comment:
Instead of printing the value of LONG_BIT, I recommend to compile intobject with --save-temps. When invoking make, catch the line that compiles intobject.c, copy it and add --save-temps. Then report the fragment of intobject.i that corresponds to int_mul.

Please also report the exact version of glibc you are using. 2.1.93 sometimes gets the order of includes wrong, so that LONG_BIT ends up being defined as 64.
-------------------------------------------------------

Date: 2000-Oct-04 01:46
By: lo-lan-do

Comment:
You're [Martin v. Löwis] probably right about the libc stuff.
I'm using 2.1.94 (as installed by the Debian unstable
distribution).  After inserting

printf ("ah: %d, LONG_BIT: %d, LONG_BIT/2: %d\n", ah, LONG_BIT, LONG_BIT/2);

I can clearly see that LONG_BIT is 64.  The appropriate
intobject.i section reads:

int_mul(PyIntObject *v, PyIntObject *w)
{
        long a, b, ah, bh, x, y;
        int s = 1;

        a = v->ob_ival;
        b = w->ob_ival;
        ah = a >> (64 /2);
        bh = b >> (64 /2);
        printf ("ah: %d, LONG_BIT: %d, LONG_BIT/2: %d\n", ah, 64 , 64 /2);

Does this give enough confirmation for me
to submit a Debian bug on the libc6 package?
-------------------------------------------------------

Date: 2000-Oct-04 08:34
By: lo-lan-do

Comment:
After a bit of investigation (thanks to the Debian maintainer
of libc6) it appears that #define'ing _GNU_SOURCE causes
some include file or other to do Not The Right Thing.  Namely,
#define'ing LONG_BIT to 64 while LONG_MAX is correct
(0x7FFFFFFFL).

I'll continue investigating (though maybe not as intensively, I'm
getting a bit flummoxed...)
-------------------------------------------------------

Date: 2000-Oct-04 18:55
By: tim_one

Comment:
Note that I just checked in changes to intobject.c and pyport.h to do a compile-time #error if LONG_BIT appears to be insanely defined by the platform.
-------------------------------------------------------

Date: 2000-Oct-05 01:24
By: lo-lan-do

Comment:
True.  And I confirm that this breaks compilation
on my system :-)

I'll try to get in touch with the Debian libc
maintainer to see if that's Debian-specific or
not.  I trust him to forward the bug report upstream
if need be.  Stay tuned.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115919&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 13:21:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 05:21:09 -0700
Subject: [Python-bugs-list] [Bug #116117] cmath & umath fail to load on HPUX10.2
Message-ID: <200010051221.FAA24996@bush.i.sourceforge.net>

Bug #116117, was updated on 2000-Oct-05 05:21
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: cmath & umath fail to load on HPUX10.2

Details: Happens for builds of Python 1.6
with either cc or gcc.  I was able to fix this by adding "-lm" to
the build lines for both cmathmodule.sl and mathmodule.sl.
The problem does not occur with HPUX11.

Seems like one needs a SHLIB_LIBS variable in configure
or some such?

(To test, one just starts up python - built with shared modules -
and says "import math")



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116117&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 13:36:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 05:36:09 -0700
Subject: [Python-bugs-list] [Bug #116121] cmath & umath fail to load on HPUX10.2
Message-ID: <200010051236.FAA17426@delerium.i.sourceforge.net>

Bug #116121, was updated on 2000-Oct-05 05:36
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: cmath & umath fail to load on HPUX10.2

Details: Happens for builds of Python 1.6
with either cc or gcc.  I was able to fix this by adding "-lm" to
the build lines for both cmathmodule.sl and mathmodule.sl.
The problem does not occur with HPUX11.

Seems like one needs a SHLIB_LIBS variable in configure
or some such?

(To test, one just starts up python - built with shared modules -
and says "import math")



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116121&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 13:44:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 05:44:56 -0700
Subject: [Python-bugs-list] [Bug #115987] Crash in __coerce__ (2.0b2)
Message-ID: <200010051244.FAA17766@delerium.i.sourceforge.net>

Bug #115987, was updated on 2000-Oct-04 01:26
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Summary: Crash in __coerce__ (2.0b2)

Details: The example below results in a hard crash (Application Error) on w2k.

Python 2.0b2 (#6, Sep 26 2000, 14:59:21) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> class A:
...     def __init__(self, v):
...         self.v = v
...     def __iadd__(self, v):
...         return self.v + v
...     def __coerce__(self, x):
...         print "__coerce__", v
...
>>> a = A(5)
>>> a += 6
__coerce__


The instruction at "0x1e127647" referenced memory as 0x00000046". The memory could not be "read".


Follow-Ups:

Date: 2000-Oct-04 06:18
By: fdrake

Comment:
On Linux, I get the expected NameError after it prints "__coerce__".

Assigned to TIm since this appears to be Windows-specific.
-------------------------------------------------------

Date: 2000-Oct-04 20:02
By: tim_one

Comment:
Reassigned to Thomas, removed Platform-Specific.

INPLACE_ADD is leaving trash on the eval stack here, so what happens after that is a crap shoot (Windows just happens to blow up doing Py_INCREF(that_trash) later).

INPLACE_ADD calls PyNumber_InPlaceAdd.
That calls PyInstance_HalfBinOp.
That calls the __coerce__ method, which prints "__coerce__", wants to raise a NameError, and "coerced" is NULL.
So PyInstance_HalfBinOp returns -1, but has never stored into its **r_result argument.
Its **r_result argument was PyNumber_InPlaceAdd's &x, where x is an uninitialized local PyObject*.
PyNumber_InPlaceAdd returns this stack trash as its result.
INPLACE_ADD then pushes the trash on Python's stack.
Since the trash didn't happen to be NULL on Windows, ceval thinks everything is fine and continues on to the STORE_NAME opcode (which eventually leads to the blowup).

-------------------------------------------------------

Date: 2000-Oct-05 05:44
By: twouters

Comment:
Confirmed Tim's analysis, fixed it in the obvious way: initializing the local pointer explicitly to NULL. And the same for all InPlace* functions that call PyInstance_HalfBinOp() themselves. The problem did not occur for the normal functions, because they call PyInstance_DoBinOp() which explicitly initializes the result object itself.

Fixed in revision 2.55 of Objects/abstract.c.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115987&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 15:00:19 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 07:00:19 -0700
Subject: [Python-bugs-list] [Bug #116048] BeOpen Python 2.0b2 RPM does not include python2.0 binary
Message-ID: <200010051400.HAA20801@delerium.i.sourceforge.net>

Bug #116048, was updated on 2000-Oct-04 13:42
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Summary: BeOpen Python 2.0b2 RPM does not include python2.0 binary

Details: When installing Python from the source distribution, 'make install' provides a 'python2.0' binary. Being able to rely on that is convenient for script authors, as they can express that a certain script needs python2 to work.

The BeOpen Linux RPM does not include that binary, so scripts expecting it won't work with it.

Follow-Ups:

Date: 2000-Oct-05 07:00
By: jhylton

Comment:
It will be included in the next version of the RPMs.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116048&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 15:01:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 07:01:52 -0700
Subject: [Python-bugs-list] [Bug #116011] PyPort.h backward compatibility issues missing
Message-ID: <200010051401.HAA20841@delerium.i.sourceforge.net>

Bug #116011, was updated on 2000-Oct-04 08:23
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 7
Summary: PyPort.h backward compatibility issues missing

Details: PyPort.h contain only Py_PROTO for backward compatibility.
I'm thinking about add also the "Py_FPROTO" ghost macro, this may speed up code porting to the new version.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116011&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 15:02:22 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 07:02:22 -0700
Subject: [Python-bugs-list] [Bug #116117] cmath & umath fail to load on HPUX10.2
Message-ID: <200010051402.HAA20937@delerium.i.sourceforge.net>

Bug #116117, was updated on 2000-Oct-05 05:21
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: cmath & umath fail to load on HPUX10.2

Details: Happens for builds of Python 1.6
with either cc or gcc.  I was able to fix this by adding "-lm" to
the build lines for both cmathmodule.sl and mathmodule.sl.
The problem does not occur with HPUX11.

Seems like one needs a SHLIB_LIBS variable in configure
or some such?

(To test, one just starts up python - built with shared modules -
and says "import math")



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116117&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 15:05:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 07:05:27 -0700
Subject: [Python-bugs-list] [Bug #116121] cmath & umath fail to load on HPUX10.2
Message-ID: <200010051405.HAA21013@delerium.i.sourceforge.net>

Bug #116121, was updated on 2000-Oct-05 05:36
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Duplicate
Bug Group: Platform-specific
Priority: 5
Summary: cmath & umath fail to load on HPUX10.2

Details: Happens for builds of Python 1.6
with either cc or gcc.  I was able to fix this by adding "-lm" to
the build lines for both cmathmodule.sl and mathmodule.sl.
The problem does not occur with HPUX11.

Seems like one needs a SHLIB_LIBS variable in configure
or some such?

(To test, one just starts up python - built with shared modules -
and says "import math")



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116121&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 15:17:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 07:17:16 -0700
Subject: [Python-bugs-list] [Bug #115469] test_socket hangs on Debian Linux 2.2
Message-ID: <200010051417.HAA21531@delerium.i.sourceforge.net>

Bug #115469, was updated on 2000-Sep-27 01:54
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: test_socket hangs on Debian Linux 2.2

Details: The test runs until it prints "child connecting" and then just hangs. Pressing C-c causes a traceback that points at the
s.accept() call in line 105.

uname -a says
Linux pc-larsga 2.0.36 #2 Sun Jan 17 19:38:45 EST 1999 i686  unknown

ldd python says
libdl.so.2 => /lib/libdl.so.2 (0x4001a000)
libm.so.6 => /lib/libm.so.6 (0x4001e000)
libc.so.6 => /lib/libc.so.6 (0x4003b000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

This bug is probably related to 115221.

Follow-Ups:

Date: 2000-Sep-27 11:04
By: nascheme

Comment:
I can't reproduce this on my Debian 2.2 machine running 
Linux 2.2.16.  Which libc6 are you using (dpkg -l libc6)?  
Also, it is possible that something is wrong with the loopback network.  The output from "netstat -tnp; ifconfig lo" taken during the hang may be helpful
-------------------------------------------------------

Date: 2000-Oct-05 07:17
By: jhylton

Comment:
Lars-- Is this still a problem for you?  Can you provide any of the information Neil asked for?  If not, I think we should assume it is a Debian problem.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115469&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 15:17:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 07:17:52 -0700
Subject: [Python-bugs-list] [Bug #115221] test_poll hangs on Debian Linux 2.2
Message-ID: <200010051417.HAA21535@delerium.i.sourceforge.net>

Bug #115221, was updated on 2000-Sep-24 07:38
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: test_poll hangs on Debian Linux 2.2

Details: When run from the command-line test_poll.py prints
"This is a test." 12 times and then hangs, without ever printing "Poll test 1 complete".

All other tests seem to work just fine.

Follow-Ups:

Date: 2000-Sep-27 10:58
By: nascheme

Comment:
I can't reproduce this on my Debian 2.2 system running Linux
 2.2.16.  Can you give the output from "uname -a" and "dpkg 
-l libc6"?  I am using libc6 2.1.3-13.
-------------------------------------------------------

Date: 2000-Oct-05 07:17
By: jhylton

Comment:
Andrew -- Is this still a problem for you?  
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115221&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 15:21:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 07:21:34 -0700
Subject: [Python-bugs-list] [Bug #116136] reindent hits sre recursion limit in tokenize
Message-ID: <200010051421.HAA29693@bush.i.sourceforge.net>

Bug #116136, was updated on 2000-Oct-05 07:21
Here is a current snapshot of the bug.

Project: Python
Category: demos and tools
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: reindent hits sre recursion limit in tokenize

Details: While running Tim Peters' new reindent script over my code,
I received the following traceback:

checking ./dtcout.py ...
Traceback (most recent call last):
  File "/usr/local/bin/reindent", line 258, in ?
    main()
  File "/usr/local/bin/reindent", line 65, in main
    check(arg)
  File "/usr/local/bin/reindent", line 77, in check
    check(fullname)
  File "/usr/local/bin/reindent", line 90, in check
    if r.run():
  File "/usr/local/bin/reindent", line 135, in run
    tokenize.tokenize(self.getline, self.tokeneater)
  File "/usr/local/lib/python2.0/tokenize.py", line 152, in tokenize
    pseudomatch = pseudoprog.match(line, pos)
RuntimeError: maximum recursion limit exceeded

The pattern compiled into pseudoprog is

[ \f\t]*((\\\r?\n|#[^\r\n]*|([rR]?'''|[rR]?"""))|((0[jJ]|[1-9]\d*[jJ]|((\d+\.\d*|\.\d+)([eE][-+]?\d+)?|[1-9]\d*[eE][-+]?\d+)[jJ])|((\d+\.\d*|\.\d+)([eE][-+]?\d+)?|[1-9]\d*[eE][-+]?\d+)|(0[xX][\da-fA-F]*[lL]?|0[0-7]*[lL]?|[1-9]\d*[lL]?))|((\+=|\-=|\*=|%=|/=|\*\*=|&=|\|=|\^=|>>=|<<=|\+|\-|\*\*|\*|\^|~|/|%|&|\||<<|>>|==|<=|<>|!=|>=|=|<|>)|[][(){}]|(\r?\n|[:;.,`]))|([rR]?'(\\.|[^\n'\\])*('|\\\r?\n)|[rR]?"(\\.|[^\n"\\])*("|\\\r?\n))|[a-zA-Z_]\w*)

I am not even going to try to figure out what part of the re triggers the excessive recursion.  Here is the source file reindent was munching on when the exception was raised.  Hopefully the bug submission process won't destroy it.  If so, let me know (skip@mojam.com) and I'll send it to you.

def dtmlfunc(**__d):
    import sys, urllib, string
    output = []
    append = output.append
    append('<!-- Generated: Wed Mar 10 12:13:08 1999 -->')
    append('\012<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> <!-- -*-html-helper -*- -->\012<HTML>\012<HEAD>\012<TITLE>Musi-Cal Search: ')
    append("""%s""" % __d['search_key'])
    append('</TITLE>\012<LINK REV="made" HREF="mailto:concertmaster@musi-cal.com">\012</HEAD>\012<BODY bgcolor="#ffffff" text="#000000" link="#CC0000" alink="#FF3300" vlink="#330099"\012>\012\012')
    append("""%s""" % __d['banner'])
    append('\012\012<H2 align="center">Musi-Cal Search Response</H2>\012\012')
    if __d['repeat_msg']:
        append('\012  ')
        append("""%s""" % __d['repeat_msg'])
        append('\012  <hr>\012')
    append('\012\012')
    if __d['entries']:
        append('\012\012    ')
        if __d['indirect']:
            append('\012      <P>\012      You can invoke this search using the following URL.\012      Why not save it for future reference?\012      <p align=center><code>http://')
            append("""%s""" % __d['servername'])
            append('/cgi-bin/event-search?')
            append("""%s""" % __d['query_string'])
            append('</code></p>\012    ')
        append('\012    \012    <p>\012    Click <img src="http://www.musi-cal.com/icons/vdb10.gif" alt="[VDB]"> to look up venue information.<br>\012    ')
        if __d['next']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['next'])
            append('">[Next Page]</a>\012    </font>\012    ')
        append('\012    ')
        if __d['prev']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['prev'])
            append('">[Previous Page]</a><br>\012    </font>\012    ')
        else:
            append('\012      ')
            if __d['next']:
                append('<br>')
            append('\012    ')
        append('\012\012    <TABLE border=0 cellspacing="5" cellpadding="0" width="100%">\012\012    ')
        __i_entries = -1
        for __elt_entries in __d['entries']:
            __i_entries = __i_entries + 1
            append('\012\012\011<tr valign=middle>\012\012\011')
            if __d['editor']:
                append('\012\011  <TD><A href="http://')
                append("""%s""" % __d['servername'])
                append('/cgi-bin/edit-entry?editor=')
                try: append(urllib.quote(__d['editor']))
                except: append(__d['editor'].urllib.quote())
                append('&key=')
                append("""%s""" % __elt_entries['key'])
                append('">[Edit]</A><BR><A href="http://')
                append("""%s""" % __d['servername'])
                append('/cgi-bin/edit-entry?editor=')
                try: append(urllib.quote(__d['editor']))
                except: append(__d['editor'].urllib.quote())
                append('&key=')
                append("""%s""" % __elt_entries['key'])
                append('&zap=1">[Delete]</A>\012\011  <br><font size="-1">Submitter: ')
                try: append(get_email(__elt_entries))
                except: append(__elt_entries.get_email())
                append('</font>\012\011')
            else:
                append('\012\011  ')
                if __d['show_vcal']:
                    append('<TD><A href="http://')
                    append("""%s""" % __d['servername'])
                    append('/cgi-bin/gencal?type=vCalendar&key=')
                    append("""%s""" % __elt_entries['key'])
                    append('"><IMG SRC="/images/vcal.gif" ALIGN="top" ALT="vCal" width="16" height="16" border="0"></A>')
                append('\012\011')
            append('\012\012    ')
            try: append(html(__elt_entries))
            except: append(__elt_entries.html())
            append('\012\012    ')
            if (__i_entries == 0):
                append('\012\011')
                if __d['display_static']:
                    append('\012\011<td width="25%" valign=top rowspan=')
                    append("""%s""" % len(__d['entries']))
                    append('>\012\011    ')
                    if __d['static_info']:
                        append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><font size="+1"><a name="staticinfo">Notes Index</a></font></th></tr>\012\011\011  </table>\012\012\011\011')
                        if __d['stperformers']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stperf">Performers</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stperformers'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stcontributors']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th>Contributors</th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stcontributors'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stvenues']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stven">Venues</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stvenues'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stevents']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stev">Events</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stevents'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stcities']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stcity">Cities</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stcities'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011<font size="-1">You can <strong><a\012\011\011href="http://www.musi-cal.com/addstatic.shtml">add</a></strong> or\012\011\011<strong><a href="http://www.musi-cal.com/editstatic.shtml">edit</a></strong>\012\011\011Notes Index items too!</font>\012\012\011    ')
                    append('\012\011    <p>\012\011    <a href="http://www.musi-cal.com/cgi-bin/redirect/http%3a//www.amazon.com/exec/obidos/redirect-home/musical">\012\011    <img src="http://www.musi-cal.com/icons/amzn-assoc.gif" border="0" alt="In Association with Amazon.com"></a> \012\011</td>\012\011')
                append('\012    ')
            append('\012\012    ')
        append('\012\012    </TABLE>\012\012    ')
        if __d['next']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['next'])
            append('">[Next Page]</a>\012    </font>\012    ')
        append('\012    ')
        if __d['prev']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['prev'])
            append('">[Previous Page]</a><br>\012    </font>\012    ')
        else:
            append('\012      ')
            if __d['next']:
                append('<br>')
            append('\012    ')
        append('\012\012    <P>Check with venues before making plans to attend listed events.\012\012    <P>If you notice any errors, <A\012    href="mailto:concertmaster@musi-cal.com">please let us know</A> so we can\012    correct them.\012\012')
    else:
        append('\012\012    ')
        if __d['searchbyperformer']:
            append('\012      <p>We were not able to find any matches to your search.  It\'s possible\012      the artist you were searching for is not on tour or that we don\'t\012      currently have their dates in our database. You might also try <a\012      href="http://')
            append("""%s""" % __d['servername'])
            append('/cgi-bin/list-perf">browsing by performer</a>\012      in case you\'ve misspelled their name.\012      If you know of a possible source for their concert schedule,\012      <a href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\012      ')
            if __d['stperformers']:
                append('\012\011<table width="100%" cellpadding=2>\012\011<tr><th><a name="stperf">Performers</a></th></tr>\012\011<tr><td textcolor="black" bgcolor="white">\012\011  <font size="-1">\012\011  ')
                append("""%s""" % __d['stperformers'])
                append('\012\011  </font>\012\011  </td></tr>\012\011</table>\012     ')
            append('\012\012   ')
        else:
            append('\012      ')
            if __d['searchbyvenue']:
                append('\012\011<p>We were not able to find any matches to your search.  Venue\012\011names can often spelled several different ways.  You might try\012\011searching for just a single word in the venue\'s name, such as\012\011<strong>Passim</strong> instead of <strong>Club Passim</strong>.\012\011Also, some venues, such as church-sponsored coffeehouses, may\012\011be listed either under the name of the coffeehouse or the name\012\011of the hosting venue.\012\011We may also not have their schedule in our database.\012\011If you know of a possible source for their concert schedule,\012\011<a href="mailto:concertmaster@musi-cal.com">let us know</a>.\012      ')
            else:
                append('\012\011')
                if __d['searchbyevent']:
                    append('\012\011  <p>We were not able to find any matches to your search.\012\011  If you know of a possible source for event schedules,\012\011  <a href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\011')
                else:
                    append('\012\011  ')
                    if __d['searchbylocation']:
                        append('\012      <p>We were not able to find any matches to your search.\012      Please check that the city, state and country names are\012      spelled or abbreviated properly.  You might also try <a\012      href="http://')
                        append("""%s""" % __d['servername'])
                        append('/index-geog.shtml">browsing by location</a>\012      in case you misspelled the name. If you know of a\012      possible source of concert schedules for this region, <a\012      href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\011  ')
                    else:
                        append('\012      <p>We were not able to find any matches to your search.\012      If you know of a possible source of concert schedules\012      that would fill a hole in our database, <a\012      href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\011  ')
                    append('\012\011')
                append('\012      ')
            append('\012    ')
        append('\012\012')
    append('\012\012<P ALIGN="center"><CENTER>\012<p>\012<FORM METHOD="GET" ACTION="http://')
    append("""%s""" % __d['servername'])
    append('/cgi-bin/simple-search">\012<input type=radio name="key" value="performer">performer\012<input type=radio checked name="key" value="city">city\012<input type=radio name="key" value="venue">venue\012<input type=radio name="key" value="event">event<br>\012Search for: <INPUT TYPE="text" NAME="value">\012<input type="submit" value="OK">\012<br>')
    append("""%s""" % __d['survey'])
    append('\012</FORM></CENTER>\012\012\012<p align=center>\012<strong><font size="-1"><a href="/index-contribute.shtml"\012onMouseOver="window.status=\'Add events or Notes Index entries to the database\'; return true">Contribute</a> | <a href="/index-search.shtml"\012onMouseOver="window.status=\'Search the database in several ways\'; return true">Search</a> | <a href="/index-sponsor.shtml"\012onMouseOver="window.status=\'Advertise in Musi-Cal!\'; return true">Advertise</a> | <a href="/index-contents.shtml"\012onMouseOver="window.status=\'Let your mousey to the walking...\';return true">Contents</a> | <a href="/index-learn.shtml"\012onMouseOver="window.status=\'Stuck? Get help here...\'; return true">Help</a> | <a href="/Faq.shtml"\012onMouseOver="window.status=\'You got questions? We got answers...\'; return true">FAQ</a></font></strong>\012\012\012<p align=center>\012<A HREF="http://www.musi-cal.com/"><IMG border=0 WIDTH=23 HEIGHT=33 SRC="http://www.musi-cal.com/icons/not!
e.gif" ALT="[Musi-Cal Home Page]"></A>\012\012<font size="-1"><a href="mailto:concertmaster@musi-cal.com">Contact Us!</a><br><em>Copyright &#169; 1994-1999, Automatrix, Inc.</em>\012</font>\012\012\012\012</BODY>\012</HTML>\012')
    return string.join(output, '')


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116136&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 15:23:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 07:23:06 -0700
Subject: [Python-bugs-list] [Bug #110644] bug in PyLong_FromLongLong (PR#324)
Message-ID: <200010051423.HAA21763@delerium.i.sourceforge.net>

Bug #110644, was updated on 2000-Jul-31 14:10
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Summary: bug in PyLong_FromLongLong (PR#324)

Details: Jitterbug-Id: 324
Submitted-By: Thomas.Malik@t-online.de
Date: Wed, 10 May 2000 15:37:28 -0400 (EDT)
Version: 1.5.2
OS: all


there's a bug in PyLong_FromLongLong, resulting in truncation of negative 64 bit
integers. PyLong_FromLongLong starts with: 
	if( ival <= (LONG_LONG)LONG_MAX ) {
		return PyLong_FromLong( (long)ival );
	}
	else if( ival <= (unsigned LONG_LONG)ULONG_MAX ) {
		return PyLong_FromUnsignedLong( (unsigned long)ival );
	}
	else {
             ....

Now, if ival is smaller than -LONG_MAX, it falls outside the long integer range
(being a 64 bit negative integer), but gets handled by the first if-then-case in
above code ('cause it is, of course, smaller than LONG_MAX). This results in
truncation of the 64 bit negative integer to a more or less arbitrary 32 bit
number. The way to fix it is to compare the absolute value of imax against
LONG_MAX in the first condition. The second condition (ULONG_MAX) must, at
least, check wether ival is positive. 




====================================================================
Audit trail:
Mon May 22 17:13:25 2000	guido	changed notes
Mon May 22 17:13:25 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-23 11:20
By: tim_one

Comment:
Reassigned from Trent to me -- Python had the same bug in its "regular int" code for years, and I fixed it there, so I should fix it here too.  'Tis tricky to get right.
-------------------------------------------------------

Date: 2000-Aug-23 15:08
By: tmick

Comment:
Tim, Sorry to have left this siting here. I did not know that it was assigned to me. The code is now:
    if ((LONG_LONG)LONG_MIN <= ival && ival <= (LONG_LONG)LONG_MAX) {
        return PyLong_FromLong( (long)ival );
    }
    else if (0 <= ival && ival <= (unsigned LONG_LONG)ULONG_MAX) {
        return PyLong_FromUnsignedLong( (unsigned long)ival );
    }
    else {

which means that the bug is fixed n'est ce pas? I remember discussing this way back (though "way back" for me is like last week for you).

-------------------------------------------------------

Date: 2000-Aug-23 17:27
By: tim_one

Comment:
What do you mean you didn't know it was assigned to you?  It was assigned to you for an entire 7 minutes before I reassigned it to me <wink>!
So I assigned it back to you.  You're indeed right about the fix -- I had hallucinated this into something deeper than it was.  Better for you to fix it since you can actually test it!  Thanks, Trent.
-------------------------------------------------------

Date: 2000-Aug-31 08:49
By: tmick

Comment:
I am confident that this is fixed I just can't test it because my Win64 box is currently down. I'll leave it open and close it when I get a change to verify (a week or two from now).
-------------------------------------------------------

Date: 2000-Sep-22 21:37
By: tim_one

Comment:
Marked this Fixed since Trent checked in the change weeks ago.  Leaving it for Trent to Close, though.
-------------------------------------------------------

Date: 2000-Oct-05 07:23
By: jhylton

Comment:
I am marking this closed, because Tim said it was fixed weeks ago and Trent seems to have forgotten to close it.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110644&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 15:32:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 07:32:39 -0700
Subject: [Python-bugs-list] [Bug #115912] GC crashes in 2.0b1 and 2.0b2
Message-ID: <200010051432.HAA22156@delerium.i.sourceforge.net>

Bug #115912, was updated on 2000-Oct-03 06:43
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 7
Summary: GC crashes in 2.0b1 and 2.0b2

Details: Forwarded message from Andrew Reutter at Origin:


We are experiencing crashes in both Python 2.0b1 and 2.0b2 that appear to be
related to cyclical garbage collection.
A summary of the scenario follows:

We have embedded Python as a .lib into a much larger project.  We build this
project in both Win32 and Solaris environments.
On Win32 _only_, we use custom memory management routines in order to
facilitate the tracking of memory.
The memory manager also fills memory with specific bit patterns upon both
allocation and deallocation in order to detect the use of uninitialized or
freed memory.

After several minutes of successful execution, we see a reproducible crash
in gc_list_remove.
It receives a node pointer which points to memory filled with our memory
initialization bit pattern (0xCD),
indicating to us that the allocation was successful, but the object was
never fully initialized or placed in a gc_list.
Although this crash occurs at the same point in our code each time, the
address of the node pointer varies with each execution,
making it impossible to set a breakpoint when the node allocation takes
place.

Since we only tweak memory management under Win32, our memory manager is
unlikely to be the culprit.
The crash disappears when Python is compiled without the WITH_CYCLE_GC
definition.

Unfortunately, the project is both extremely large and the source is closed,
so we are unable to send you a quick methodology for reproduction of our
crash.  We would nonetheless like to assist you in solving this problem in
any way we _are_ able, so let us know.
Are there any other reported bugs in gcmodule.c (we noted that some were
fixed when b2 was released)?
Is there any information you could provide us that would help us debug it
ourselves?  An example would be to direct us to the single method by which
all objects are allocated, if such a method exists.



Follow-Ups:

Date: 2000-Oct-03 13:37
By: loewis

Comment:
It might help to find out which C extension modules are used; i.e. printing sys.modules shortly before the crash. Have all extension modules been recompiled with the 2.0bx header files?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115912&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 15:40:19 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 07:40:19 -0700
Subject: [Python-bugs-list] [Bug #110836] configure script fails with cross-compiler (PR#228)
Message-ID: <200010051440.HAA22453@delerium.i.sourceforge.net>

Bug #110836, was updated on 2000-Aug-01 14:14
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 3
Summary: configure script fails with cross-compiler (PR#228)

Details: Jitterbug-Id: 228
Submitted-By: dean@dragonsys.com
Date: Wed,  8 Mar 2000 15:36:00 -0500 (EST)
Version: 1.5.2
OS: Linux


I was trying to build python with a cross-compiler, so I put my cross-compiler
bin directory in the front of my path and executed the configure script. The
fact that a cross-compiler was being used was detected correctly, causing it to
fail later on at line 1922:
    { echo "configure: error: can not run test program while cross compiling"
1>&2; exit 1; }

This is a bug in configure, isn't it?





====================================================================
Audit trail:
Mon Apr 03 18:37:06 2000	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:14
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] configure script fails with cross-compiler (PR#228)
Date: Wed, 08 Mar 2000 22:19:12 -0500

> I was trying to build python with a cross-compiler, so I put my cross-compiler
> bin directory in the front of my path and executed the configure script. The
> fact that a cross-compiler was being used was detected correctly, causing it to
> fail later on at line 1922:
>     { echo "configure: error: can not run test program while cross compiling"
> 1>&2; exit 1; }
> 
> This is a bug in configure, isn't it?

Depends on your point of view.  It's a restriction that the configure
doesn't work with a cross compiler, because there are a bunch of tests
for which it needs to run code to determine the outcome.

If you want to contribute patches to configure.in to supply defaults
(I think there are 6-8 cases) that would be approciated.  See
python.org/patches/.

Cheers,

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110836&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 15:48:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 07:48:50 -0700
Subject: [Python-bugs-list] [Bug #115341] Todays CVS python dumps core in gcmodule.c?!
Message-ID: <200010051448.HAA22820@delerium.i.sourceforge.net>

Bug #115341, was updated on 2000-Sep-26 01:43
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: Todays CVS python dumps core in gcmodule.c?!

Details: While tracing a bug in my own code, I got a core dump from python.
Since it is extremely difficult to find out WHERE in my 58k lines of code this
happens,  I can't just make a small test case. I thought at this stage it might
be useful to report anyway.

no203[204]lehmann%3% gdb =python core        
GNU gdb 19991004
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `/usr/local/nonius/bin/python /usr/local/nonius/app/gui/to
p.py new orient x.non'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdb.so.3...done.
Reading symbols from /lib/libpthread.so.0...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libutil.so.1...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/stropmodule.so.
..done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/timemodule.so..
.done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/_tkinter.so...
done.
---Type <return> to continue, or q <return> to quit---
Reading symbols from /usr/local/nonius/lib/libBLT24.so...done.
Reading symbols from /usr/local/nonius/lib/libtk8.3.so...done.
Reading symbols from /usr/local/nonius/lib/libtcl8.3.so...done.
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/mathmodule.so..
.done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/md5module.so...
done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/multi
array.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/_nump
y.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/umath
.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/structmodule.so
...done.
Reading symbols from /usr/local/nonius/app/misc/linux/_ntoolsmodule.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/_socketmodule.s
o...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/cStringIO.so...
done.
Reading symbols from /lib/libnss_files.so.2...done.
---Type <return> to continue, or q <return> to quit---
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/lapac
k_lite.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/selectmodule.so
...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/gdbmmodule.so..
.done.
Reading symbols from /usr/lib/libgdbm.so.2...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/cPickle.so...
done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/ranli
b.so...done.
#0  update_refs (containers=0x80bfec0) at ./gcmodule.c:150
150                     gc->gc_refs = PyObject_FROM_GC(gc)->ob_refcnt;
(gdb) where
#0  update_refs (containers=0x80bfec0) at ./gcmodule.c:150
#1  0x808ae9b in collect (young=0x80bfec0, old=0x80bfecc) at ./gcmodule.c:382
#2  0x808b0cc in collect_generations () at ./gcmodule.c:488
#3  0x808b10f in _PyGC_Insert (op=0x8703824) at ./gcmodule.c:507
#4  0x807fbe4 in PyTuple_New (size=3) at tupleobject.c:87
#5  0x80561df in eval_code2 (co=0x8260518, globals=0x823fcd4, locals=0x0, 
    args=0x824d258, argcount=2, kws=0x8780190, kwcount=5, defs=0x8268f50, 
    defcount=1, owner=0x82699e4) at ceval.c:1561
#6  0x8057e3b in call_function (func=0x8269a7c, arg=0x87616cc, kw=0x87743ac)
    at ceval.c:2744
#7  0x8057a4b in PyEval_CallObjectWithKeywords (func=0x87816bc, arg=0x87616cc, 
    kw=0x87743ac) at ceval.c:2588
#8  0x806df7b in PyInstance_New (class=0x82699e4, arg=0x87616cc, kw=0x87743ac)
    at classobject.c:463
#9  0x8057b51 in call_builtin (func=0x82699e4, arg=0x87616cc, kw=0x87743ac)
    at ceval.c:2625
#10 0x8057a58 in PyEval_CallObjectWithKeywords (func=0x82699e4, arg=0x87616cc, 
    kw=0x87743ac) at ceval.c:2590
#11 0x8056bab in eval_code2 (co=0x81f0c58, globals=0x8201b1c, locals=0x0, 
    args=0x875cd8c, argcount=2, kws=0x875cd94, kwcount=0, defs=0x8201248, 
    defcount=1, owner=0x81fe94c) at ceval.c:1923
#12 0x805687c in eval_code2 (co=0x81f2de8, globals=0x8201b1c, locals=0x0, 
    args=0x866e2b0, argcount=2, kws=0x866e2b8, kwcount=0, defs=0x0, 
---Type <return> to continue, or q <return> to quit---
    defcount=0, owner=0x8201a4c) at ceval.c:1822
#13 0x805687c in eval_code2 (co=0x81ef9d0, globals=0x8201b1c, locals=0x0, 
    args=0x8203314, argcount=2, kws=0x820331c, kwcount=0, defs=0x8201098, 
    defcount=1, owner=0x81f4e8c) at ceval.c:1822
#14 0x805687c in eval_code2 (co=0x83d1d10, globals=0x83d8044, locals=0x0, 
    args=0x8202840, argcount=2, kws=0x8202848, kwcount=0, defs=0x0, 
    defcount=0, owner=0x85fc974) at ceval.c:1822
#15 0x805687c in eval_code2 (co=0x83cff98, globals=0x83d8044, locals=0x0, 
    args=0x8202068, argcount=1, kws=0x820206c, kwcount=0, defs=0x0, 
    defcount=0, owner=0x85fc974) at ceval.c:1822
#16 0x805687c in eval_code2 (co=0x83af368, globals=0x83b2574, locals=0x0, 
    args=0x86134f0, argcount=2, kws=0x0, kwcount=0, defs=0x83b2120, 
    defcount=1, owner=0x83c8b8c) at ceval.c:1822
#17 0x8057e3b in call_function (func=0x83bcc7c, arg=0x860fcac, kw=0x0)
    at ceval.c:2744
#18 0x8057a4b in PyEval_CallObjectWithKeywords (func=0x8203194, arg=0x860fcac, 
    kw=0x0) at ceval.c:2588
#19 0x806df7b in PyInstance_New (class=0x85fc974, arg=0x860fcac, kw=0x0)
    at classobject.c:463
#20 0x8057b51 in call_builtin (func=0x85fc974, arg=0x860fcac, kw=0x0)
    at ceval.c:2625
#21 0x8057a58 in PyEval_CallObjectWithKeywords (func=0x85fc974, arg=0x860fcac, 
    kw=0x0) at ceval.c:2590
---Type <return> to continue, or q <return> to quit---
#22 0x8056bab in eval_code2 (co=0x8163568, globals=0x80caecc, locals=0x0, 
    args=0x80d562c, argcount=2, kws=0x80d5634, kwcount=0, defs=0x0, 
    defcount=0, owner=0x860e81c) at ceval.c:1923
#23 0x805687c in eval_code2 (co=0x810e8f8, globals=0x80caecc, 
    locals=0x80caecc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
    defcount=0, owner=0x0) at ceval.c:1822
#24 0x80545d7 in PyEval_EvalCode (co=0x810e8f8, globals=0x80caecc, 
    locals=0x80caecc) at ceval.c:319
#25 0x80660b4 in run_node (n=0x80d3cc8, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", globals=0x80caecc, 
    locals=0x80caecc) at pythonrun.c:886
#26 0x8066079 in run_err_node (n=0x80d3cc8, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", globals=0x80caecc, 
    locals=0x80caecc) at pythonrun.c:874
#27 0x8066057 in PyRun_FileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", start=257, 
    globals=0x80caecc, locals=0x80caecc, closeit=1) at pythonrun.c:866
#28 0x8065821 in PyRun_SimpleFileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", closeit=1)
    at pythonrun.c:579
#29 0x80654d0 in PyRun_AnyFileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", closeit=1)
    at pythonrun.c:459
---Type <return> to continue, or q <return> to quit---
#30 0x8051a40 in Py_Main (argc=4, argv=0xbffff814) at main.c:289
#31 0x8051566 in main (argc=5, argv=0xbffff814) at python.c:10
(gdb) 
(gdb) list
145     static void
146     update_refs(PyGC_Head *containers)
147     {
148             PyGC_Head *gc = containers->gc_next;
149             for (; gc != containers; gc=gc->gc_next) {
150                     gc->gc_refs = PyObject_FROM_GC(gc)->ob_refcnt;
151             }
152     }
153
154     static int
(gdb) print gc
$1 = (PyGC_Head *) 0x0


Follow-Ups:

Date: 2000-Sep-26 04:31
By: gvanrossum

Comment:
Neil, can you have a look at this?
-------------------------------------------------------

Date: 2000-Sep-26 09:44
By: nascheme

Comment:
Since I can't reproduce this bug here are some things to 
try:

- compile Python with Py_DEBUG defined
- compile Python with Py_DEBUG and without GC
- at the start of your application call
  gc.set_debug(gc.DEBUG_LEAK) and gc.set_threshold(1)
- at the start of your application disable GC with gc.disable()
- recompile your extension modules
-------------------------------------------------------

Date: 2000-Sep-26 09:45
By: nascheme

Comment:
Since I can't reproduce this bug here are some things to 
try:

- compile Python with Py_DEBUG defined
- compile Python with Py_DEBUG and without GC
- at the start of your application call
  gc.set_debug(gc.DEBUG_LEAK) and gc.set_threshold(1)
- at the start of your application disable GC with gc.disable()
- recompile your extension modules
- checkout Python from a few days ago (cvs -D option)
-------------------------------------------------------

Date: 2000-Sep-29 01:39
By: hooft

Comment:
Sorry that I have not been able to react quicker. Unfortunately I won't be here in the weekend either.

- Py_Debug didn't change anything, it still dumped core.
- set_debug and set_threshold(1) : it still dumps core.

#0  update_refs (containers=0x80be6f8) at ./gcmodule.c:150
150                     gc->gc_refs = PyObject_FROM_GC(gc)->ob_refcnt;
(gdb) where
#0  update_refs (containers=0x80be6f8) at ./gcmodule.c:150
#1  0x8079db3 in collect (young=0x80be6f8, old=0x80be6f8) at ./gcmodule.c:382
#2  0x8079f57 in collect_generations () at ./gcmodule.c:471
#3  0x807a044 in _PyGC_Insert (op=0x87b1c14) at ./gcmodule.c:507
#4  0x80589cb in PyTuple_New (size=3) at tupleobject.c:87

(gdb) print containers
$50 = (PyGC_Head *) 0x80be6f8
(gdb) print gc
$51 = (PyGC_Head *) 0x0

I checked the first 50 or so references, no NULL encountered yet.

- gc.disable makes it continue, but I get all kinds of weird trouble
   with Tk:
Error: 3
AttributeError Exception in Tk callback
  Function: <function <lambda> at 0x87cb8e4> (type: <type 'function'>)
  Args: ('3652', '1', '1', '0', '1', '0', '-449121110', '0', '102', '0', '??', '0', '??', '0', '.138093276.141021828.141028308.142397076.142399772.142400300.142414228', '7', '544', '454', '1')
Traceback (innermost last):
  File "/usr/local/nonius/lib/python2.0/site-packages/Pmw/Pmw_0_8_4/lib/PmwBase.py", line 1668, in __call__
    args = apply(self.subst, args)
  File "/usr/local/nonius/lib/python2.0/lib-tk/Tkinter.py", line 1048, in _substitute
    e.widget = self._nametowidget(W)
  File "/usr/local/nonius/lib/python2.0/lib-tk/Tkinter.py", line 973, in nametowidget
    w = w._root()
  File "/usr/local/nonius/lib/python2.0/lib-tk/Tkinter.py", line 1012, in _root
    while w.master: w = w.master
AttributeError: 'Frame' instance has no attribute 'master'

And when the program terminates:
  [73562 refs]
  Print left references? [ny] n
  zsh: segmentation fault (core dumped)  collect new orient
  collect new orient  6.18s user 0.33s system 2% cpu 4:06.65 total

(gdb) where
#0  0x400e7129 in chunk_free (ar_ptr=0x4017bd60, p=0x87ce2f8) at malloc.c:3111
#1  0x400e6fba in __libc_free (mem=0x87ce300) at malloc.c:3023
#2  0x805941e in PyTuple_Fini () at tupleobject.c:562
#3  0x80762b6 in Py_Finalize () at pythonrun.c:243
#4  0x80777f4 in Py_Exit (sts=0) at pythonrun.c:1120
#5  0x8076d5e in PyErr_PrintEx (set_sys_last_vars=1) at pythonrun.c:708
#6  0x8076c6a in PyErr_Print () at pythonrun.c:671
#7  0x80769c1 in PyRun_SimpleFileEx (fp=0x80ce428, filename=0xbffff9a3 "/usr/local/nonius/app/gui/top.py", closeit=1) at pythonrun.c:582
#8  0x8076610 in PyRun_AnyFileEx (fp=0x80ce428, filename=0xbffff9a3 "/usr/local/nonius/app/gui/top.py", closeit=1) at pythonrun.c:459
#9  0x8051c40 in Py_Main (argc=3, argv=0xbffff834) at main.c:289
#10 0x8051756 in main (argc=4, argv=0xbffff834) at python.c:10

- to be able to enable Py_DEBUG I had to recompile all extension modules, so that point I skipped.
- I don't think "cvs -D" will be very useful, it is just the first time I'm seeing
   this here, but it might have been present already for a long time.

I am at a loss. I really have no clue how to reduce the program while maintaining the problem to make a simple test case. I can't even trace where my program is failing?!?!?
-------------------------------------------------------

Date: 2000-Oct-03 13:41
By: loewis

Comment:
I notice a module _ntoolsmodule.so is used. Has this module been recompiled with the current header files? Is source code of this module available for review?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115341&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 15:51:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 07:51:56 -0700
Subject: [Python-bugs-list] [Bug #115919] Integer multiplication overflow
Message-ID: <200010051451.HAA22904@delerium.i.sourceforge.net>

Bug #115919, was updated on 2000-Oct-03 08:01
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 6
Summary: Integer multiplication overflow

Details: roland@cachemir ~ $ python2.0 
Python 2.0b2 (#3, Oct  3 2000, 16:30:25) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> 1+1
2
>>> 1*1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>> 

Last CVS update 2000-10-03 around 14:00 UTC.  Last before that was some weeks ago, sorry for not being precise.  Compiled with ./configure --prefix=/usr/local/ && make, su and make install.  Only personal change is the use of readline in Modules/Setup.local.  Did I do something wrong?

Follow-Ups:

Date: 2000-Oct-03 08:25
By: jhylton

Comment:
What happens when you run "make test"?  It looks like there is something fundamentally broken, but I can't tell what it is.  If 1*1 fails, I expect the rest of the test suite to also report errors.


-------------------------------------------------------

Date: 2000-Oct-03 08:38
By: lo-lan-do

Comment:
make test shows me plenty of lines looking like this one (except the name of the test changes):

test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication

I also get messages along the lines of 'test test_dbm skipped --  No module named dbm', but I guess these ones are OK.
-------------------------------------------------------

Date: 2000-Oct-03 08:40
By: jhylton

Comment:
Can you include the complete output?

-------------------------------------------------------

Date: 2000-Oct-03 09:02
By: lo-lan-do

Comment:
[In case the bug would be caused by a recent upgrade to a beta glibc, I tried the '1*1' test with Python 1.5.2.  No bug visible there.]

$ make distclean && ./configure --prefix=/usr/local/ && make
$ make test &> test.log

It seems that 'make test' somehow hangs when testing threads, so I cut at that point.  I hope the relevant info is shown before that point.
Here goes...

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Unhandled exception in thread:
test_grammar
test test_grammar crashed -- exceptions.OverflowError: integer multiplication
test_opcodes
test_operations
test_builtin
test test_builtin crashed -- exceptions.OverflowError: integer multiplication
test_exceptions
test_types
test test_types crashed -- exceptions.OverflowError: integer multiplication
test_MimeWriter
test_StringIO
test_al
test test_al skipped --  No module named al
test_array
test test_array crashed -- exceptions.OverflowError: integer multiplication
test_atexit
test_audioop
test test_audioop skipped --  No module named audioop
test_augassign
test test_augassign crashed -- exceptions.OverflowError: integer multiplication
test_binascii
test_binhex
test test_binhex crashed -- exceptions.OverflowError: integer multiplication
test_bsddb
test_cd
test test_cd skipped --  No module named cd
test_cfgparser
test test_cfgparser crashed -- exceptions.OverflowError: integer multiplication
test_cgi
test test_cgi crashed -- exceptions.OverflowError: integer multiplication
test_cl
test test_cl skipped --  No module named cl
test_class
test_cmath
test_compile
test_contains
test_cookie
test test_cookie crashed -- exceptions.OverflowError: integer multiplication
test_cpickle
test_crypt
test test_crypt skipped --  No module named crypt
test_dbm
test test_dbm skipped --  No module named dbm
test_dl
test test_dl skipped --  No module named dl
test_dospath
test_errno
test_extcall
test_fcntl
test_file
test_fork1
test_format
test_gc
test_gdbm
test test_gdbm skipped --  No module named gdbm
test_getopt
test_gettext
test test_gettext crashed -- exceptions.OverflowError: integer multiplication
test_gl
test test_gl skipped --  No module named gl
test_grp
test_gzip
test test_gzip skipped --  No module named zlib
test_hash
test_imageop
test test_imageop skipped --  No module named imageop
test_imgfile
test test_imgfile skipped --  No module named imgfile
test_largefile
test test_largefile skipped --  platform does not have largefile support
test_linuxaudiodev
test test_linuxaudiodev skipped --  No module named linuxaudiodev
test_long
test test_long crashed -- exceptions.OverflowError: integer multiplication
test_longexp
test_math
test_md5
test_mimetools
test test_mimetools crashed -- exceptions.AttributeError: encode
test_minidom
test test_minidom skipped --  No module named pyexpat
test_mmap
test test_mmap crashed -- exceptions.OverflowError: integer multiplication
test_new
test_nis
test test_nis skipped --  No module named nis
test_ntpath
test_openpty
test_operator
test test_operator failed -- Writing: 'mul(5, 2) = <class exceptions.OverflowError at 0x818f41c>: 10 expected', expected: 'testing:
 neg\012testing: or_\012testing: pos\012testing: repeat\012testing: rshift'
test_parser
test_pickle
test_pkg
test_poll
test test_poll crashed -- exceptions.OverflowError: integer multiplication
test_popen2
test_posixpath
test_pow
test test_pow crashed -- exceptions.OverflowError: integer multiplication
test_pty
test test_pty skipped --  No module named termios
test_pwd
test_pyexpat
test test_pyexpat skipped --  cannot import name expat
test_re
test test_re crashed -- exceptions.OverflowError: integer multiplication
test_regex
test_rfc822
test test_rfc822 crashed -- exceptions.OverflowError: integer multiplication
test_rgbimg
test test_rgbimg skipped --  No module named rgbimg
test_rotor
test_sax
test test_sax skipped --  cannot import name expat
test_select
test_sha
test_signal
test_socket
test_sre
test test_sre failed -- Writing: "sre.match(r'(a)|(b)', 'b').start(1)", expected: ''
test_strftime
test test_strftime crashed -- exceptions.OverflowError: integer multiplication
test_string
test_strop
test_struct
test test_struct crashed -- exceptions.OverflowError: integer multiplication
test_sunaudiodev
test test_sunaudiodev skipped --  No module named sunaudiodev
test_thread
Traceback (most recent call last):
  File "./Lib/test/test_thread.py", line 21, in task
    delay = random.random() * numtasks
  File "/home/roland/perso/src/sourceforge/python/dist/src/Lib/whrandom.py", line 71, in random
    x = (171 * x) % 30269
OverflowError: integer multiplication

-------------------------------------------------------

Date: 2000-Oct-03 09:03
By: jhylton

Comment:
Two more questions:
1) What platform?  Is this a 64-bit machine?  A regular x86?
2) Could you run this under gdb and report where exactly the error is being generated?  The exception is raised in Objects/intobject.c.  I would set a breakpoint at the top of int_mul() and step through the function.


-------------------------------------------------------

Date: 2000-Oct-03 09:32
By: lo-lan-do

Comment:
1) Regular i686 (sez uname).
2) It seems that ah and bh are 1 and not 0 like they should.
A bit of printf-debugging shows me that LONG_BIT/2 is 32,
so somehow 1 >> 32 != 0, which seems most strange and
bizarre to me.  On the other hand, gcc tells me the following
when I compile:

intobject.c: In function `int_mul':
intobject.c:327: warning: right shift count >= width of type

I hope he [gcc] still does the rshift, but I'm no gcc guru.
Hope this helps...
-------------------------------------------------------

Date: 2000-Oct-03 10:01
By: jhylton

Comment:
This does help.  The compiler warning is a bad sign.  I notice that you're using a more recent version of gcc than I have installed.  I'll try building with a newer gcc, but in the interim it may help if you compile the following test program:

#include <stdio.h>
#include <ctype.h>

#ifndef CHAR_BIT
#define CHAR_BIT 8
#endif

#ifndef LONG_BIT
#define LONG_BIT (CHAR_BIT * sizeof(long))
#endif

int main()
{
    int a, b;
    a = 1;
    b = a;
    a = a >> (LONG_BIT / 2);
    printf("CHAR_BIT = %d, LONG_BIT = %d\n", CHAR_BIT, LONG_BIT);
    printf("%d >> %d == %d\n", b, LONG_BIT/2, a);
    return 0;
}

On my system it compiles without warning using gcc -Wall and produces the following output:

CHAR_BIT = 8, LONG_BIT = 32
1 >> 16 == 0

What output do you get?  What is sizeof(long) on your platform?  Does ctype.h define CHAR_BIT or LONG_BIT?

-------------------------------------------------------

Date: 2000-Oct-03 10:23
By: lo-lan-do

Comment:
Your test program compiles without warning and
gives the same results as yours here.
sizeof(long) is 4, limits.h defines CHAR_BIT to be 8.
LONG_BIT is defined in bits/xopen_lim.h to be 32.
-------------------------------------------------------

Date: 2000-Oct-03 10:30
By: lo-lan-do

Comment:
Now if I replace LONG_BIT/2 by LONG_BIT in your test program:
roland@cachemir /tmp $ gcc -Wall test.c && ./a.out 
test.c: In function `main':
test.c:20: warning: right shift count >= width of type
CHAR_BIT = 8, LONG_BIT = 32
1 >> 32 == 1
roland@cachemir /tmp $ 

So I guess it's really something to do with gcc.  Drat.
-------------------------------------------------------

Date: 2000-Oct-03 11:19
By: jhylton

Comment:
I'll see if I can reproduce the problem with GCC 2.95.2

-------------------------------------------------------

Date: 2000-Oct-03 14:26
By: jhylton

Comment:
I can't reproduce this on my system with gcc-2.95.2

I'm puzzled by your last comment about replacing LONG_BIT/2 with LONG_BIT and getting the warning.  I really don't understand why the code is generating a warning at compile time.

line 327 of Object/intobject.c is this right:
	ah = a >> (LONG_BIT/2);
And on your platform LONG_BIT == 32?  And it generates the warning?
Can you print the value of LONG_BIT/2 at just the time it is used in int_mul?

-------------------------------------------------------

Date: 2000-Oct-03 15:46
By: loewis

Comment:
Instead of printing the value of LONG_BIT, I recommend to compile intobject with --save-temps. When invoking make, catch the line that compiles intobject.c, copy it and add --save-temps. Then report the fragment of intobject.i that corresponds to int_mul.

Please also report the exact version of glibc you are using. 2.1.93 sometimes gets the order of includes wrong, so that LONG_BIT ends up being defined as 64.
-------------------------------------------------------

Date: 2000-Oct-04 01:46
By: lo-lan-do

Comment:
You're [Martin v. Löwis] probably right about the libc stuff.
I'm using 2.1.94 (as installed by the Debian unstable
distribution).  After inserting

printf ("ah: %d, LONG_BIT: %d, LONG_BIT/2: %d\n", ah, LONG_BIT, LONG_BIT/2);

I can clearly see that LONG_BIT is 64.  The appropriate
intobject.i section reads:

int_mul(PyIntObject *v, PyIntObject *w)
{
        long a, b, ah, bh, x, y;
        int s = 1;

        a = v->ob_ival;
        b = w->ob_ival;
        ah = a >> (64 /2);
        bh = b >> (64 /2);
        printf ("ah: %d, LONG_BIT: %d, LONG_BIT/2: %d\n", ah, 64 , 64 /2);

Does this give enough confirmation for me
to submit a Debian bug on the libc6 package?
-------------------------------------------------------

Date: 2000-Oct-04 08:34
By: lo-lan-do

Comment:
After a bit of investigation (thanks to the Debian maintainer
of libc6) it appears that #define'ing _GNU_SOURCE causes
some include file or other to do Not The Right Thing.  Namely,
#define'ing LONG_BIT to 64 while LONG_MAX is correct
(0x7FFFFFFFL).

I'll continue investigating (though maybe not as intensively, I'm
getting a bit flummoxed...)
-------------------------------------------------------

Date: 2000-Oct-04 18:55
By: tim_one

Comment:
Note that I just checked in changes to intobject.c and pyport.h to do a compile-time #error if LONG_BIT appears to be insanely defined by the platform.
-------------------------------------------------------

Date: 2000-Oct-05 01:24
By: lo-lan-do

Comment:
True.  And I confirm that this breaks compilation
on my system :-)

I'll try to get in touch with the Debian libc
maintainer to see if that's Debian-specific or
not.  I trust him to forward the bug report upstream
if need be.  Stay tuned.
-------------------------------------------------------

Date: 2000-Oct-05 07:51
By: jhylton

Comment:
The fix is to raise an error at compile time if LONG_BITS is assigned an unreasonable value by the compiler/C library headers.

This is fix in revision 2.21 of Include/pyport.h and rev 2.51 of Object/intobject.h


-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115919&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 15:52:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 07:52:05 -0700
Subject: [Python-bugs-list] [Bug #115221] test_poll hangs on Debian Linux 2.2
Message-ID: <200010051452.HAA22907@delerium.i.sourceforge.net>

Bug #115221, was updated on 2000-Sep-24 07:38
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: test_poll hangs on Debian Linux 2.2

Details: When run from the command-line test_poll.py prints
"This is a test." 12 times and then hangs, without ever printing "Poll test 1 complete".

All other tests seem to work just fine.

Follow-Ups:

Date: 2000-Sep-27 10:58
By: nascheme

Comment:
I can't reproduce this on my Debian 2.2 system running Linux
 2.2.16.  Can you give the output from "uname -a" and "dpkg 
-l libc6"?  I am using libc6 2.1.3-13.
-------------------------------------------------------

Date: 2000-Oct-05 07:17
By: jhylton

Comment:
Andrew -- Is this still a problem for you?  
-------------------------------------------------------

Date: 2000-Oct-05 07:52
By: akuchling

Comment:
I don't have a Debian system to reproduce this on.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115221&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 15:53:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 07:53:45 -0700
Subject: [Python-bugs-list] [Bug #115844] OverflowError: integer multiplication
Message-ID: <200010051453.HAA23044@delerium.i.sourceforge.net>

Bug #115844, was updated on 2000-Oct-02 06:27
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 6
Summary: OverflowError: integer multiplication

Details: 
Python2.0b2 compiled from source on a full RH7.0 install:


Python 2.0b2 (#2, Sep 27 2000, 11:40:58) 
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> a = 5 * 5
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>>

Follow-Ups:

Date: 2000-Oct-02 06:39
By: gvanrossum

Comment:
Something very basic is wrong. What output does the test suite give? ("make test"). Please see the README for digging into this.

Note that you submitted your bug report anonymously. We can't help you very effectively unless we can exchange email with you!
-------------------------------------------------------

Date: 2000-Oct-03 08:27
By: jhylton

Comment:
Strange! Another bug about integer multiplication overflow.  The other one is on a Debian install.

-------------------------------------------------------

Date: 2000-Oct-03 10:21
By: gvanrossum

Comment:
Could it be a 64-bit bug? Otherwise I suspect a GCC bug, or a 64-bit GCC bug. Note that GCC 2.96 is bleeding edge!
-------------------------------------------------------

Date: 2000-Oct-03 10:30
By: fdrake

Comment:
I don't see any reference to GCC 2.96 on the GCC website (http://gcc.gnu.org/).  PythonLabs should be a RH7.0 box to perform testing.

This may be a duplicate of #1159191.
-------------------------------------------------------

Date: 2000-Oct-03 11:17
By: jhylton

Comment:
This bug has also been reported on a system using gcc2.95, so I'm going try with that version of GCC.  It doesn't sound like this is a 64-bit platform; does RH7 run on a 64-bit platform?  It does appear that the problem is caused by LONG_BIT being too big resulting in a bogus shift.

-------------------------------------------------------

Date: 2000-Oct-04 18:59
By: tim_one

Comment:
Note that I just checked in changes to intobject.c and pyport.h to do a compile-time #error if LONG_BIT appears to be insanely defined by the platform.
-------------------------------------------------------

Date: 2000-Oct-05 07:53
By: jhylton

Comment:
same fix as other integer multiplication bug; report error at compile-time if compiler has bogus definition of LONG_BITS

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115844&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 15:54:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 07:54:29 -0700
Subject: [Python-bugs-list] [Bug #116136] reindent hits sre recursion limit in tokenize
Message-ID: <200010051454.HAA31063@bush.i.sourceforge.net>

Bug #116136, was updated on 2000-Oct-05 07:21
Here is a current snapshot of the bug.

Project: Python
Category: demos and tools
Status: Open
Resolution: None
Bug Group: None
Priority: 1
Summary: reindent hits sre recursion limit in tokenize

Details: While running Tim Peters' new reindent script over my code,
I received the following traceback:

checking ./dtcout.py ...
Traceback (most recent call last):
  File "/usr/local/bin/reindent", line 258, in ?
    main()
  File "/usr/local/bin/reindent", line 65, in main
    check(arg)
  File "/usr/local/bin/reindent", line 77, in check
    check(fullname)
  File "/usr/local/bin/reindent", line 90, in check
    if r.run():
  File "/usr/local/bin/reindent", line 135, in run
    tokenize.tokenize(self.getline, self.tokeneater)
  File "/usr/local/lib/python2.0/tokenize.py", line 152, in tokenize
    pseudomatch = pseudoprog.match(line, pos)
RuntimeError: maximum recursion limit exceeded

The pattern compiled into pseudoprog is

[ \f\t]*((\\\r?\n|#[^\r\n]*|([rR]?'''|[rR]?"""))|((0[jJ]|[1-9]\d*[jJ]|((\d+\.\d*|\.\d+)([eE][-+]?\d+)?|[1-9]\d*[eE][-+]?\d+)[jJ])|((\d+\.\d*|\.\d+)([eE][-+]?\d+)?|[1-9]\d*[eE][-+]?\d+)|(0[xX][\da-fA-F]*[lL]?|0[0-7]*[lL]?|[1-9]\d*[lL]?))|((\+=|\-=|\*=|%=|/=|\*\*=|&=|\|=|\^=|>>=|<<=|\+|\-|\*\*|\*|\^|~|/|%|&|\||<<|>>|==|<=|<>|!=|>=|=|<|>)|[][(){}]|(\r?\n|[:;.,`]))|([rR]?'(\\.|[^\n'\\])*('|\\\r?\n)|[rR]?"(\\.|[^\n"\\])*("|\\\r?\n))|[a-zA-Z_]\w*)

I am not even going to try to figure out what part of the re triggers the excessive recursion.  Here is the source file reindent was munching on when the exception was raised.  Hopefully the bug submission process won't destroy it.  If so, let me know (skip@mojam.com) and I'll send it to you.

def dtmlfunc(**__d):
    import sys, urllib, string
    output = []
    append = output.append
    append('<!-- Generated: Wed Mar 10 12:13:08 1999 -->')
    append('\012<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> <!-- -*-html-helper -*- -->\012<HTML>\012<HEAD>\012<TITLE>Musi-Cal Search: ')
    append("""%s""" % __d['search_key'])
    append('</TITLE>\012<LINK REV="made" HREF="mailto:concertmaster@musi-cal.com">\012</HEAD>\012<BODY bgcolor="#ffffff" text="#000000" link="#CC0000" alink="#FF3300" vlink="#330099"\012>\012\012')
    append("""%s""" % __d['banner'])
    append('\012\012<H2 align="center">Musi-Cal Search Response</H2>\012\012')
    if __d['repeat_msg']:
        append('\012  ')
        append("""%s""" % __d['repeat_msg'])
        append('\012  <hr>\012')
    append('\012\012')
    if __d['entries']:
        append('\012\012    ')
        if __d['indirect']:
            append('\012      <P>\012      You can invoke this search using the following URL.\012      Why not save it for future reference?\012      <p align=center><code>http://')
            append("""%s""" % __d['servername'])
            append('/cgi-bin/event-search?')
            append("""%s""" % __d['query_string'])
            append('</code></p>\012    ')
        append('\012    \012    <p>\012    Click <img src="http://www.musi-cal.com/icons/vdb10.gif" alt="[VDB]"> to look up venue information.<br>\012    ')
        if __d['next']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['next'])
            append('">[Next Page]</a>\012    </font>\012    ')
        append('\012    ')
        if __d['prev']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['prev'])
            append('">[Previous Page]</a><br>\012    </font>\012    ')
        else:
            append('\012      ')
            if __d['next']:
                append('<br>')
            append('\012    ')
        append('\012\012    <TABLE border=0 cellspacing="5" cellpadding="0" width="100%">\012\012    ')
        __i_entries = -1
        for __elt_entries in __d['entries']:
            __i_entries = __i_entries + 1
            append('\012\012\011<tr valign=middle>\012\012\011')
            if __d['editor']:
                append('\012\011  <TD><A href="http://')
                append("""%s""" % __d['servername'])
                append('/cgi-bin/edit-entry?editor=')
                try: append(urllib.quote(__d['editor']))
                except: append(__d['editor'].urllib.quote())
                append('&key=')
                append("""%s""" % __elt_entries['key'])
                append('">[Edit]</A><BR><A href="http://')
                append("""%s""" % __d['servername'])
                append('/cgi-bin/edit-entry?editor=')
                try: append(urllib.quote(__d['editor']))
                except: append(__d['editor'].urllib.quote())
                append('&key=')
                append("""%s""" % __elt_entries['key'])
                append('&zap=1">[Delete]</A>\012\011  <br><font size="-1">Submitter: ')
                try: append(get_email(__elt_entries))
                except: append(__elt_entries.get_email())
                append('</font>\012\011')
            else:
                append('\012\011  ')
                if __d['show_vcal']:
                    append('<TD><A href="http://')
                    append("""%s""" % __d['servername'])
                    append('/cgi-bin/gencal?type=vCalendar&key=')
                    append("""%s""" % __elt_entries['key'])
                    append('"><IMG SRC="/images/vcal.gif" ALIGN="top" ALT="vCal" width="16" height="16" border="0"></A>')
                append('\012\011')
            append('\012\012    ')
            try: append(html(__elt_entries))
            except: append(__elt_entries.html())
            append('\012\012    ')
            if (__i_entries == 0):
                append('\012\011')
                if __d['display_static']:
                    append('\012\011<td width="25%" valign=top rowspan=')
                    append("""%s""" % len(__d['entries']))
                    append('>\012\011    ')
                    if __d['static_info']:
                        append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><font size="+1"><a name="staticinfo">Notes Index</a></font></th></tr>\012\011\011  </table>\012\012\011\011')
                        if __d['stperformers']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stperf">Performers</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stperformers'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stcontributors']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th>Contributors</th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stcontributors'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stvenues']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stven">Venues</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stvenues'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stevents']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stev">Events</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stevents'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stcities']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stcity">Cities</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stcities'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011<font size="-1">You can <strong><a\012\011\011href="http://www.musi-cal.com/addstatic.shtml">add</a></strong> or\012\011\011<strong><a href="http://www.musi-cal.com/editstatic.shtml">edit</a></strong>\012\011\011Notes Index items too!</font>\012\012\011    ')
                    append('\012\011    <p>\012\011    <a href="http://www.musi-cal.com/cgi-bin/redirect/http%3a//www.amazon.com/exec/obidos/redirect-home/musical">\012\011    <img src="http://www.musi-cal.com/icons/amzn-assoc.gif" border="0" alt="In Association with Amazon.com"></a> \012\011</td>\012\011')
                append('\012    ')
            append('\012\012    ')
        append('\012\012    </TABLE>\012\012    ')
        if __d['next']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['next'])
            append('">[Next Page]</a>\012    </font>\012    ')
        append('\012    ')
        if __d['prev']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['prev'])
            append('">[Previous Page]</a><br>\012    </font>\012    ')
        else:
            append('\012      ')
            if __d['next']:
                append('<br>')
            append('\012    ')
        append('\012\012    <P>Check with venues before making plans to attend listed events.\012\012    <P>If you notice any errors, <A\012    href="mailto:concertmaster@musi-cal.com">please let us know</A> so we can\012    correct them.\012\012')
    else:
        append('\012\012    ')
        if __d['searchbyperformer']:
            append('\012      <p>We were not able to find any matches to your search.  It\'s possible\012      the artist you were searching for is not on tour or that we don\'t\012      currently have their dates in our database. You might also try <a\012      href="http://')
            append("""%s""" % __d['servername'])
            append('/cgi-bin/list-perf">browsing by performer</a>\012      in case you\'ve misspelled their name.\012      If you know of a possible source for their concert schedule,\012      <a href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\012      ')
            if __d['stperformers']:
                append('\012\011<table width="100%" cellpadding=2>\012\011<tr><th><a name="stperf">Performers</a></th></tr>\012\011<tr><td textcolor="black" bgcolor="white">\012\011  <font size="-1">\012\011  ')
                append("""%s""" % __d['stperformers'])
                append('\012\011  </font>\012\011  </td></tr>\012\011</table>\012     ')
            append('\012\012   ')
        else:
            append('\012      ')
            if __d['searchbyvenue']:
                append('\012\011<p>We were not able to find any matches to your search.  Venue\012\011names can often spelled several different ways.  You might try\012\011searching for just a single word in the venue\'s name, such as\012\011<strong>Passim</strong> instead of <strong>Club Passim</strong>.\012\011Also, some venues, such as church-sponsored coffeehouses, may\012\011be listed either under the name of the coffeehouse or the name\012\011of the hosting venue.\012\011We may also not have their schedule in our database.\012\011If you know of a possible source for their concert schedule,\012\011<a href="mailto:concertmaster@musi-cal.com">let us know</a>.\012      ')
            else:
                append('\012\011')
                if __d['searchbyevent']:
                    append('\012\011  <p>We were not able to find any matches to your search.\012\011  If you know of a possible source for event schedules,\012\011  <a href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\011')
                else:
                    append('\012\011  ')
                    if __d['searchbylocation']:
                        append('\012      <p>We were not able to find any matches to your search.\012      Please check that the city, state and country names are\012      spelled or abbreviated properly.  You might also try <a\012      href="http://')
                        append("""%s""" % __d['servername'])
                        append('/index-geog.shtml">browsing by location</a>\012      in case you misspelled the name. If you know of a\012      possible source of concert schedules for this region, <a\012      href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\011  ')
                    else:
                        append('\012      <p>We were not able to find any matches to your search.\012      If you know of a possible source of concert schedules\012      that would fill a hole in our database, <a\012      href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\011  ')
                    append('\012\011')
                append('\012      ')
            append('\012    ')
        append('\012\012')
    append('\012\012<P ALIGN="center"><CENTER>\012<p>\012<FORM METHOD="GET" ACTION="http://')
    append("""%s""" % __d['servername'])
    append('/cgi-bin/simple-search">\012<input type=radio name="key" value="performer">performer\012<input type=radio checked name="key" value="city">city\012<input type=radio name="key" value="venue">venue\012<input type=radio name="key" value="event">event<br>\012Search for: <INPUT TYPE="text" NAME="value">\012<input type="submit" value="OK">\012<br>')
    append("""%s""" % __d['survey'])
    append('\012</FORM></CENTER>\012\012\012<p align=center>\012<strong><font size="-1"><a href="/index-contribute.shtml"\012onMouseOver="window.status=\'Add events or Notes Index entries to the database\'; return true">Contribute</a> | <a href="/index-search.shtml"\012onMouseOver="window.status=\'Search the database in several ways\'; return true">Search</a> | <a href="/index-sponsor.shtml"\012onMouseOver="window.status=\'Advertise in Musi-Cal!\'; return true">Advertise</a> | <a href="/index-contents.shtml"\012onMouseOver="window.status=\'Let your mousey to the walking...\';return true">Contents</a> | <a href="/index-learn.shtml"\012onMouseOver="window.status=\'Stuck? Get help here...\'; return true">Help</a> | <a href="/Faq.shtml"\012onMouseOver="window.status=\'You got questions? We got answers...\'; return true">FAQ</a></font></strong>\012\012\012<p align=center>\012<A HREF="http://www.musi-cal.com/"><IMG border=0 WIDTH=23 HEIGHT=33 SRC="http://www.musi-cal.com/icons/not!
e.gif" ALT="[Musi-Cal Home Page]"></A>\012\012<font size="-1"><a href="mailto:concertmaster@musi-cal.com">Contact Us!</a><br><em>Copyright &#169; 1994-1999, Automatrix, Inc.</em>\012</font>\012\012\012\012</BODY>\012</HTML>\012')
    return string.join(output, '')


Follow-Ups:

Date: 2000-Oct-05 07:54
By: gvanrossum

Comment:
After 2.0 final is released.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116136&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 16:23:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 08:23:03 -0700
Subject: [Python-bugs-list] [Bug #115119] re module docs missing lookbehind, etc.
Message-ID: <200010051523.IAA24305@delerium.i.sourceforge.net>

Bug #115119, was updated on 2000-Sep-22 11:12
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: None
Bug Group: None
Priority: 5
Summary: re module docs missing lookbehind, etc.

Details: Perhap this is not a bug, but the re module documentation does not describe some PCRE2 features that sre incorporates. Note that these did not make it into pre, and so are not necessary for pre compatibility, but maybe should be documented as sre features.

Here follows a text description from a message by AMK that accompanied a pyPCRE snapshot:

[I've lost the reference to the original and had to retype what follows.]

========
New features in PCRE2 compared to PCRE1 are:

\z    Matches only at the end of the string. This differs from the existing \Z, which will match at the end of the string, or before a final newline at the end of the string.

(?<=...)    Positive lookbehind assertion. Matches if the current position in the string is preceded by a match for the contained regex

(?<!...)    Negative lookbehind assertion. Matches if the current position in the string is not preceded by a match for the contained regex

========

FYI, two other PCRE2 features that AMK described don't seem to have make it into sre: "once-only subpatterns" and "conditional subpatterns".



Follow-Ups:

Date: 2000-Sep-22 11:14
By: gvanrossum

Comment:
For Fred to negotiate with Fredrik.
-------------------------------------------------------

Date: 2000-Sep-22 11:21
By: jdnier

Comment:
Actually, '\z' is supported by pre, so at least that should be added to the docs.
-------------------------------------------------------

Date: 2000-Sep-28 06:01
By: fdrake

Comment:
Andrew, you're more in the know than I on this topic -- if I can get some text from you, I can mark it up.  Thanks!
-------------------------------------------------------

Date: 2000-Sep-28 14:50
By: akuchling

Comment:
Looking at the SRE code, it doesn't seem like it supports \z.  Lookbehinds do seem to be implemented, though; I'll work on producing some text for this.

-------------------------------------------------------

Date: 2000-Oct-05 08:22
By: akuchling

Comment:
Text written and checked in to lib/libre.tex

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115119&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 16:28:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 08:28:06 -0700
Subject: [Python-bugs-list] [Bug #115392] Build under SunOS 4.1.4_JL fails
Message-ID: <200010051528.IAA32444@bush.i.sourceforge.net>

Bug #115392, was updated on 2000-Sep-26 12:13
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: Wont Fix
Bug Group: Platform-specific
Priority: 6
Summary: Build under SunOS 4.1.4_JL fails

Details: The linkage of the python executable fails under SunOS 4.1.4_JL since
LDFLAGS in Modules/Makefile is defined as:

  LDFLAGS = -L

That is, no value of the -L option is specified.  This definition seems
to be generated by the configure script.  The same problem raises even
though a explicit definition of LDFLAGS is given when the configure
script is invoked, as shown below:

  $ env LDFLAGS='' ./configure

(In fact, no -L options are needed for my configuration, so the linkage
is successfully done by running make LDFLAGS='').

Follow-Ups:

Date: 2000-Sep-26 12:18
By: kajiyama

Comment:
I forgot to give the version: 2.0b1, of course :-)
-------------------------------------------------------

Date: 2000-Sep-26 12:38
By: fdrake

Comment:
Assigned to Barry since he's the GNUish guy, and he should know enough autoconf to fix this.
-------------------------------------------------------

Date: 2000-Sep-27 10:09
By: loewis

Comment:
The bug is caused by the configure.in fragment

    if test -d "$with_threads"
    then LDFLAGS="$LDFLAGS -L$with_threads"
    fi

with_threads is empty, yet the test whether it is a directory(!) succeeds.

It appears that 'test -d' must be replaced with 'test -n' in many places in configure.in; bumped priority so this gets attention.
-------------------------------------------------------

Date: 2000-Oct-05 08:28
By: bwarsaw

Comment:
Should we worry about this?  I've tested -d "" with the Bourne shell on Linux, FreeBSD, and Solaris 2.6, and all return false as expected.  If SunOS 4.1.4_JL is anything like SunOS 4 in the US, it is ancient!  I personally don't think it's worth expending effort on supporting this platform.

Your solution works fine (and should be added to a FAQ some place).  Alternaatively, use bash instead of sh to run configure.

Re-assigning to Guido to see if he agrees.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115392&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 16:29:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 08:29:56 -0700
Subject: [Python-bugs-list] [Bug #116117] cmath & umath fail to load on HPUX10.2
Message-ID: <200010051529.IAA32521@bush.i.sourceforge.net>

Bug #116117, was updated on 2000-Oct-05 05:21
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: cmath & umath fail to load on HPUX10.2

Details: Happens for builds of Python 1.6
with either cc or gcc.  I was able to fix this by adding "-lm" to
the build lines for both cmathmodule.sl and mathmodule.sl.
The problem does not occur with HPUX11.

Seems like one needs a SHLIB_LIBS variable in configure
or some such?

(To test, one just starts up python - built with shared modules -
and says "import math")



Follow-Ups:

Date: 2000-Oct-05 08:29
By: bwarsaw

Comment:
Sorry, I don't know anything about HPUX, nor do I have a machine to test this, or a possible fix, on.  I'm sure we'd accept patches against Python 2.0's configure script.

Re-assigning to Jeremy for disposition.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116117&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 16:32:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 08:32:27 -0700
Subject: [Python-bugs-list] [Bug #115676] repr(__builtin__.license) reads from stdin
Message-ID: <200010051532.IAA32652@bush.i.sourceforge.net>

Bug #115676, was updated on 2000-Sep-29 10:47
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Summary: repr(__builtin__.license) reads from stdin

Details: Invoking repr or str on __builtin__.license invokes the site._Printer's __repr__ mthod which interacts with the console.  This causes problems for tools, such as a debugger, that use repr to inspect the environment and might set a bad precedent  for definition of __repr__, which is documented to return a string representation of the value.  I realize that _Printer is used to provide a pager for the license in an interactive interpreter session.  Could it only be used when the session is interactive and disabled when running a scipt from a file?  I realize that individual tools can work around this, but it seems odd to have to special case this.

Follow-Ups:

Date: 2000-Oct-05 08:32
By: bwarsaw

Comment:
Guido fixed this in revision 1.20 of Lib/site.py so that repr(license) prints only a short message and does not read from stdin.

You now have to use "license()" to see the entire license text. 
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115676&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 16:35:49 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 08:35:49 -0700
Subject: [Python-bugs-list] [Bug #116144] Python 2.0b1  hangs
Message-ID: <200010051535.IAA24912@delerium.i.sourceforge.net>

Bug #116144, was updated on 2000-Oct-05 08:35
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Python 2.0b1  hangs

Details: Hi

My python program hangs after a while,  cannot even kill through ^C.  just hangs!

I am running python on the DEC Alpha system.   The program goes through 
a large flat file biological database. Reads entry by entry and prints 
some information after parsing each entry.  (an entry consists of number of lines).
I can give you more detail, if this was an unknown problem.


Ramu


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116144&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 16:38:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 08:38:10 -0700
Subject: [Python-bugs-list] [Bug #110836] configure script fails with cross-compiler (PR#228)
Message-ID: <200010051538.IAA00446@bush.i.sourceforge.net>

Bug #110836, was updated on 2000-Aug-01 14:14
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 3
Summary: configure script fails with cross-compiler (PR#228)

Details: Jitterbug-Id: 228
Submitted-By: dean@dragonsys.com
Date: Wed,  8 Mar 2000 15:36:00 -0500 (EST)
Version: 1.5.2
OS: Linux


I was trying to build python with a cross-compiler, so I put my cross-compiler
bin directory in the front of my path and executed the configure script. The
fact that a cross-compiler was being used was detected correctly, causing it to
fail later on at line 1922:
    { echo "configure: error: can not run test program while cross compiling"
1>&2; exit 1; }

This is a bug in configure, isn't it?





====================================================================
Audit trail:
Mon Apr 03 18:37:06 2000	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:14
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] configure script fails with cross-compiler (PR#228)
Date: Wed, 08 Mar 2000 22:19:12 -0500

> I was trying to build python with a cross-compiler, so I put my cross-compiler
> bin directory in the front of my path and executed the configure script. The
> fact that a cross-compiler was being used was detected correctly, causing it to
> fail later on at line 1922:
>     { echo "configure: error: can not run test program while cross compiling"
> 1>&2; exit 1; }
> 
> This is a bug in configure, isn't it?

Depends on your point of view.  It's a restriction that the configure
doesn't work with a cross compiler, because there are a bunch of tests
for which it needs to run code to determine the outcome.

If you want to contribute patches to configure.in to supply defaults
(I think there are 6-8 cases) that would be approciated.  See
python.org/patches/.

Cheers,

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Oct-05 08:38
By: bwarsaw

Comment:
I'm not sure what changes to configure are necessary to support cross compiling, but if we decide to fix this, it shouldn't be until after 2.0 final.

I've added this feature request to PEP 42, under the Building and Installing section.  Closing this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110836&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 16:43:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 08:43:04 -0700
Subject: [Python-bugs-list] [Bug #115221] test_poll hangs on Debian Linux 2.2
Message-ID: <200010051543.IAA25249@delerium.i.sourceforge.net>

Bug #115221, was updated on 2000-Sep-24 07:38
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: test_poll hangs on Debian Linux 2.2

Details: When run from the command-line test_poll.py prints
"This is a test." 12 times and then hangs, without ever printing "Poll test 1 complete".

All other tests seem to work just fine.

Follow-Ups:

Date: 2000-Sep-27 10:58
By: nascheme

Comment:
I can't reproduce this on my Debian 2.2 system running Linux
 2.2.16.  Can you give the output from "uname -a" and "dpkg 
-l libc6"?  I am using libc6 2.1.3-13.
-------------------------------------------------------

Date: 2000-Oct-05 07:17
By: jhylton

Comment:
Andrew -- Is this still a problem for you?  
-------------------------------------------------------

Date: 2000-Oct-05 07:52
By: akuchling

Comment:
I don't have a Debian system to reproduce this on.

-------------------------------------------------------

Date: 2000-Oct-05 08:43
By: larsga

Comment:
I did a "cvs update", recompiled and ran the regtest again. Problem still persists.

Traceback is
Traceback (most recent call last):
  File "test_poll.py", line 171, in ?
    test_poll1()
  File "test_poll.py", line 65, in test_poll1
    poll_unit_tests()
  File "test_poll.py", line 77, in poll_unit_tests
    r = p.poll()
KeyboardInterrupt

[larsga@pc-larsga test]$ uname -a
Linux pc-larsga 2.0.36 #2 Sun Jan 17 19:38:45 EST 1999 i686 unknown
[larsga@pc-larsga test]$ dpkg -l libc6
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  libc6          2.1.3-10       GNU C Library: Shared libraries and Timezone

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115221&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 16:48:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 08:48:25 -0700
Subject: [Python-bugs-list] [Bug #115221] test_poll hangs on Debian Linux 2.2
Message-ID: <200010051548.IAA00851@bush.i.sourceforge.net>

Bug #115221, was updated on 2000-Sep-24 07:38
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: test_poll hangs on Debian Linux 2.2

Details: When run from the command-line test_poll.py prints
"This is a test." 12 times and then hangs, without ever printing "Poll test 1 complete".

All other tests seem to work just fine.

Follow-Ups:

Date: 2000-Sep-27 10:58
By: nascheme

Comment:
I can't reproduce this on my Debian 2.2 system running Linux
 2.2.16.  Can you give the output from "uname -a" and "dpkg 
-l libc6"?  I am using libc6 2.1.3-13.
-------------------------------------------------------

Date: 2000-Oct-05 07:17
By: jhylton

Comment:
Andrew -- Is this still a problem for you?  
-------------------------------------------------------

Date: 2000-Oct-05 07:52
By: akuchling

Comment:
I don't have a Debian system to reproduce this on.

-------------------------------------------------------

Date: 2000-Oct-05 08:43
By: larsga

Comment:
I did a "cvs update", recompiled and ran the regtest again. Problem still persists.

Traceback is
Traceback (most recent call last):
  File "test_poll.py", line 171, in ?
    test_poll1()
  File "test_poll.py", line 65, in test_poll1
    poll_unit_tests()
  File "test_poll.py", line 77, in poll_unit_tests
    r = p.poll()
KeyboardInterrupt

[larsga@pc-larsga test]$ uname -a
Linux pc-larsga 2.0.36 #2 Sun Jan 17 19:38:45 EST 1999 i686 unknown
[larsga@pc-larsga test]$ dpkg -l libc6
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  libc6          2.1.3-10       GNU C Library: Shared libraries and Timezone

-------------------------------------------------------

Date: 2000-Oct-05 08:48
By: akuchling

Comment:
Interesting; Neil has libc6-2.1.3-13, while Lars has 2.1.3-10.  Presumably that last tag is a release level?

On the other hand, Neil is running a 2.2 Linux while Lars is running 2.0.36, and Neil also reported problems with
poll on a 2.0 machine.  So the finger of suspicion is pointing at the kernel...
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115221&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 16:58:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 08:58:53 -0700
Subject: [Python-bugs-list] [Bug #115469] test_socket hangs on Debian Linux 2.2
Message-ID: <200010051558.IAA25910@delerium.i.sourceforge.net>

Bug #115469, was updated on 2000-Sep-27 01:54
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: Fixed
Bug Group: Platform-specific
Priority: 7
Summary: test_socket hangs on Debian Linux 2.2

Details: The test runs until it prints "child connecting" and then just hangs. Pressing C-c causes a traceback that points at the
s.accept() call in line 105.

uname -a says
Linux pc-larsga 2.0.36 #2 Sun Jan 17 19:38:45 EST 1999 i686  unknown

ldd python says
libdl.so.2 => /lib/libdl.so.2 (0x4001a000)
libm.so.6 => /lib/libm.so.6 (0x4001e000)
libc.so.6 => /lib/libc.so.6 (0x4003b000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

This bug is probably related to 115221.

Follow-Ups:

Date: 2000-Sep-27 11:04
By: nascheme

Comment:
I can't reproduce this on my Debian 2.2 machine running 
Linux 2.2.16.  Which libc6 are you using (dpkg -l libc6)?  
Also, it is possible that something is wrong with the loopback network.  The output from "netstat -tnp; ifconfig lo" taken during the hang may be helpful
-------------------------------------------------------

Date: 2000-Oct-05 07:17
By: jhylton

Comment:
Lars-- Is this still a problem for you?  Can you provide any of the information Neil asked for?  If not, I think we should assume it is a Debian problem.

-------------------------------------------------------

Date: 2000-Oct-05 08:58
By: larsga

Comment:
I did a cvs update, recompile and new run of the test. It
no longer hangs for me. I have not updated the system in any way, so I can only assume that this has been fixed in some 
way.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115469&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 16:59:07 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 08:59:07 -0700
Subject: [Python-bugs-list] [Bug #115469] test_socket hangs on Debian Linux 2.2
Message-ID: <200010051559.IAA25913@delerium.i.sourceforge.net>

Bug #115469, was updated on 2000-Sep-27 01:54
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: Fixed
Bug Group: Platform-specific
Priority: 7
Summary: test_socket hangs on Debian Linux 2.2

Details: The test runs until it prints "child connecting" and then just hangs. Pressing C-c causes a traceback that points at the
s.accept() call in line 105.

uname -a says
Linux pc-larsga 2.0.36 #2 Sun Jan 17 19:38:45 EST 1999 i686  unknown

ldd python says
libdl.so.2 => /lib/libdl.so.2 (0x4001a000)
libm.so.6 => /lib/libm.so.6 (0x4001e000)
libc.so.6 => /lib/libc.so.6 (0x4003b000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

This bug is probably related to 115221.

Follow-Ups:

Date: 2000-Sep-27 11:04
By: nascheme

Comment:
I can't reproduce this on my Debian 2.2 machine running 
Linux 2.2.16.  Which libc6 are you using (dpkg -l libc6)?  
Also, it is possible that something is wrong with the loopback network.  The output from "netstat -tnp; ifconfig lo" taken during the hang may be helpful
-------------------------------------------------------

Date: 2000-Oct-05 07:17
By: jhylton

Comment:
Lars-- Is this still a problem for you?  Can you provide any of the information Neil asked for?  If not, I think we should assume it is a Debian problem.

-------------------------------------------------------

Date: 2000-Oct-05 08:58
By: larsga

Comment:
I did a cvs update, recompile and new run of the test. It
no longer hangs for me. I have not updated the system in any way, so I can only assume that this has been fixed in some 
way.
-------------------------------------------------------

Date: 2000-Oct-05 08:59
By: larsga

Comment:
I did a cvs update, recompile and new run of the test. It
no longer hangs for me. I have not updated the system in any way, so I can only assume that this has been fixed in some 
way.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115469&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 16:59:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 08:59:24 -0700
Subject: [Python-bugs-list] [Bug #115469] test_socket hangs on Debian Linux 2.2
Message-ID: <200010051559.IAA25917@delerium.i.sourceforge.net>

Bug #115469, was updated on 2000-Sep-27 01:54
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 7
Summary: test_socket hangs on Debian Linux 2.2

Details: The test runs until it prints "child connecting" and then just hangs. Pressing C-c causes a traceback that points at the
s.accept() call in line 105.

uname -a says
Linux pc-larsga 2.0.36 #2 Sun Jan 17 19:38:45 EST 1999 i686  unknown

ldd python says
libdl.so.2 => /lib/libdl.so.2 (0x4001a000)
libm.so.6 => /lib/libm.so.6 (0x4001e000)
libc.so.6 => /lib/libc.so.6 (0x4003b000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

This bug is probably related to 115221.

Follow-Ups:

Date: 2000-Sep-27 11:04
By: nascheme

Comment:
I can't reproduce this on my Debian 2.2 machine running 
Linux 2.2.16.  Which libc6 are you using (dpkg -l libc6)?  
Also, it is possible that something is wrong with the loopback network.  The output from "netstat -tnp; ifconfig lo" taken during the hang may be helpful
-------------------------------------------------------

Date: 2000-Oct-05 07:17
By: jhylton

Comment:
Lars-- Is this still a problem for you?  Can you provide any of the information Neil asked for?  If not, I think we should assume it is a Debian problem.

-------------------------------------------------------

Date: 2000-Oct-05 08:58
By: larsga

Comment:
I did a cvs update, recompile and new run of the test. It
no longer hangs for me. I have not updated the system in any way, so I can only assume that this has been fixed in some 
way.
-------------------------------------------------------

Date: 2000-Oct-05 08:59
By: larsga

Comment:
I did a cvs update, recompile and new run of the test. It
no longer hangs for me. I have not updated the system in any way, so I can only assume that this has been fixed in some 
way.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115469&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 17:02:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 09:02:37 -0700
Subject: [Python-bugs-list] [Bug #115469] test_socket hangs on Debian Linux 2.2
Message-ID: <200010051602.JAA26074@delerium.i.sourceforge.net>

Bug #115469, was updated on 2000-Sep-27 01:54
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 7
Summary: test_socket hangs on Debian Linux 2.2

Details: The test runs until it prints "child connecting" and then just hangs. Pressing C-c causes a traceback that points at the
s.accept() call in line 105.

uname -a says
Linux pc-larsga 2.0.36 #2 Sun Jan 17 19:38:45 EST 1999 i686  unknown

ldd python says
libdl.so.2 => /lib/libdl.so.2 (0x4001a000)
libm.so.6 => /lib/libm.so.6 (0x4001e000)
libc.so.6 => /lib/libc.so.6 (0x4003b000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

This bug is probably related to 115221.

Follow-Ups:

Date: 2000-Sep-27 11:04
By: nascheme

Comment:
I can't reproduce this on my Debian 2.2 machine running 
Linux 2.2.16.  Which libc6 are you using (dpkg -l libc6)?  
Also, it is possible that something is wrong with the loopback network.  The output from "netstat -tnp; ifconfig lo" taken during the hang may be helpful
-------------------------------------------------------

Date: 2000-Oct-05 07:17
By: jhylton

Comment:
Lars-- Is this still a problem for you?  Can you provide any of the information Neil asked for?  If not, I think we should assume it is a Debian problem.

-------------------------------------------------------

Date: 2000-Oct-05 08:58
By: larsga

Comment:
I did a cvs update, recompile and new run of the test. It
no longer hangs for me. I have not updated the system in any way, so I can only assume that this has been fixed in some 
way.
-------------------------------------------------------

Date: 2000-Oct-05 08:59
By: larsga

Comment:
I did a cvs update, recompile and new run of the test. It
no longer hangs for me. I have not updated the system in any way, so I can only assume that this has been fixed in some 
way.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115469&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 17:07:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 09:07:51 -0700
Subject: [Python-bugs-list] [Bug #116117] cmath & umath fail to load on HPUX10.2
Message-ID: <200010051607.JAA01696@bush.i.sourceforge.net>

Bug #116117, was updated on 2000-Oct-05 05:21
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Wont Fix
Bug Group: Platform-specific
Priority: 6
Summary: cmath & umath fail to load on HPUX10.2

Details: Happens for builds of Python 1.6
with either cc or gcc.  I was able to fix this by adding "-lm" to
the build lines for both cmathmodule.sl and mathmodule.sl.
The problem does not occur with HPUX11.

Seems like one needs a SHLIB_LIBS variable in configure
or some such?

(To test, one just starts up python - built with shared modules -
and says "import math")



Follow-Ups:

Date: 2000-Oct-05 08:29
By: bwarsaw

Comment:
Sorry, I don't know anything about HPUX, nor do I have a machine to test this, or a possible fix, on.  I'm sure we'd accept patches against Python 2.0's configure script.

Re-assigning to Jeremy for disposition.
-------------------------------------------------------

Date: 2000-Oct-05 09:07
By: jhylton

Comment:
The Setup file includes a comment noting the need to add the -lm flag.  It looks like you also figured it out.  We would be happy to accept a patch to configure.in that fixes this, but there is no bug per see.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116117&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 18:24:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 10:24:51 -0700
Subject: [Python-bugs-list] [Bug #115907] Encoding of "=" by quopri.py module
Message-ID: <200010051724.KAA04829@bush.i.sourceforge.net>

Bug #115907, was updated on 2000-Oct-03 05:47
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: Encoding of "=" by quopri.py module

Details: While making an automated mail sending engine, I used the quopri.encode(...) for my multipart mails.
quopri.encode(...) converts "=" into "==" while the mail clients expect "=3D". Thus I got some problems reading such mails with Outlook Express 5 , Netscape Messenger (Linux) and StarOffice Mail (Linux). Especially when the HTML part of the mail contains hyperkinks <a href=...>...</a> that crash Outlook express. The others make a 404 HTTP error.
I run Python 1.5.2, but this bug/feature remains perhaps with Python 1.6 and Python 2.0bx cause I didn't notice any change log to the quopri module.
I found a workaround (fix ?) by changing the "quote" function of "quopri.py" to this:
==== quopri.py ====
...
def quote(c):
## if c == ESCAPE:
##  return ESCAPE * 2
## else:
  i = ord(c)
  return ESCAPE + HEX[i/16] + HEX[i%16]
...
==== end quopri.py ====
Now, the 3 above mentioned mail clients read correctly the raw text and html parts of my mails - including hyperlinks.
Is it a bug, a feature, or did I misuse "quopri" ?

Follow-Ups:

Date: 2000-Oct-05 10:24
By: jhylton

Comment:
fixed in revision 1.7 of quopri

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115907&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 18:25:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 10:25:54 -0700
Subject: [Python-bugs-list] [Bug #116011] PyPort.h backward compatibility issues missing
Message-ID: <200010051725.KAA29445@delerium.i.sourceforge.net>

Bug #116011, was updated on 2000-Oct-04 08:23
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: Feature Request
Priority: 7
Summary: PyPort.h backward compatibility issues missing

Details: PyPort.h contain only Py_PROTO for backward compatibility.
I'm thinking about add also the "Py_FPROTO" ghost macro, this may speed up code porting to the new version.

Follow-Ups:

Date: 2000-Oct-05 10:25
By: lemburg

Comment:
Well, since it was used in the Python 1.5.x include files, I guess we can
make the assumption that at least some extensions also used it.

I'll check in a patch.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116011&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 19:04:49 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 11:04:49 -0700
Subject: [Python-bugs-list] [Bug #115392] Build under SunOS 4.1.4_JL fails
Message-ID: <200010051804.LAA06476@bush.i.sourceforge.net>

Bug #115392, was updated on 2000-Sep-26 12:13
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: Wont Fix
Bug Group: Platform-specific
Priority: 6
Summary: Build under SunOS 4.1.4_JL fails

Details: The linkage of the python executable fails under SunOS 4.1.4_JL since
LDFLAGS in Modules/Makefile is defined as:

  LDFLAGS = -L

That is, no value of the -L option is specified.  This definition seems
to be generated by the configure script.  The same problem raises even
though a explicit definition of LDFLAGS is given when the configure
script is invoked, as shown below:

  $ env LDFLAGS='' ./configure

(In fact, no -L options are needed for my configuration, so the linkage
is successfully done by running make LDFLAGS='').

Follow-Ups:

Date: 2000-Sep-26 12:18
By: kajiyama

Comment:
I forgot to give the version: 2.0b1, of course :-)
-------------------------------------------------------

Date: 2000-Sep-26 12:38
By: fdrake

Comment:
Assigned to Barry since he's the GNUish guy, and he should know enough autoconf to fix this.
-------------------------------------------------------

Date: 2000-Sep-27 10:09
By: loewis

Comment:
The bug is caused by the configure.in fragment

    if test -d "$with_threads"
    then LDFLAGS="$LDFLAGS -L$with_threads"
    fi

with_threads is empty, yet the test whether it is a directory(!) succeeds.

It appears that 'test -d' must be replaced with 'test -n' in many places in configure.in; bumped priority so this gets attention.
-------------------------------------------------------

Date: 2000-Oct-05 08:28
By: bwarsaw

Comment:
Should we worry about this?  I've tested -d "" with the Bourne shell on Linux, FreeBSD, and Solaris 2.6, and all return false as expected.  If SunOS 4.1.4_JL is anything like SunOS 4 in the US, it is ancient!  I personally don't think it's worth expending effort on supporting this platform.

Your solution works fine (and should be added to a FAQ some place).  Alternaatively, use bash instead of sh to run configure.

Re-assigning to Guido to see if he agrees.
-------------------------------------------------------

Date: 2000-Oct-05 11:04
By: gvanrossum

Comment:
It's easy enough to systematically replace test -d "$foo" with test ! -z "$foo" -a -d "$foo" everywhere in the configure script. I'd say do this; test -d "" is probably just ill-defined and shouldn't be relied on.

Barry, back to you!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115392&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 19:07:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 11:07:55 -0700
Subject: [Python-bugs-list] [Bug #116144] Python 2.0b1  hangs
Message-ID: <200010051807.LAA06636@bush.i.sourceforge.net>

Bug #116144, was updated on 2000-Oct-05 08:35
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Python 2.0b1  hangs

Details: Hi

My python program hangs after a while,  cannot even kill through ^C.  just hangs!

I am running python on the DEC Alpha system.   The program goes through 
a large flat file biological database. Reads entry by entry and prints 
some information after parsing each entry.  (an entry consists of number of lines).
I can give you more detail, if this was an unknown problem.


Ramu


Follow-Ups:

Date: 2000-Oct-05 11:07
By: gvanrossum

Comment:
We definitely need more information! One problem is that we don't have a DEC Alpha system to test on, so we can't easily try if out even if you gave us the source of your script and the input data!

Of course it's also possible that it's a bug in your program, or a change in Python that has nothing to do with DEC Alpha. But we can't tell from what you're saying! Can you reproduce the problem with a small test script? Also, please try if this is still broken with Python 2.0b2.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116144&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 19:43:49 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 11:43:49 -0700
Subject: [Python-bugs-list] [Bug #115392] Build under SunOS 4.1.4_JL fails
Message-ID: <200010051843.LAA32576@delerium.i.sourceforge.net>

Bug #115392, was updated on 2000-Sep-26 12:13
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 6
Summary: Build under SunOS 4.1.4_JL fails

Details: The linkage of the python executable fails under SunOS 4.1.4_JL since
LDFLAGS in Modules/Makefile is defined as:

  LDFLAGS = -L

That is, no value of the -L option is specified.  This definition seems
to be generated by the configure script.  The same problem raises even
though a explicit definition of LDFLAGS is given when the configure
script is invoked, as shown below:

  $ env LDFLAGS='' ./configure

(In fact, no -L options are needed for my configuration, so the linkage
is successfully done by running make LDFLAGS='').

Follow-Ups:

Date: 2000-Sep-26 12:18
By: kajiyama

Comment:
I forgot to give the version: 2.0b1, of course :-)
-------------------------------------------------------

Date: 2000-Sep-26 12:38
By: fdrake

Comment:
Assigned to Barry since he's the GNUish guy, and he should know enough autoconf to fix this.
-------------------------------------------------------

Date: 2000-Sep-27 10:09
By: loewis

Comment:
The bug is caused by the configure.in fragment

    if test -d "$with_threads"
    then LDFLAGS="$LDFLAGS -L$with_threads"
    fi

with_threads is empty, yet the test whether it is a directory(!) succeeds.

It appears that 'test -d' must be replaced with 'test -n' in many places in configure.in; bumped priority so this gets attention.
-------------------------------------------------------

Date: 2000-Oct-05 08:28
By: bwarsaw

Comment:
Should we worry about this?  I've tested -d "" with the Bourne shell on Linux, FreeBSD, and Solaris 2.6, and all return false as expected.  If SunOS 4.1.4_JL is anything like SunOS 4 in the US, it is ancient!  I personally don't think it's worth expending effort on supporting this platform.

Your solution works fine (and should be added to a FAQ some place).  Alternaatively, use bash instead of sh to run configure.

Re-assigning to Guido to see if he agrees.
-------------------------------------------------------

Date: 2000-Oct-05 11:04
By: gvanrossum

Comment:
It's easy enough to systematically replace test -d "$foo" with test ! -z "$foo" -a -d "$foo" everywhere in the configure script. I'd say do this; test -d "" is probably just ill-defined and shouldn't be relied on.

Barry, back to you!
-------------------------------------------------------

Date: 2000-Oct-05 11:43
By: bwarsaw

Comment:
Okay.  This patch is in 1.667 of configure.in, and the corresponding configure.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115392&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 20:26:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 12:26:39 -0700
Subject: [Python-bugs-list] [Bug #115973] Cygwin Fixes
Message-ID: <200010051926.MAA01700@delerium.i.sourceforge.net>

Bug #115973, was updated on 2000-Oct-03 20:40
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Summary: Cygwin Fixes

Details: With the following changes
Cygwin compiled Python supports dynamic libraries and can support Tkinter

===========
Python / dynload_shlib.c
~line 24
===========

const struct filedescr _PyImport_DynLoadFiletab[] = {
#ifdef __CYGWIN__
	{".pyd", "rb", C_EXTENSION},
	{".dll", "rb", C_EXTENSION},
#else
	{".so", "rb", C_EXTENSION},
	{"module.so", "rb", C_EXTENSION},
#endif
	{0, 0}
};


==========
Modules / _tkinker.c
~line 60
==========

#if !(defined(MS_WINDOWS) || defined(__CYGWIN__))
#define HAVE_CREATEFILEHANDLER
#endif



Follow-Ups:

Date: 2000-Oct-05 12:26
By: tim_one

Comment:
I've checked this in.  Thanks, Norman!  In the future, please submit an actual (context diff) patch via the patch manager instead (and if Cygwin doesn't support "diff -c", it's not worth porting to <wink>).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115973&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 20:40:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 12:40:46 -0700
Subject: [Python-bugs-list] [Bug #116172] 2.0b2 curses module fails to build on SGI
Message-ID: <200010051940.MAA02295@delerium.i.sourceforge.net>

Bug #116172, was updated on 2000-Oct-05 12:40
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 2.0b2 curses module fails to build on SGI

Details: I didn't see this in the database.

Trying to build 2.0b2 here on SGI IRIX 6.5.  I have this
line in Setup:

     _curses _cursesmodule.c -lcurses -ltermcap

This used to work on 1.5.2 on IRIX 6.5, but it doesn't with 2.0b2.

Here is a digested version of the errors:

cc -n32  -O -KPIC -I./../Include -I.. -DHAVE_CONFIG_H -c ./_cursesmodule.c
...
  The identifier "attr_t" is undefined.
  The identifier "ACS_S3" is undefined.
  The identifier "ACS_LEQUAL" is undefined.
  The identifier "ACS_GEQUAL" is undefined.
  The identifier "ACS_PI" is undefined.
  The identifier "ACS_NEQUAL" is undefined.
  The identifier "ACS_STERLING" is undefined.
  A value of type "int" cannot be assigned to an entity of type "char *".
        capname = tigetstr( capname );
                ^
  The identifier "A_HORIZONTAL" is undefined.
  The identifier "A_LEFT" is undefined.
  The identifier "A_LOW" is undefined.
  The identifier "A_RIGHT" is undefined.
  The identifier "A_TOP" is undefined.
  The identifier "A_VERTICAL" is undefined.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116172&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 20:50:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 12:50:10 -0700
Subject: [Python-bugs-list] [Bug #116174] using %% in cstrings sometimes fails with unicode params
Message-ID: <200010051950.MAA02691@delerium.i.sourceforge.net>

Bug #116174, was updated on 2000-Oct-05 12:50
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: using %% in cstrings sometimes fails with unicode params

Details: There are various ways to show this but here's an example:

>>> "%s %%" % u"test"
u'test %'
>>> "%% %s %%" % u"test"
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: not all arguments converted

This is still present in a recent CVS version of Python2.0

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116174&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 20:57:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 12:57:31 -0700
Subject: [Python-bugs-list] [Bug #116174] using %% in cstrings sometimes fails with unicode params
Message-ID: <200010051957.MAA03029@delerium.i.sourceforge.net>

Bug #116174, was updated on 2000-Oct-05 12:50
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 9
Summary: using %% in cstrings sometimes fails with unicode params

Details: There are various ways to show this but here's an example:

>>> "%s %%" % u"test"
u'test %'
>>> "%% %s %%" % u"test"
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: not all arguments converted

This is still present in a recent CVS version of Python2.0

Follow-Ups:

Date: 2000-Oct-05 12:57
By: gvanrossum

Comment:
Marc-Andre, this is clearly a bug in the unicode specific % formatting code... Can you fix it before Sunday?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116174&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 21:10:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 13:10:06 -0700
Subject: [Python-bugs-list] [Bug #110611] Signal processing bug (Linux threads, readline, whatever else) (PR#196)
Message-ID: <200010052010.NAA03487@delerium.i.sourceforge.net>

Bug #110611, was updated on 2000-Jul-31 14:05
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Summary: Signal processing bug (Linux threads, readline, whatever else) (PR#196)

Details: Jitterbug-Id: 196
Submitted-By: Gregor Hoffleit <flight@mathi.uni-heidelberg.de>
Date: Tue, 1 Feb 2000 14:43:09 +0100
Version: None
OS: None

--FL5UXtIhxfXey3p5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hi,

this must be the strangest bug report ever sent to bugs-py ;-).

I don't expect a resolution for this bug from you, I just wanted to make
sure this thing is recorded and the BTS. Perhaps somebody could give me a
hint where I could look for the misbehavior. Candidates seem to be glibc,
LinuxThreads, GNU readline, the Python readline module and the Python thread
support ;-)

In 1.5.2, there's a strange problem with signals on Linux systems. This has
been discussed before on the mailing list, probably it even has a relation
to Bug#102 ("incorrect signal processing"), but IMHO this reports adds a few
other aspects. Definitely it is a (platform-specific) problem in 1.5.2.


I have problems describing the bug, since the behavior seems to depend on so
many parameters. The most obvious incarnation of the problem is probably
this:

In the Python 1.5.2 interpreter included with Debian 2.2 ("potato"), if you
press Control-C on the command line (or send a SIGINT), the interpreter
exits to the shell:

  freefly;104> python
  Python 1.5.2 (#0, Sep 13 1999, 09:12:57)  [GCC 2.95.1 19990816 (release)]=
 on
      linux2=20
  Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
  >>> [Ctrl-C]
  freefly;105>=20

Normally, you'd expect a KeyboardInterrupt exception here.



Now I tried and compiled different configurations of Python (each from a
pristine source tree) on this Debian system:

  (151+t+rl)   Python 1.5.1 (threads, readline)
  (152)        Python 1.5.2 (no threads, no readline) =20
  (152+rl)     Python 1.5.2 (no threads, readline)
  (152+t)      Python 1.5.2 (threads, no readline)
  (152+t+rl)   Python 1.5.2 (threads, readline)
  (152+pth+rl) Python 1.5.2 (GNU Pth threads, readline)

Thread support was realized with glibc 2.1.2's LinuxThreads, i.e. pthreads.
readline was GNU readline 2.1 (for the record, I also tried 4.1beta3, but
this made no difference).

When I refer to Debian 2.1 ("slink"), this is a system with glibc 2.0.7 and
the same GNU readline version 2.1.



The following tables show the output of some experiments with those
configurations. The [] brackets show the keys pressed. Note that a line like
"[Ctrl-C][Enter]" implies that the interpreter showed no visible reaction to
the first Ctrl-C! "----" lines mean that I started up a new clean session.


(1) This is what happens when you start up a new interpreter and press
    Ctrl-C once, twice and so on, while on the command line:

152,152+t             152+rl,152+pth+rl  152+t+rl        151+t+rl
=3D=3D=3D=3D=3D=3D=3D=3D=3D             =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D  =3D=3D=3D=3D=3D=3D=3D=3D        =3D=3D=3D=3D=3D=3D=3D=3D
------------------    ----------------   -------------   ----------------
>>> [Ctrl-C][Ctrl-C]  >>> [Ctrl-C]       >>> [Ctrl-C]    >>> [Ctrl-C][Ct...]
KeyboardInterrupt     KeyboardInterrupt  freefly:5>      ----------------
>>> [Ctrl-C]          >>> [Ctrl-C]       -------------
KeyboardInterrupt     KeyboardInterrupt
>>> [Ctrl-C]          >>> [Ctrl-C]
KeyboardInterrupt     KeyboardInterrupt
>>> [Ctrl-C]          >>> [Ctrl-C]
KeyboardInterrupt     KeyboardInterrupt
------------------    ----------------

                                         152+t+rl (on a Debian 2.1 system)
                                         =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
                                         ---------------------
                                         >>> [Ctrl-C]
                                         KeyboardInterrupt
                                         >>> [Ctrl-C][Ctr...]
                                         ---------------------

  -> 1.5.2 with readline but without LinuxThreads is right.
  -> For some reason, 1.5.2 without readline ignores the first SIGINT.
  -> 1.5.2 with both readline and LinuxThreads kill the interpreter.
  -> 1.5.1 seems to ignore all SIGINTs's. =20
  -> For 1.5.2 running glibc 2.0.7 (instead of 2.1.2) and readline, the
     interpreter doesn't get killed, but still after the first SIGINT all
     following SIGINTs are ignored.
    =20
  -> It's worth a note that with only one of readline or thread support, the
     package seems to behave more reasonable; have both enabled is bad.
    =20
  -> With threading support by means of GNU Pth (instead of the native libc6
     LinuxThreads), the package behaves more correctly, too!

    =20
(2) Now on those systems who seemed to ignore the first SIGINT, I pressed
    Enter after it:

152,152+t                           151+t+rl
=3D=3D=3D=3D=3D=3D=3D=3D=3D                           =3D=3D=3D=3D=3D=3D=3D=
=3D
---------------------               --------------------
>>> [Ctrl-C][Enter]                 >>> [Ctrl-C][Enter]
Traceback (innermost last):         Traceback (innermost last):
  File "<stdin>", line 0, in ?      File "<stdin>", line 0, in ?
KeyboardInterrupt                   KeyboardInterrupt
>>> [Ctrl-C]                        >>> [Ctrl-C][Enter]
KeyboardInterrupt                   Traceback (innermost last):
---------------------                 File "<stdin>", line 0, in ?
                                    KeyboardInterrupt
                                    >>>
                                    --------------------

				   =20
  -> Obviously, the interpreter *DID* record the SIGINT in the first place,
     it just didn't provoke any immediate action=20
  -> On 1.5.2 without readline, the second and all following SIGINTs are
     handled as one would expect.
  -> 1.5.1 with thread and readline shows this strange behavior not only for
     the first, but also for the second and any following SIGINT.


    =20
(3) On the glibc 2.0.7 system, I verified that indeed all subsequent SIGINTs
    are ignored. You're not able even to interrupt a loop, after the
    interpreter has received a SIGINT while he was on the command line:
    =20
152+t+rl (on a Debian 2.1 system)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
---------------------
>>> [Ctrl-C]
KeyboardInterrupt
>>> [Ctrl-C][Enter]
>>> [Ctrl-C][Enter]
{kein weiteres SIGINT
wird akzeptiert, auch im Laufen:}
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
=2E..
999
>>>
---------------------
---------------------
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
Traceback (innermost last):
  File "<stdin>", line 1, in ?
KeyboardInterrupt
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
Traceback (innermost last):
  File "<stdin>", line 1, in ?
KeyboardInterrupt
>>> [Ctrl-C]
KeyboardInterrupt
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
=2E..
999
>>>
---------------------

  -> Note that it didn't hurt to break multiple times into a loop;
     only SIGINTs on the command line do mess up the interpreter!


    =20
    =20
(4) In the Debian 2.2 Python package, you have to be careful not to kill the
    interpreter; that's especially a problem when you try to break into a
    loop--if you hold down Ctrl-C for too long, the interpreter quits!
    =20
152+t+rl (Debian 2.2 package)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
---------------------
>>> [Ctrl-C]
freefly:5>
---------------------
---------------------
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401

KeyboardInterrupt
>>>
---------------------
---------------------
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C pressed down for a longer time]
400
401

freefly;19>=20
---------------------




(5) The Debian 2.2 package behaves more reasonable when the readline module
    has been moved out of the way:

152+t (Debian 2.2 package, readline module moved out of the way)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
---------------------
>>> [Ctrl-C][Ctrl-C]
KeyboardInterrupt
>>> ...                   (vgl. 152, 152+t)
---------------------
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
40[Enter]
Traceback (innermost last):
  File "<stdin>", line 0, in ?
KeyboardInterrupt
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
KeyboardInterrupt
>>>


--FL5UXtIhxfXey3p5
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4luLt3eVfDf25G40RAQw9AKDhLyI7RDYt3G85Rxet2ZlK1b1nKwCg3zl/
tasWxAOGLUK3K3ucMBbhBag=
=PTOI
-----END PGP SIGNATURE-----

--FL5UXtIhxfXey3p5--


====================================================================
Audit trail:
Mon Feb 07 12:38:12 2000	guido	changed notes
Mon Feb 07 12:38:12 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Jul-31 14:05
By: none

Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196)
Date: Wed, 2 Feb 2000 03:04:04 -0500

[flight@mathi.uni-heidelberg.de]

> this must be the strangest bug report ever sent to bugs-py ;-).

No, but I don't recall one that evidenced more hard & tedious work!  Wow.
Thank you.  Switch to Windows -- it's so much more reliable <wink>.

If you haven't already done so, may I suggest building Python from the
current CVS development source tree instead?

http://www.python.org/download/cvs.html

This may be a waste of effort, but I'd hate to see you pour more time
tracking down obscure bugs that may already have been fixed.  Contrarily, if
the current CVS version still displays the problems, more work devoted to
tracking them down is certain not to be a waste.



-------------------------------------------------------

Date: 2000-Jul-31 14:05
By: none

Comment:
From: Gregor Hoffleit <flight@mathi.uni-heidelberg.de>
Subject: RE: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196)
Date: Wed, 2 Feb 2000 14:25:07 +0100

Hi,

> If you haven't already done so, may I suggest building Python from the
> current CVS development source tree instead?

sorry, I forgot to mention that I tried that. Didnt't change the behavior
at all (I also saw that there were no big changes to the readline nor to
the threading code since 1.5.2).

    Gregor


-------------------------------------------------------

Date: 2000-Jul-31 14:05
By: none

Comment:
From: Gregor Hoffleit <flight@mathi.uni-heidelberg.de>
Subject: Returned mail: User unknown
Date: Thu, 3 Feb 2000 11:46:44 +0100 (MET)

This is a MIME-encapsulated message

--LAA26536.949574804/relay.uni-heidelberg.de

The original message was received at Thu, 3 Feb 2000 11:46:41 +0100 (MET)
from mailserver.mathi.uni-heidelberg.de [129.206.26.32]

   ----- The following addresses had permanent fatal errors -----
<bugs-by@python.org>

   ----- Transcript of session follows -----
.. while talking to parrot.python.org.:
>>> RCPT To:<bugs-by@python.org>
<<< 550 <bugs-by@python.org>... User unknown
550 <bugs-by@python.org>... User unknown

--LAA26536.949574804/relay.uni-heidelberg.de
Content-Type: message/delivery-status

Reporting-MTA: dns; relay.uni-heidelberg.de
Received-From-MTA: DNS; mailserver.mathi.uni-heidelberg.de
Arrival-Date: Thu, 3 Feb 2000 11:46:41 +0100 (MET)

Final-Recipient: RFC822; bugs-by@python.org
Action: failed
Status: 5.1.1
Remote-MTA: DNS; parrot.python.org
Diagnostic-Code: SMTP; 550 <bugs-by@python.org>... User unknown
Last-Attempt-Date: Thu, 3 Feb 2000 11:46:44 +0100 (MET)

--LAA26536.949574804/relay.uni-heidelberg.de
Content-Type: message/rfc822

Return-Path: <flight@mathi.uni-heidelberg.de>
Received: from mailserver.mathi.uni-heidelberg.de (mailserver.mathi.uni-heidelberg.de [129.206.26.32])
	by relay.uni-heidelberg.de (8.9.3+Sun/8.9.3) with ESMTP id LAA26531
	for <bugs-by@python.org>; Thu, 3 Feb 2000 11:46:41 +0100 (MET)
Received: from testserv.mathi.uni-heidelberg.de (testserv.mathi.uni-heidelberg.de [129.206.26.30])
	by mailserver.mathi.uni-heidelberg.de (Postfix) with SMTP id CFF5512917
	for <bugs-by@python.org>; Thu,  3 Feb 2000 11:48:11 +0100 (CET)
Received: by testserv.mathi.uni-heidelberg.de (sSMTP sendmail emulation); Thu, 3 Feb 2000 11:48:12 +0100
Date: Thu, 3 Feb 2000 11:48:12 +0100
From: Gregor Hoffleit <flight@mathi.uni-heidelberg.de>
To: bugs-by@python.org
Subject: RE: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196)
Message-ID: <20000203114812.B18567@mathi.uni-heidelberg.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0pre3i

Fredric Lundh pointed me to Alex Zbyslaw's posting regarding this topic
(http://x44.deja.com/getdoc.xp?AN=545159177).

Indeed Alex' patch1 (http://www.xfb52.dial.pipex.com/patches/python.shtml)
for FreeBSD (disabling the interrupt handler chanege in the readline module)
works for Debian, too, i.e. if I stick with the default inthandler in the
readline module, SIGINT doesn't kill the interpreter anymore.

Still, the drawback of this change is that I have to press RETURN before
a SIGINT is spotted by Python (btw, this is the same behavior as with 1.5.1
on the system with the same configuration).

Still, IMHO this behavior is preferable.

    Gregor

--LAA26536.949574804/relay.uni-heidelberg.de--


-------------------------------------------------------

Date: 2000-Jul-31 14:05
By: none

Comment:
From: Gregor Hoffleit <flight@mathi.uni-heidelberg.de>
Subject: Re: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196)
Date: Fri, 11 Feb 2000 14:52:42 +0100


--dDRMvlgZJXvWKvBx
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Ok, one more data point:

On Fri, Feb 11, 2000 at 08:29:43AM -0500, Randall Hopper wrote:
> You know, I think you may have it.  On IRIX, I don't have Python built
> with threads.  However, on FreeBSD at home I'd guess that it is (I built =
it
> from ports).  My IRIX python has no problem with Ctrl-C while my FreeBSD
> version at home locks up with Ctrl-C.  I rebuilt my IRIX Python
> --with-thread, and now it hangs when Ctrl-C is hit.

And now, we're three: When using threads and readline, Ctrl-C hangs IRIX and
FreeBSD and kills Linux Python.

This doesn't sound like a kernel problem, more like a problem with readline
not being thread-safe I guess.

    Gregor
   =20

--dDRMvlgZJXvWKvBx
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4pBQq3eVfDf25G40RAUbSAJ41b+DgwHEmRUm0uQcJLjvZ3ROiSwCdH8Xq
jFH5J1TsLQBbQTPU5Xvv0Bo=
=0j16
-----END PGP SIGNATURE-----

--dDRMvlgZJXvWKvBx--

-------------------------------------------------------

Date: 2000-Sep-15 19:47
By: gvanrossum

Comment:
Some progress notes:

There are several bugs here.

1. The combination readline + threads causes ^C to just exit or die.
I've found that this can be fixed with readline 4.x by setting the global variable rl_catch_signals to 0 in setup_readline(). But my Red Hat 6. 2 system still comes with readline 2.2. How can I detect the readline version? And what to do for readline 2.2?

2. Without the readline module, the first ^C requires [Enter] before it is seen.
I haven't researched this yet, but will.

3. Debian 2.1 ignores the second and all subsequent ^Cs.
I won't look into this; apparently it's fixed in Debian 2.2.

4. Similar problems on IRIX.
I'll presume this is the same as (1).
-------------------------------------------------------

Date: 2000-Sep-16 09:43
By: gvanrossum

Comment:
Whew! It looks like BOTH bugs (1) and (2) from my previous comment were caused by mixing of signal() and sigaction(). It appears that if signal() is used to set a handler, sigaction() doesn't report it as the old handler, and vice versa. Possibly this bug is more severe when threads are used.

Bugs (1) and (2) are both fixed now -- I've introduced new APIs PyOS_setsig() and PyOS_getsig() that use sigaction() if it exists and signal() otherwise, and changed the readline and signal modules to use this.

I won't look into the other problems -- if there are still problems with signals, please submit a new bug report.
-------------------------------------------------------

Date: 2000-Oct-05 13:10
By: VizNut

Comment:
Just a note:  the Ctrl-C hangs at the interactive Python prompt with readline is still a problem on IRIX with Python 2.0b2.  

I rebuilt --without-threads again and now the Python prompt behaves as it should:

> python2
Python 2.0b2 (#1, Oct  5 2000, 16:05:21) [C] on irix646-n32
Type "copyright", "credits" or "license" for more information.
>>> 
KeyboardInterrupt
>>> 
KeyboardInterrupt
>>> 
KeyboardInterrupt
>>> 



-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110611&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 21:29:33 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 13:29:33 -0700
Subject: [Python-bugs-list] [Bug #112786] Build under Cygwin fails
Message-ID: <200010052029.NAA12470@bush.i.sourceforge.net>

Bug #112786, was updated on 2000-Aug-26 01:39
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: Build under Cygwin fails

Details: Py1.6b1
========
1) socketmodule.c -- looks for netinet/tcp.h, which does not exist on cygwin.

2) gcc   python.o \
          ../libpython1.6.a    -lm  -o python
python.o: In function `main':
/usr/local/bin/Python-1.6b1/Modules/python.c:12: undefined reference to `Py_Main


Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-13 04:13
By: gvanrossum

Comment:
I don't have cygwin. Does anyone here have cygwin? I know Tim said the cygwin installer failed for him, so he doesn't have it. Is there someone outside the PythonLabs to whom we could assign this?
-------------------------------------------------------

Date: 2000-Sep-16 01:56
By: tim_one

Comment:
A fellow named Norman mailto:nhv@yahoo.com posted to c.l.py with some evidence of real Cygwin knowledge, so I emailed him a link to this bug and asked whether he'd help out.
-------------------------------------------------------

Date: 2000-Sep-16 20:29
By: nhv

Comment:
Hi I am that fellow Norman

FYI I have been doing bi-weekly builds of the Python CVS source with the 'current' Cygwin distribution for about a year.

I sent Tim my small set of diffs

Basically threading with Cygwin Python is still broken
and dll building with Cygwin has some problems but other then that everything including tkinter works for me with very minor changes.

FWIW We are succesfully embedding Python in PrettyPoly
http://prettypoly.sourceforge.net and I am using Cygwin
as my development enviroment for this

If helpful I can mail someone my diffs and the results of make test after each of my CVS sessions or apon request

Also FWIW I build Cygwin from source and have access to the Cygwin development team

I will help in anyway I can to make Python compile with Cygwin 'out of the box'  


Norman Vine nhv@yahoo.com

-------------------------------------------------------

Date: 2000-Sep-17 05:41
By: tim_one

Comment:
Here's the body of email from Norman:

I will certainly help in anyway that I can :-)

Below is a diff of my PY_SRC and the Python CVS at SourceForge

specifically

1) socketmodule.c -- looks for netinet/tcp.h, which does not exist on cygwin.

Cygwin does not have netinet / tcp.h
There has been some discussion about including a dummy tcp.h
into the distribution but I am noy sure that this is a standard header ?
see
http://sources.redhat.com/ml/cygwin/2000-09/msg00011.html

2) gcc python.o \
../libpython1.6.a -lm -o python
python.o: In function `main':
/usr/local/bin/Python-1.6b1/Modules/python.c:12: undefined reference to
`Py_Main

Before rerunning make after a failed build it is occasionally necessary to from top_level python_src directory it is necessary to do
% rm *.a *.o *.exe
I believe that this will solve this problem

I am working with the 2.0 srource tree though and I notice that this is reported against the 1.6 tree


IMHO the two main 'issues'  with Python and Cygwin remaining
are threads and dll support.

I am working on the dll stuff and am aware of Distutils

The thread stuff is beyond me and I could use some help.

I will gladly be a Cygwin 'tester' for Python.

and can forward Cygwin specific Python questions that
I can not answer directly to the appropriate Cygwin list(s)

Cheers

Norman


Index: _tkinter.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/_tkinter.c,v
retrieving revision 1.111
diff -r1.111 _tkinter.c
0a1
>
60,62c61,63
< #if !defined(MS_WINDOWS)
< #define HAVE_CREATEFILEHANDLER
< #endif
---
> //#if !(defined(MS_WINDOWS) || defined(__CYGWIN__))
> //#define HAVE_CREATEFILEHANDLER
> //#endif
64a66
> #undef HAVE_CREATEFILEHANDLER
71c73
< #ifdef MS_WINDOWS
---
> #if defined(MS_WINDOWS) || defined(__CYGWIN__)
Index: main.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/main.c,v
retrieving revision 1.44
diff -r1.44 main.c
11c11
< #ifdef MS_WINDOWS
---
> #if defined(MS_WINDOWS) || defined(__CYGWIN__)
187c187
< #ifdef MS_WINDOWS
---
> #if defined(MS_WINDOWS) || defined(__CYGWIN__)
209c209
< #ifdef MS_WINDOWS
---
> #if defined(MS_WINDOWS) || defined(__CYGWIN__)
Index: socketmodule.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v
retrieving revision 1.127
diff -r1.127 socketmodule.c
125c125
< #ifndef __BEOS__
---
> #if !defined(__BEOS__) && !defined(__CYGWIN__)

-------------------------------------------------------

Date: 2000-Oct-05 13:29
By: jhylton

Comment:
Can we close this bug now?

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112786&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 21:37:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 13:37:47 -0700
Subject: [Python-bugs-list] [Bug #116174] using %% in cstrings sometimes fails with unicode params
Message-ID: <200010052037.NAA04641@delerium.i.sourceforge.net>

Bug #116174, was updated on 2000-Oct-05 12:50
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 9
Summary: using %% in cstrings sometimes fails with unicode params

Details: There are various ways to show this but here's an example:

>>> "%s %%" % u"test"
u'test %'
>>> "%% %s %%" % u"test"
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: not all arguments converted

This is still present in a recent CVS version of Python2.0

Follow-Ups:

Date: 2000-Oct-05 12:57
By: gvanrossum

Comment:
Marc-Andre, this is clearly a bug in the unicode specific % formatting code... Can you fix it before Sunday?
-------------------------------------------------------

Date: 2000-Oct-05 13:37
By: lemburg

Comment:
Ok, here's what I think is going wrong:

When the string %-formatting code sees a Unicode object as
argument, it tries to pass the already formatted part of the string
together with the not yet formatted part to the Unicode %-formatting
code which then takes care of formatting the remaining arguments.

The reason for this was to avoid duplicate evaluations of %-arguments.

Now if there happens to be a "%%" *before* the first Unicode
argument, the Unicode %-formatting function will see this
as "%" (it was already formatted by the string %-formatting
code) and this produces the error message you see.

I will look into this, but can't promise anything w/r to the deadline.
The patch will surely be a little complicated due to the way
the string/Unicode interaction works here.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116174&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 22:58:23 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 14:58:23 -0700
Subject: [Python-bugs-list] [Bug #112786] Build under Cygwin fails
Message-ID: <200010052158.OAA07756@delerium.i.sourceforge.net>

Bug #112786, was updated on 2000-Aug-26 01:39
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: Build under Cygwin fails

Details: Py1.6b1
========
1) socketmodule.c -- looks for netinet/tcp.h, which does not exist on cygwin.

2) gcc   python.o \
          ../libpython1.6.a    -lm  -o python
python.o: In function `main':
/usr/local/bin/Python-1.6b1/Modules/python.c:12: undefined reference to `Py_Main


Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-13 04:13
By: gvanrossum

Comment:
I don't have cygwin. Does anyone here have cygwin? I know Tim said the cygwin installer failed for him, so he doesn't have it. Is there someone outside the PythonLabs to whom we could assign this?
-------------------------------------------------------

Date: 2000-Sep-16 01:56
By: tim_one

Comment:
A fellow named Norman mailto:nhv@yahoo.com posted to c.l.py with some evidence of real Cygwin knowledge, so I emailed him a link to this bug and asked whether he'd help out.
-------------------------------------------------------

Date: 2000-Sep-16 20:29
By: nhv

Comment:
Hi I am that fellow Norman

FYI I have been doing bi-weekly builds of the Python CVS source with the 'current' Cygwin distribution for about a year.

I sent Tim my small set of diffs

Basically threading with Cygwin Python is still broken
and dll building with Cygwin has some problems but other then that everything including tkinter works for me with very minor changes.

FWIW We are succesfully embedding Python in PrettyPoly
http://prettypoly.sourceforge.net and I am using Cygwin
as my development enviroment for this

If helpful I can mail someone my diffs and the results of make test after each of my CVS sessions or apon request

Also FWIW I build Cygwin from source and have access to the Cygwin development team

I will help in anyway I can to make Python compile with Cygwin 'out of the box'  


Norman Vine nhv@yahoo.com

-------------------------------------------------------

Date: 2000-Sep-17 05:41
By: tim_one

Comment:
Here's the body of email from Norman:

I will certainly help in anyway that I can :-)

Below is a diff of my PY_SRC and the Python CVS at SourceForge

specifically

1) socketmodule.c -- looks for netinet/tcp.h, which does not exist on cygwin.

Cygwin does not have netinet / tcp.h
There has been some discussion about including a dummy tcp.h
into the distribution but I am noy sure that this is a standard header ?
see
http://sources.redhat.com/ml/cygwin/2000-09/msg00011.html

2) gcc python.o \
../libpython1.6.a -lm -o python
python.o: In function `main':
/usr/local/bin/Python-1.6b1/Modules/python.c:12: undefined reference to
`Py_Main

Before rerunning make after a failed build it is occasionally necessary to from top_level python_src directory it is necessary to do
% rm *.a *.o *.exe
I believe that this will solve this problem

I am working with the 2.0 srource tree though and I notice that this is reported against the 1.6 tree


IMHO the two main 'issues'  with Python and Cygwin remaining
are threads and dll support.

I am working on the dll stuff and am aware of Distutils

The thread stuff is beyond me and I could use some help.

I will gladly be a Cygwin 'tester' for Python.

and can forward Cygwin specific Python questions that
I can not answer directly to the appropriate Cygwin list(s)

Cheers

Norman


Index: _tkinter.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/_tkinter.c,v
retrieving revision 1.111
diff -r1.111 _tkinter.c
0a1
>
60,62c61,63
< #if !defined(MS_WINDOWS)
< #define HAVE_CREATEFILEHANDLER
< #endif
---
> //#if !(defined(MS_WINDOWS) || defined(__CYGWIN__))
> //#define HAVE_CREATEFILEHANDLER
> //#endif
64a66
> #undef HAVE_CREATEFILEHANDLER
71c73
< #ifdef MS_WINDOWS
---
> #if defined(MS_WINDOWS) || defined(__CYGWIN__)
Index: main.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/main.c,v
retrieving revision 1.44
diff -r1.44 main.c
11c11
< #ifdef MS_WINDOWS
---
> #if defined(MS_WINDOWS) || defined(__CYGWIN__)
187c187
< #ifdef MS_WINDOWS
---
> #if defined(MS_WINDOWS) || defined(__CYGWIN__)
209c209
< #ifdef MS_WINDOWS
---
> #if defined(MS_WINDOWS) || defined(__CYGWIN__)
Index: socketmodule.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v
retrieving revision 1.127
diff -r1.127 socketmodule.c
125c125
< #ifndef __BEOS__
---
> #if !defined(__BEOS__) && !defined(__CYGWIN__)

-------------------------------------------------------

Date: 2000-Oct-05 13:29
By: jhylton

Comment:
Can we close this bug now?

-------------------------------------------------------

Date: 2000-Oct-05 14:58
By: tim_one

Comment:
I doubt it.  These changes don't match the ones Norman posted in his other "bug" report.  Until he submits a proper context-diff patch or says "nevermind", I expect all Cygwin bugs should remain open.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112786&group_id=5470


From noreply@sourceforge.net  Thu Oct  5 23:26:41 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 15:26:41 -0700
Subject: [Python-bugs-list] [Bug #116136] sre recursion limit hit in tokenize.py
Message-ID: <200010052226.PAA08794@delerium.i.sourceforge.net>

Bug #116136, was updated on 2000-Oct-05 07:21
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: sre recursion limit hit in tokenize.py

Details: While running Tim Peters' new reindent script over my code,
I received the following traceback:

checking ./dtcout.py ...
Traceback (most recent call last):
  File "/usr/local/bin/reindent", line 258, in ?
    main()
  File "/usr/local/bin/reindent", line 65, in main
    check(arg)
  File "/usr/local/bin/reindent", line 77, in check
    check(fullname)
  File "/usr/local/bin/reindent", line 90, in check
    if r.run():
  File "/usr/local/bin/reindent", line 135, in run
    tokenize.tokenize(self.getline, self.tokeneater)
  File "/usr/local/lib/python2.0/tokenize.py", line 152, in tokenize
    pseudomatch = pseudoprog.match(line, pos)
RuntimeError: maximum recursion limit exceeded

The pattern compiled into pseudoprog is

[ \f\t]*((\\\r?\n|#[^\r\n]*|([rR]?'''|[rR]?"""))|((0[jJ]|[1-9]\d*[jJ]|((\d+\.\d*|\.\d+)([eE][-+]?\d+)?|[1-9]\d*[eE][-+]?\d+)[jJ])|((\d+\.\d*|\.\d+)([eE][-+]?\d+)?|[1-9]\d*[eE][-+]?\d+)|(0[xX][\da-fA-F]*[lL]?|0[0-7]*[lL]?|[1-9]\d*[lL]?))|((\+=|\-=|\*=|%=|/=|\*\*=|&=|\|=|\^=|>>=|<<=|\+|\-|\*\*|\*|\^|~|/|%|&|\||<<|>>|==|<=|<>|!=|>=|=|<|>)|[][(){}]|(\r?\n|[:;.,`]))|([rR]?'(\\.|[^\n'\\])*('|\\\r?\n)|[rR]?"(\\.|[^\n"\\])*("|\\\r?\n))|[a-zA-Z_]\w*)

I am not even going to try to figure out what part of the re triggers the excessive recursion.  Here is the source file reindent was munching on when the exception was raised.  Hopefully the bug submission process won't destroy it.  If so, let me know (skip@mojam.com) and I'll send it to you.

def dtmlfunc(**__d):
    import sys, urllib, string
    output = []
    append = output.append
    append('<!-- Generated: Wed Mar 10 12:13:08 1999 -->')
    append('\012<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> <!-- -*-html-helper -*- -->\012<HTML>\012<HEAD>\012<TITLE>Musi-Cal Search: ')
    append("""%s""" % __d['search_key'])
    append('</TITLE>\012<LINK REV="made" HREF="mailto:concertmaster@musi-cal.com">\012</HEAD>\012<BODY bgcolor="#ffffff" text="#000000" link="#CC0000" alink="#FF3300" vlink="#330099"\012>\012\012')
    append("""%s""" % __d['banner'])
    append('\012\012<H2 align="center">Musi-Cal Search Response</H2>\012\012')
    if __d['repeat_msg']:
        append('\012  ')
        append("""%s""" % __d['repeat_msg'])
        append('\012  <hr>\012')
    append('\012\012')
    if __d['entries']:
        append('\012\012    ')
        if __d['indirect']:
            append('\012      <P>\012      You can invoke this search using the following URL.\012      Why not save it for future reference?\012      <p align=center><code>http://')
            append("""%s""" % __d['servername'])
            append('/cgi-bin/event-search?')
            append("""%s""" % __d['query_string'])
            append('</code></p>\012    ')
        append('\012    \012    <p>\012    Click <img src="http://www.musi-cal.com/icons/vdb10.gif" alt="[VDB]"> to look up venue information.<br>\012    ')
        if __d['next']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['next'])
            append('">[Next Page]</a>\012    </font>\012    ')
        append('\012    ')
        if __d['prev']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['prev'])
            append('">[Previous Page]</a><br>\012    </font>\012    ')
        else:
            append('\012      ')
            if __d['next']:
                append('<br>')
            append('\012    ')
        append('\012\012    <TABLE border=0 cellspacing="5" cellpadding="0" width="100%">\012\012    ')
        __i_entries = -1
        for __elt_entries in __d['entries']:
            __i_entries = __i_entries + 1
            append('\012\012\011<tr valign=middle>\012\012\011')
            if __d['editor']:
                append('\012\011  <TD><A href="http://')
                append("""%s""" % __d['servername'])
                append('/cgi-bin/edit-entry?editor=')
                try: append(urllib.quote(__d['editor']))
                except: append(__d['editor'].urllib.quote())
                append('&key=')
                append("""%s""" % __elt_entries['key'])
                append('">[Edit]</A><BR><A href="http://')
                append("""%s""" % __d['servername'])
                append('/cgi-bin/edit-entry?editor=')
                try: append(urllib.quote(__d['editor']))
                except: append(__d['editor'].urllib.quote())
                append('&key=')
                append("""%s""" % __elt_entries['key'])
                append('&zap=1">[Delete]</A>\012\011  <br><font size="-1">Submitter: ')
                try: append(get_email(__elt_entries))
                except: append(__elt_entries.get_email())
                append('</font>\012\011')
            else:
                append('\012\011  ')
                if __d['show_vcal']:
                    append('<TD><A href="http://')
                    append("""%s""" % __d['servername'])
                    append('/cgi-bin/gencal?type=vCalendar&key=')
                    append("""%s""" % __elt_entries['key'])
                    append('"><IMG SRC="/images/vcal.gif" ALIGN="top" ALT="vCal" width="16" height="16" border="0"></A>')
                append('\012\011')
            append('\012\012    ')
            try: append(html(__elt_entries))
            except: append(__elt_entries.html())
            append('\012\012    ')
            if (__i_entries == 0):
                append('\012\011')
                if __d['display_static']:
                    append('\012\011<td width="25%" valign=top rowspan=')
                    append("""%s""" % len(__d['entries']))
                    append('>\012\011    ')
                    if __d['static_info']:
                        append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><font size="+1"><a name="staticinfo">Notes Index</a></font></th></tr>\012\011\011  </table>\012\012\011\011')
                        if __d['stperformers']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stperf">Performers</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stperformers'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stcontributors']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th>Contributors</th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stcontributors'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stvenues']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stven">Venues</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stvenues'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stevents']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stev">Events</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stevents'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stcities']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stcity">Cities</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stcities'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011<font size="-1">You can <strong><a\012\011\011href="http://www.musi-cal.com/addstatic.shtml">add</a></strong> or\012\011\011<strong><a href="http://www.musi-cal.com/editstatic.shtml">edit</a></strong>\012\011\011Notes Index items too!</font>\012\012\011    ')
                    append('\012\011    <p>\012\011    <a href="http://www.musi-cal.com/cgi-bin/redirect/http%3a//www.amazon.com/exec/obidos/redirect-home/musical">\012\011    <img src="http://www.musi-cal.com/icons/amzn-assoc.gif" border="0" alt="In Association with Amazon.com"></a> \012\011</td>\012\011')
                append('\012    ')
            append('\012\012    ')
        append('\012\012    </TABLE>\012\012    ')
        if __d['next']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['next'])
            append('">[Next Page]</a>\012    </font>\012    ')
        append('\012    ')
        if __d['prev']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['prev'])
            append('">[Previous Page]</a><br>\012    </font>\012    ')
        else:
            append('\012      ')
            if __d['next']:
                append('<br>')
            append('\012    ')
        append('\012\012    <P>Check with venues before making plans to attend listed events.\012\012    <P>If you notice any errors, <A\012    href="mailto:concertmaster@musi-cal.com">please let us know</A> so we can\012    correct them.\012\012')
    else:
        append('\012\012    ')
        if __d['searchbyperformer']:
            append('\012      <p>We were not able to find any matches to your search.  It\'s possible\012      the artist you were searching for is not on tour or that we don\'t\012      currently have their dates in our database. You might also try <a\012      href="http://')
            append("""%s""" % __d['servername'])
            append('/cgi-bin/list-perf">browsing by performer</a>\012      in case you\'ve misspelled their name.\012      If you know of a possible source for their concert schedule,\012      <a href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\012      ')
            if __d['stperformers']:
                append('\012\011<table width="100%" cellpadding=2>\012\011<tr><th><a name="stperf">Performers</a></th></tr>\012\011<tr><td textcolor="black" bgcolor="white">\012\011  <font size="-1">\012\011  ')
                append("""%s""" % __d['stperformers'])
                append('\012\011  </font>\012\011  </td></tr>\012\011</table>\012     ')
            append('\012\012   ')
        else:
            append('\012      ')
            if __d['searchbyvenue']:
                append('\012\011<p>We were not able to find any matches to your search.  Venue\012\011names can often spelled several different ways.  You might try\012\011searching for just a single word in the venue\'s name, such as\012\011<strong>Passim</strong> instead of <strong>Club Passim</strong>.\012\011Also, some venues, such as church-sponsored coffeehouses, may\012\011be listed either under the name of the coffeehouse or the name\012\011of the hosting venue.\012\011We may also not have their schedule in our database.\012\011If you know of a possible source for their concert schedule,\012\011<a href="mailto:concertmaster@musi-cal.com">let us know</a>.\012      ')
            else:
                append('\012\011')
                if __d['searchbyevent']:
                    append('\012\011  <p>We were not able to find any matches to your search.\012\011  If you know of a possible source for event schedules,\012\011  <a href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\011')
                else:
                    append('\012\011  ')
                    if __d['searchbylocation']:
                        append('\012      <p>We were not able to find any matches to your search.\012      Please check that the city, state and country names are\012      spelled or abbreviated properly.  You might also try <a\012      href="http://')
                        append("""%s""" % __d['servername'])
                        append('/index-geog.shtml">browsing by location</a>\012      in case you misspelled the name. If you know of a\012      possible source of concert schedules for this region, <a\012      href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\011  ')
                    else:
                        append('\012      <p>We were not able to find any matches to your search.\012      If you know of a possible source of concert schedules\012      that would fill a hole in our database, <a\012      href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\011  ')
                    append('\012\011')
                append('\012      ')
            append('\012    ')
        append('\012\012')
    append('\012\012<P ALIGN="center"><CENTER>\012<p>\012<FORM METHOD="GET" ACTION="http://')
    append("""%s""" % __d['servername'])
    append('/cgi-bin/simple-search">\012<input type=radio name="key" value="performer">performer\012<input type=radio checked name="key" value="city">city\012<input type=radio name="key" value="venue">venue\012<input type=radio name="key" value="event">event<br>\012Search for: <INPUT TYPE="text" NAME="value">\012<input type="submit" value="OK">\012<br>')
    append("""%s""" % __d['survey'])
    append('\012</FORM></CENTER>\012\012\012<p align=center>\012<strong><font size="-1"><a href="/index-contribute.shtml"\012onMouseOver="window.status=\'Add events or Notes Index entries to the database\'; return true">Contribute</a> | <a href="/index-search.shtml"\012onMouseOver="window.status=\'Search the database in several ways\'; return true">Search</a> | <a href="/index-sponsor.shtml"\012onMouseOver="window.status=\'Advertise in Musi-Cal!\'; return true">Advertise</a> | <a href="/index-contents.shtml"\012onMouseOver="window.status=\'Let your mousey to the walking...\';return true">Contents</a> | <a href="/index-learn.shtml"\012onMouseOver="window.status=\'Stuck? Get help here...\'; return true">Help</a> | <a href="/Faq.shtml"\012onMouseOver="window.status=\'You got questions? We got answers...\'; return true">FAQ</a></font></strong>\012\012\012<p align=center>\012<A HREF="http://www.musi-cal.com/"><IMG border=0 WIDTH=23 HEIGHT=33 SRC="http://www.musi-cal.com/icons/not!
e.gif" ALT="[Musi-Cal Home Page]"></A>\012\012<font size="-1"><a href="mailto:concertmaster@musi-cal.com">Contact Us!</a><br><em>Copyright &#169; 1994-1999, Automatrix, Inc.</em>\012</font>\012\012\012\012</BODY>\012</HTML>\012')
    return string.join(output, '')


Follow-Ups:

Date: 2000-Oct-05 07:54
By: gvanrossum

Comment:
After 2.0 final is released.
-------------------------------------------------------

Date: 2000-Oct-05 15:26
By: tim_one

Comment:
Changed Category to Library, Summary to get "reindent" out of it, Group to Platform-specific, assigned to /F, and raised the Priority.

Skip, tell us which platform you're using.  It doesn't fail on Windows.  Also confirm that this is purely a problem with tokenize.py (e.g., does your test program also fail when run thru tabnanny.py, and/or checkappend.py?).

Since it doesn't fail for me, I can't whittle it down.  Strongly *suspect* it's due to your long string literals.  tokenize.py uses naive regexps for matching string literals, with bad performance characteristics.  If I were on a platform that failed, I'd

a) First whittle this down to a one-liner (pick on the line with the longest string literal).

b) Replace tokenize.py's string-literal regexps with the ones IDLE uses (which worked fine even on multimegabyte string literals, & much faster, in pre).

That wouldn't solve the underlying recursion limit problem, but would make it much harder to provoke.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116136&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 01:37:15 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 17:37:15 -0700
Subject: [Python-bugs-list] [Bug #115831] 0.0**-2.0 returns "inf" instead of raising ValueError
Message-ID: <200010060037.RAA13485@delerium.i.sourceforge.net>

Bug #115831, was updated on 2000-Oct-02 03:43
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Summary: 0.0**-2.0 returns "inf" instead of raising ValueError

Details: 0.0**(-2.5) correctly raises "ValueError: 0.0 to a negative power", but
0.0**(-2.0) or 0.0**(-2) returns "inf", instead of raising the same exception.
Something wrong here?

0**0 (integer or float) does return 1 which is correct limiting value.

[Reported to me by William Park]

Follow-Ups:

Date: 2000-Oct-03 02:53
By: ping

Comment:
Hi.  I just submitted patch 101751 to address this.
Hope this helps.
-------------------------------------------------------

Date: 2000-Oct-05 17:37
By: tim_one

Comment:
Fixed and Closed.  Checkin comment:

SF bug 115831 and Ping's SF patch 101751, 0.0**-2.0 returns inf rather than raise ValueError.  Checked in the patch as far as it went, but also changed all of ints, longs and floats to raise ZeroDivisionError instead when raising 0 to a negative number.  This is what 754-inspired stds require, as the " true result" is an infinity obtained from finite operands, i.e. it's a singularity. Also changed float pow to not be so timid about using its square-and-multiply algorithm.  Note that what math.pow does is unrelated to what builtin pow does, and will still vary by platform.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115831&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 01:39:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 17:39:54 -0700
Subject: [Python-bugs-list] [Bug #110677] PRIVATE: various minor Tkinter things (PR#388)
Message-ID: <200010060039.RAA21910@bush.i.sourceforge.net>

Bug #110677, was updated on 2000-Jul-31 14:13
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: PRIVATE: various minor Tkinter things (PR#388)

Details: Jitterbug-Id: 388
Submitted-By: markus.oberhumer@jk.uni-linz.ac.at
Date: Wed,  5 Jul 2000 09:38:11 -0400 (EDT)
Version: python CVS
OS: all


Tkinter.Wm.wm_state() lacks a missing "newstate=None" optional parameter.

Tkinter.Text lacks some important methods: [xy]view_moveto, [xy]view_scroll

Canvas.CanvasItem & Canvas.Group:
  - bind lacks an optional "add" param
  - unbind lacks an optional "funcid" param
  - tkraise/lower should call self.canvas.tag_XXXX
  - bbox() return value is inconsistent with Canvas.bbox()



====================================================================
Audit trail:
Tue Jul 11 08:24:23 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-09 12:17
By: effbot

Comment:
the first two items are fixed.  I'll look at the Canvas.py stuff later.
-------------------------------------------------------

Date: 2000-Sep-30 21:21
By: gvanrossum

Comment:
Later being when?
-------------------------------------------------------

Date: 2000-Oct-03 08:22
By: gvanrossum

Comment:
I'll do this so Fredrik can work on SRE.
-------------------------------------------------------

Date: 2000-Oct-05 17:39
By: gvanrossum

Comment:
Fixed the remaining items, *except* bbox() -- this would change the API and it's better not to break existing code.

I've marked this module as obsolete now; it really shouldn't be used for new projects! It's better to go directly with the Tkinter.Canvas class.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110677&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 02:45:15 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 18:45:15 -0700
Subject: [Python-bugs-list] [Bug #116136] sre recursion limit hit in tokenize.py
Message-ID: <200010060145.SAA24260@bush.i.sourceforge.net>

Bug #116136, was updated on 2000-Oct-05 07:21
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: sre recursion limit hit in tokenize.py

Details: While running Tim Peters' new reindent script over my code,
I received the following traceback:

checking ./dtcout.py ...
Traceback (most recent call last):
  File "/usr/local/bin/reindent", line 258, in ?
    main()
  File "/usr/local/bin/reindent", line 65, in main
    check(arg)
  File "/usr/local/bin/reindent", line 77, in check
    check(fullname)
  File "/usr/local/bin/reindent", line 90, in check
    if r.run():
  File "/usr/local/bin/reindent", line 135, in run
    tokenize.tokenize(self.getline, self.tokeneater)
  File "/usr/local/lib/python2.0/tokenize.py", line 152, in tokenize
    pseudomatch = pseudoprog.match(line, pos)
RuntimeError: maximum recursion limit exceeded

The pattern compiled into pseudoprog is

[ \f\t]*((\\\r?\n|#[^\r\n]*|([rR]?'''|[rR]?"""))|((0[jJ]|[1-9]\d*[jJ]|((\d+\.\d*|\.\d+)([eE][-+]?\d+)?|[1-9]\d*[eE][-+]?\d+)[jJ])|((\d+\.\d*|\.\d+)([eE][-+]?\d+)?|[1-9]\d*[eE][-+]?\d+)|(0[xX][\da-fA-F]*[lL]?|0[0-7]*[lL]?|[1-9]\d*[lL]?))|((\+=|\-=|\*=|%=|/=|\*\*=|&=|\|=|\^=|>>=|<<=|\+|\-|\*\*|\*|\^|~|/|%|&|\||<<|>>|==|<=|<>|!=|>=|=|<|>)|[][(){}]|(\r?\n|[:;.,`]))|([rR]?'(\\.|[^\n'\\])*('|\\\r?\n)|[rR]?"(\\.|[^\n"\\])*("|\\\r?\n))|[a-zA-Z_]\w*)

I am not even going to try to figure out what part of the re triggers the excessive recursion.  Here is the source file reindent was munching on when the exception was raised.  Hopefully the bug submission process won't destroy it.  If so, let me know (skip@mojam.com) and I'll send it to you.

def dtmlfunc(**__d):
    import sys, urllib, string
    output = []
    append = output.append
    append('<!-- Generated: Wed Mar 10 12:13:08 1999 -->')
    append('\012<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> <!-- -*-html-helper -*- -->\012<HTML>\012<HEAD>\012<TITLE>Musi-Cal Search: ')
    append("""%s""" % __d['search_key'])
    append('</TITLE>\012<LINK REV="made" HREF="mailto:concertmaster@musi-cal.com">\012</HEAD>\012<BODY bgcolor="#ffffff" text="#000000" link="#CC0000" alink="#FF3300" vlink="#330099"\012>\012\012')
    append("""%s""" % __d['banner'])
    append('\012\012<H2 align="center">Musi-Cal Search Response</H2>\012\012')
    if __d['repeat_msg']:
        append('\012  ')
        append("""%s""" % __d['repeat_msg'])
        append('\012  <hr>\012')
    append('\012\012')
    if __d['entries']:
        append('\012\012    ')
        if __d['indirect']:
            append('\012      <P>\012      You can invoke this search using the following URL.\012      Why not save it for future reference?\012      <p align=center><code>http://')
            append("""%s""" % __d['servername'])
            append('/cgi-bin/event-search?')
            append("""%s""" % __d['query_string'])
            append('</code></p>\012    ')
        append('\012    \012    <p>\012    Click <img src="http://www.musi-cal.com/icons/vdb10.gif" alt="[VDB]"> to look up venue information.<br>\012    ')
        if __d['next']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['next'])
            append('">[Next Page]</a>\012    </font>\012    ')
        append('\012    ')
        if __d['prev']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['prev'])
            append('">[Previous Page]</a><br>\012    </font>\012    ')
        else:
            append('\012      ')
            if __d['next']:
                append('<br>')
            append('\012    ')
        append('\012\012    <TABLE border=0 cellspacing="5" cellpadding="0" width="100%">\012\012    ')
        __i_entries = -1
        for __elt_entries in __d['entries']:
            __i_entries = __i_entries + 1
            append('\012\012\011<tr valign=middle>\012\012\011')
            if __d['editor']:
                append('\012\011  <TD><A href="http://')
                append("""%s""" % __d['servername'])
                append('/cgi-bin/edit-entry?editor=')
                try: append(urllib.quote(__d['editor']))
                except: append(__d['editor'].urllib.quote())
                append('&key=')
                append("""%s""" % __elt_entries['key'])
                append('">[Edit]</A><BR><A href="http://')
                append("""%s""" % __d['servername'])
                append('/cgi-bin/edit-entry?editor=')
                try: append(urllib.quote(__d['editor']))
                except: append(__d['editor'].urllib.quote())
                append('&key=')
                append("""%s""" % __elt_entries['key'])
                append('&zap=1">[Delete]</A>\012\011  <br><font size="-1">Submitter: ')
                try: append(get_email(__elt_entries))
                except: append(__elt_entries.get_email())
                append('</font>\012\011')
            else:
                append('\012\011  ')
                if __d['show_vcal']:
                    append('<TD><A href="http://')
                    append("""%s""" % __d['servername'])
                    append('/cgi-bin/gencal?type=vCalendar&key=')
                    append("""%s""" % __elt_entries['key'])
                    append('"><IMG SRC="/images/vcal.gif" ALIGN="top" ALT="vCal" width="16" height="16" border="0"></A>')
                append('\012\011')
            append('\012\012    ')
            try: append(html(__elt_entries))
            except: append(__elt_entries.html())
            append('\012\012    ')
            if (__i_entries == 0):
                append('\012\011')
                if __d['display_static']:
                    append('\012\011<td width="25%" valign=top rowspan=')
                    append("""%s""" % len(__d['entries']))
                    append('>\012\011    ')
                    if __d['static_info']:
                        append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><font size="+1"><a name="staticinfo">Notes Index</a></font></th></tr>\012\011\011  </table>\012\012\011\011')
                        if __d['stperformers']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stperf">Performers</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stperformers'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stcontributors']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th>Contributors</th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stcontributors'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stvenues']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stven">Venues</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stvenues'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stevents']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stev">Events</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stevents'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stcities']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stcity">Cities</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stcities'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011<font size="-1">You can <strong><a\012\011\011href="http://www.musi-cal.com/addstatic.shtml">add</a></strong> or\012\011\011<strong><a href="http://www.musi-cal.com/editstatic.shtml">edit</a></strong>\012\011\011Notes Index items too!</font>\012\012\011    ')
                    append('\012\011    <p>\012\011    <a href="http://www.musi-cal.com/cgi-bin/redirect/http%3a//www.amazon.com/exec/obidos/redirect-home/musical">\012\011    <img src="http://www.musi-cal.com/icons/amzn-assoc.gif" border="0" alt="In Association with Amazon.com"></a> \012\011</td>\012\011')
                append('\012    ')
            append('\012\012    ')
        append('\012\012    </TABLE>\012\012    ')
        if __d['next']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['next'])
            append('">[Next Page]</a>\012    </font>\012    ')
        append('\012    ')
        if __d['prev']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['prev'])
            append('">[Previous Page]</a><br>\012    </font>\012    ')
        else:
            append('\012      ')
            if __d['next']:
                append('<br>')
            append('\012    ')
        append('\012\012    <P>Check with venues before making plans to attend listed events.\012\012    <P>If you notice any errors, <A\012    href="mailto:concertmaster@musi-cal.com">please let us know</A> so we can\012    correct them.\012\012')
    else:
        append('\012\012    ')
        if __d['searchbyperformer']:
            append('\012      <p>We were not able to find any matches to your search.  It\'s possible\012      the artist you were searching for is not on tour or that we don\'t\012      currently have their dates in our database. You might also try <a\012      href="http://')
            append("""%s""" % __d['servername'])
            append('/cgi-bin/list-perf">browsing by performer</a>\012      in case you\'ve misspelled their name.\012      If you know of a possible source for their concert schedule,\012      <a href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\012      ')
            if __d['stperformers']:
                append('\012\011<table width="100%" cellpadding=2>\012\011<tr><th><a name="stperf">Performers</a></th></tr>\012\011<tr><td textcolor="black" bgcolor="white">\012\011  <font size="-1">\012\011  ')
                append("""%s""" % __d['stperformers'])
                append('\012\011  </font>\012\011  </td></tr>\012\011</table>\012     ')
            append('\012\012   ')
        else:
            append('\012      ')
            if __d['searchbyvenue']:
                append('\012\011<p>We were not able to find any matches to your search.  Venue\012\011names can often spelled several different ways.  You might try\012\011searching for just a single word in the venue\'s name, such as\012\011<strong>Passim</strong> instead of <strong>Club Passim</strong>.\012\011Also, some venues, such as church-sponsored coffeehouses, may\012\011be listed either under the name of the coffeehouse or the name\012\011of the hosting venue.\012\011We may also not have their schedule in our database.\012\011If you know of a possible source for their concert schedule,\012\011<a href="mailto:concertmaster@musi-cal.com">let us know</a>.\012      ')
            else:
                append('\012\011')
                if __d['searchbyevent']:
                    append('\012\011  <p>We were not able to find any matches to your search.\012\011  If you know of a possible source for event schedules,\012\011  <a href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\011')
                else:
                    append('\012\011  ')
                    if __d['searchbylocation']:
                        append('\012      <p>We were not able to find any matches to your search.\012      Please check that the city, state and country names are\012      spelled or abbreviated properly.  You might also try <a\012      href="http://')
                        append("""%s""" % __d['servername'])
                        append('/index-geog.shtml">browsing by location</a>\012      in case you misspelled the name. If you know of a\012      possible source of concert schedules for this region, <a\012      href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\011  ')
                    else:
                        append('\012      <p>We were not able to find any matches to your search.\012      If you know of a possible source of concert schedules\012      that would fill a hole in our database, <a\012      href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\011  ')
                    append('\012\011')
                append('\012      ')
            append('\012    ')
        append('\012\012')
    append('\012\012<P ALIGN="center"><CENTER>\012<p>\012<FORM METHOD="GET" ACTION="http://')
    append("""%s""" % __d['servername'])
    append('/cgi-bin/simple-search">\012<input type=radio name="key" value="performer">performer\012<input type=radio checked name="key" value="city">city\012<input type=radio name="key" value="venue">venue\012<input type=radio name="key" value="event">event<br>\012Search for: <INPUT TYPE="text" NAME="value">\012<input type="submit" value="OK">\012<br>')
    append("""%s""" % __d['survey'])
    append('\012</FORM></CENTER>\012\012\012<p align=center>\012<strong><font size="-1"><a href="/index-contribute.shtml"\012onMouseOver="window.status=\'Add events or Notes Index entries to the database\'; return true">Contribute</a> | <a href="/index-search.shtml"\012onMouseOver="window.status=\'Search the database in several ways\'; return true">Search</a> | <a href="/index-sponsor.shtml"\012onMouseOver="window.status=\'Advertise in Musi-Cal!\'; return true">Advertise</a> | <a href="/index-contents.shtml"\012onMouseOver="window.status=\'Let your mousey to the walking...\';return true">Contents</a> | <a href="/index-learn.shtml"\012onMouseOver="window.status=\'Stuck? Get help here...\'; return true">Help</a> | <a href="/Faq.shtml"\012onMouseOver="window.status=\'You got questions? We got answers...\'; return true">FAQ</a></font></strong>\012\012\012<p align=center>\012<A HREF="http://www.musi-cal.com/"><IMG border=0 WIDTH=23 HEIGHT=33 SRC="http://www.musi-cal.com/icons/not!
e.gif" ALT="[Musi-Cal Home Page]"></A>\012\012<font size="-1"><a href="mailto:concertmaster@musi-cal.com">Contact Us!</a><br><em>Copyright &#169; 1994-1999, Automatrix, Inc.</em>\012</font>\012\012\012\012</BODY>\012</HTML>\012')
    return string.join(output, '')


Follow-Ups:

Date: 2000-Oct-05 07:54
By: gvanrossum

Comment:
After 2.0 final is released.
-------------------------------------------------------

Date: 2000-Oct-05 15:26
By: tim_one

Comment:
Changed Category to Library, Summary to get "reindent" out of it, Group to Platform-specific, assigned to /F, and raised the Priority.

Skip, tell us which platform you're using.  It doesn't fail on Windows.  Also confirm that this is purely a problem with tokenize.py (e.g., does your test program also fail when run thru tabnanny.py, and/or checkappend.py?).

Since it doesn't fail for me, I can't whittle it down.  Strongly *suspect* it's due to your long string literals.  tokenize.py uses naive regexps for matching string literals, with bad performance characteristics.  If I were on a platform that failed, I'd

a) First whittle this down to a one-liner (pick on the line with the longest string literal).

b) Replace tokenize.py's string-literal regexps with the ones IDLE uses (which worked fine even on multimegabyte string literals, & much faster, in pre).

That wouldn't solve the underlying recursion limit problem, but would make it much harder to provoke.
-------------------------------------------------------

Date: 2000-Oct-05 18:45
By: montanaro

Comment:
Platform: Mandrake Linux 7.1
Python: latest CVS sources
One liner that fails is at

    http://www.musi-cal.com/~skip/srelimit.py

That fails when run through tabnanny or reindent

I can't see how to replace the tokenize string re's with IDLE's.  reindent and tabnanny both barf on

    pseudomatch = pseudoprog.match(line, pos)

As far as I can tell, PseudoToken (which is the re compiled into pseudoprog) doesn't appear to have much to do with matching strings other than recognizing the start of a triple-quoted string, which the problematic source file doesn't contain.



-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116136&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 03:00:15 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 19:00:15 -0700
Subject: [Python-bugs-list] [Bug #113797] Build problems on Reliant Unix
Message-ID: <200010060200.TAA24815@bush.i.sourceforge.net>

Bug #113797, was updated on 2000-Sep-07 07:33
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: Later
Bug Group: Platform-specific
Priority: 1
Summary: Build problems on Reliant Unix

Details: - the linker requires the options '-W1 -Blargedynsym', otherwise, Python's global functions and variables are not visible to external modules

- when building --with-threads, the linker requires the option -Kpthread

- mmapmodule.o requires a special library

Python version: 2.0b1

compiler version:CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000
CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000


Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 13:45
By: fdrake

Comment:
We need to know the output of "uname -s" and "uname -r" for this system.  (If "uname -r" reports an error, please try "uname -v".)

Are you willing to test a modified configure script on this platform?

What additional library is required for the mmap module?
-------------------------------------------------------

Date: 2000-Sep-12 21:59
By: fdrake

Comment:
Received the following response from Daniel Dittmar <ddittmar@users.sourceforge.net>:

> We need to know the output of "uname -s" and "uname -r" 
> for this system.  (If "uname -r" reports an error, please 
> try "uname -v".)

uname -s
ReliantUNIX-N

uname -r
5.45


> Are you willing to test a modified configure script on
> this platform?

sure.

> What additional library is required for the mmap module?

The man page states -lucb. This didn't work on my machine 
as the BSD compatibility layer is not active. I tell you 
more as soon as I know how to activate it.

***********

Another problem: to detect pthreads, the compiler must be 
called with -Kpthread. Otherwise, pthread.h goes into a 
branch where it tries to include a non existent header, 
fails, and configure reports 'no pthreads'.

Daniel

-------------------------------------------------------

Date: 2000-Sep-15 11:57
By: fdrake

Comment:
For the mmap issue, I've added a comment to Modules/Setup.in to let installers know that -lucb may be needed.  In revision 1.110.
-------------------------------------------------------

Date: 2000-Sep-15 13:37
By: fdrake

Comment:
I'm sending a modified version of  the configure script to Daniel Dittmar to test for the first two points in this bug report.
-------------------------------------------------------

Date: 2000-Sep-21 08:17
By: fdrake

Comment:
Sent query to Daniel Dittmar asking if he's had a chance to test the revised configure script I sent.
-------------------------------------------------------

Date: 2000-Sep-21 08:46
By: fdrake

Comment:
Received message from Daniel indicating he should get a chace to test the changes this weekend, so it should be available for 2.0b2.
-------------------------------------------------------

Date: 2000-Sep-24 05:46
By: ddittmar

Comment:
- configure --without-threads works with the configure patch Revision 1.158

- mmapmodule would work if it includes the lines

#include <unistd.h>

static int
getpagesize (void)
{
    return sysconf (_SC_PAGESIZE);
}

This would be the preferred way as using the BSD compatibility with -lucb is discouraged.

It requires chages to configure (has_pagesize, has_sysconf_sc_pagesize)

- configure --with-threads doesn't build yet, keeping contact with fdrake
-------------------------------------------------------

Date: 2000-Sep-25 08:10
By: fdrake

Comment:
Fix to make sure the public API properly exposed to extensions checked in as configure.in revision 1.155.  The rest of these issues can be dealt with in 2.0 final.
-------------------------------------------------------

Date: 2000-Sep-28 10:36
By: fdrake

Comment:
I've sent a patch for the mmap module to Daniel to test on Reliant UNIX; the patch should remove the need to link to libucb on that platform (the only platform that needed that as far as we know).
-------------------------------------------------------

Date: 2000-Oct-01 09:34
By: ddittmar

Comment:
The patch for the mmap module works on 2.0b2
-------------------------------------------------------

Date: 2000-Oct-01 10:51
By: fdrake

Comment:
mmap patch checked in as Modules/mmapmodule.c revision 2.24.
-------------------------------------------------------

Date: 2000-Oct-02 08:30
By: fdrake

Comment:
Sent another version of the configure script to Daniel Dittmar for testing the thread support.  I think this is the last remaining problem listed in this bug report.
-------------------------------------------------------

Date: 2000-Oct-03 09:16
By: fdrake

Comment:
Daniel Dittmar's response:
- the configure script works, except that the correct option is '-Kpthread'
(you mistyped '-Lpthread'

- there's a compilation error in thread_pthread.h:181: the expression
'(long) threadid' is not valid. The definition of pthread_t is 

typedef struct PTHREAD_HANDLE_T {
    void               *field1;
    short int           field2;
    short int           field3;
    } pthread_handle_t;

typedef pthread_handle_t pthread_t;

so I doubt that the alternative 

return (long) *(long *) &threadid

is valid. I could compile it with this version, but I doubt it's returning a
meaningful thread id. Is there a test for the thread module?

I'm away for the rest of the week, so I couldn't test anything for the
Wednesday date.

- for your information, I'm including the results of 'make test', at least
the failed ones:
test test_fork1 crashed -- exceptions.OSError: [Errno 4] Interrupted system
call
test test_popen2 crashed -- exceptions.IOError: [Errno 4] Interrupted system
call
test_signal
Trace/Breakpoint Trap - core dumped
make: *** Error code 133 (ignored)
make: *** Error code 133 (bu21) (ignored)

These test leave a few python processes around.

I'll probably look into this when I return.

Daniel

-------------------------------------------------------

Date: 2000-Oct-03 09:22
By: fdrake

Comment:
I've sent a note to Daniel asking for the config.h and config.log files generated by configure.  There's a real problem with the way we're creating thread identifiers; casting to a long just isn't sufficient.

It might be good to know what kind of processor is on the machine.
-------------------------------------------------------

Date: 2000-Oct-05 19:00
By: fdrake

Comment:
This won't be resolved for Python 2.0.  There's enough that would be effected by revising the thread identification code that we don't want to destabilize the sources at this point.

We should be able to resolve this for Python 2.1.  I've added a comment about this to the platform notes section of the README file (revision 1.102) to alert the reader to this situation.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113797&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 05:11:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 21:11:00 -0700
Subject: [Python-bugs-list] [Bug #110843] Low FD_SETSIZE limit on Win32 (PR#41)
Message-ID: <200010060411.VAA20990@delerium.i.sourceforge.net>

Bug #110843, was updated on 2000-Aug-01 14:15
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 3
Summary: Low FD_SETSIZE limit on Win32 (PR#41)

Details: Jitterbug-Id: 41
Submitted-By: brian@digicool.com
Date: Fri, 30 Jul 1999 10:10:49 -0400 (EDT)
Version: 1.5.2
OS: NT


It appears that win32 has a default limit of 64 descriptors that 
can be handed to the select() function. This is pretty low for
any serious async servers, and causes them to raise lots of errors
under very moderate loads.

We at DC ran into this using Medusa as a basis for ZServer, which
serves Zope sites. It turns out that you can actually add a define
when compiling the python15.dll for windows to bump the default
fd limit to a more reasonable level.

The approach _I_ took was to add the define: FD_SETSIZE=1024
to the preprocessor options in the MSVC project settings for
python15.dll, though I imagine you could also roll the define
into config.h or something (so long as it's defined before
windows.h or any of the select / socket include files are
referenced). It would make life much easier for win32 server
developers if this define could find its way into the next
official python release :^)

Thanks!


Brian Lloyd        brian@digicool.com
Software Engineer  540.371.6909              
Digital Creations  http://www.digicool.com 




====================================================================
Audit trail:
Fri Jul 30 10:43:41 1999	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-30 23:19
By: mhammond

Comment:
I am a little worried that adding it to config.h may have side-effects when Python is embedded in other projects with their own socket config (eg, Mozilla :-)

Now that socket and select are external .pyd modules, will it be sufficient to only add it to these extension modules?
-------------------------------------------------------

Date: 2000-Sep-21 21:16
By: tim_one

Comment:
Changed summary to say "Win32" instead of "NT", as this is a general Win32 issue.

Mark, did you email your question directly to Brian?  (This bug got moved over from Jitterbug, so he didn't see your note otherwise.)

I certainly agree Python can't go changing the MS default value in any way visible from Python.h (which #includes config.h).
-------------------------------------------------------

Date: 2000-Oct-05 21:11
By: mhammond

Comment:
Brian has agreed to help with a specific patch that will remain local to the Python build.  Dropping priority to reflect that it wont affect most users, and wont make 2.0.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110843&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 05:47:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 21:47:35 -0700
Subject: [Python-bugs-list] [Bug #112786] Build under Cygwin fails
Message-ID: <200010060447.VAA22170@delerium.i.sourceforge.net>

Bug #112786, was updated on 2000-Aug-26 01:39
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: Build under Cygwin fails

Details: Py1.6b1
========
1) socketmodule.c -- looks for netinet/tcp.h, which does not exist on cygwin.

2) gcc   python.o \
          ../libpython1.6.a    -lm  -o python
python.o: In function `main':
/usr/local/bin/Python-1.6b1/Modules/python.c:12: undefined reference to `Py_Main


Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-13 04:13
By: gvanrossum

Comment:
I don't have cygwin. Does anyone here have cygwin? I know Tim said the cygwin installer failed for him, so he doesn't have it. Is there someone outside the PythonLabs to whom we could assign this?
-------------------------------------------------------

Date: 2000-Sep-16 01:56
By: tim_one

Comment:
A fellow named Norman mailto:nhv@yahoo.com posted to c.l.py with some evidence of real Cygwin knowledge, so I emailed him a link to this bug and asked whether he'd help out.
-------------------------------------------------------

Date: 2000-Sep-16 20:29
By: nhv

Comment:
Hi I am that fellow Norman

FYI I have been doing bi-weekly builds of the Python CVS source with the 'current' Cygwin distribution for about a year.

I sent Tim my small set of diffs

Basically threading with Cygwin Python is still broken
and dll building with Cygwin has some problems but other then that everything including tkinter works for me with very minor changes.

FWIW We are succesfully embedding Python in PrettyPoly
http://prettypoly.sourceforge.net and I am using Cygwin
as my development enviroment for this

If helpful I can mail someone my diffs and the results of make test after each of my CVS sessions or apon request

Also FWIW I build Cygwin from source and have access to the Cygwin development team

I will help in anyway I can to make Python compile with Cygwin 'out of the box'  


Norman Vine nhv@yahoo.com

-------------------------------------------------------

Date: 2000-Sep-17 05:41
By: tim_one

Comment:
Here's the body of email from Norman:

I will certainly help in anyway that I can :-)

Below is a diff of my PY_SRC and the Python CVS at SourceForge

specifically

1) socketmodule.c -- looks for netinet/tcp.h, which does not exist on cygwin.

Cygwin does not have netinet / tcp.h
There has been some discussion about including a dummy tcp.h
into the distribution but I am noy sure that this is a standard header ?
see
http://sources.redhat.com/ml/cygwin/2000-09/msg00011.html

2) gcc python.o \
../libpython1.6.a -lm -o python
python.o: In function `main':
/usr/local/bin/Python-1.6b1/Modules/python.c:12: undefined reference to
`Py_Main

Before rerunning make after a failed build it is occasionally necessary to from top_level python_src directory it is necessary to do
% rm *.a *.o *.exe
I believe that this will solve this problem

I am working with the 2.0 srource tree though and I notice that this is reported against the 1.6 tree


IMHO the two main 'issues'  with Python and Cygwin remaining
are threads and dll support.

I am working on the dll stuff and am aware of Distutils

The thread stuff is beyond me and I could use some help.

I will gladly be a Cygwin 'tester' for Python.

and can forward Cygwin specific Python questions that
I can not answer directly to the appropriate Cygwin list(s)

Cheers

Norman


Index: _tkinter.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/_tkinter.c,v
retrieving revision 1.111
diff -r1.111 _tkinter.c
0a1
>
60,62c61,63
< #if !defined(MS_WINDOWS)
< #define HAVE_CREATEFILEHANDLER
< #endif
---
> //#if !(defined(MS_WINDOWS) || defined(__CYGWIN__))
> //#define HAVE_CREATEFILEHANDLER
> //#endif
64a66
> #undef HAVE_CREATEFILEHANDLER
71c73
< #ifdef MS_WINDOWS
---
> #if defined(MS_WINDOWS) || defined(__CYGWIN__)
Index: main.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/main.c,v
retrieving revision 1.44
diff -r1.44 main.c
11c11
< #ifdef MS_WINDOWS
---
> #if defined(MS_WINDOWS) || defined(__CYGWIN__)
187c187
< #ifdef MS_WINDOWS
---
> #if defined(MS_WINDOWS) || defined(__CYGWIN__)
209c209
< #ifdef MS_WINDOWS
---
> #if defined(MS_WINDOWS) || defined(__CYGWIN__)
Index: socketmodule.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v
retrieving revision 1.127
diff -r1.127 socketmodule.c
125c125
< #ifndef __BEOS__
---
> #if !defined(__BEOS__) && !defined(__CYGWIN__)

-------------------------------------------------------

Date: 2000-Oct-05 13:29
By: jhylton

Comment:
Can we close this bug now?

-------------------------------------------------------

Date: 2000-Oct-05 14:58
By: tim_one

Comment:
I doubt it.  These changes don't match the ones Norman posted in his other "bug" report.  Until he submits a proper context-diff patch or says "nevermind", I expect all Cygwin bugs should remain open.
-------------------------------------------------------

Date: 2000-Oct-05 21:47
By: nhv

Comment:
See patch: 101802 
Titled: Cygwin Fix -- missing tcp.h 
Filed: 2000-Oct-06 03:56 

After applying above patch
Cygwin V1.1.4 on w2k with
./configure --without-threads --with-suffix='exe --with-libm=
against CVS checkout as of 2200 EST 05 Oct

compiled and ran make test
minor problems still in 
test_poll
test_strftime
test_time

Win9X has a problem with
test_select

I believe the problems in test_poll will be fixed in the
next Cygwin release

Would you like me to submit Cygwin specific patches for
these problematical patches ??

Other then these minor points I believe that this 
Bug can be considered closed.

Norman



-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112786&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 06:40:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 5 Oct 2000 22:40:38 -0700
Subject: [Python-bugs-list] [Bug #116136] sre recursion limit hit in tokenize.py
Message-ID: <200010060540.WAA00381@bush.i.sourceforge.net>

Bug #116136, was updated on 2000-Oct-05 07:21
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: sre recursion limit hit in tokenize.py

Details: While running Tim Peters' new reindent script over my code,
I received the following traceback:

checking ./dtcout.py ...
Traceback (most recent call last):
  File "/usr/local/bin/reindent", line 258, in ?
    main()
  File "/usr/local/bin/reindent", line 65, in main
    check(arg)
  File "/usr/local/bin/reindent", line 77, in check
    check(fullname)
  File "/usr/local/bin/reindent", line 90, in check
    if r.run():
  File "/usr/local/bin/reindent", line 135, in run
    tokenize.tokenize(self.getline, self.tokeneater)
  File "/usr/local/lib/python2.0/tokenize.py", line 152, in tokenize
    pseudomatch = pseudoprog.match(line, pos)
RuntimeError: maximum recursion limit exceeded

The pattern compiled into pseudoprog is

[ \f\t]*((\\\r?\n|#[^\r\n]*|([rR]?'''|[rR]?"""))|((0[jJ]|[1-9]\d*[jJ]|((\d+\.\d*|\.\d+)([eE][-+]?\d+)?|[1-9]\d*[eE][-+]?\d+)[jJ])|((\d+\.\d*|\.\d+)([eE][-+]?\d+)?|[1-9]\d*[eE][-+]?\d+)|(0[xX][\da-fA-F]*[lL]?|0[0-7]*[lL]?|[1-9]\d*[lL]?))|((\+=|\-=|\*=|%=|/=|\*\*=|&=|\|=|\^=|>>=|<<=|\+|\-|\*\*|\*|\^|~|/|%|&|\||<<|>>|==|<=|<>|!=|>=|=|<|>)|[][(){}]|(\r?\n|[:;.,`]))|([rR]?'(\\.|[^\n'\\])*('|\\\r?\n)|[rR]?"(\\.|[^\n"\\])*("|\\\r?\n))|[a-zA-Z_]\w*)

I am not even going to try to figure out what part of the re triggers the excessive recursion.  Here is the source file reindent was munching on when the exception was raised.  Hopefully the bug submission process won't destroy it.  If so, let me know (skip@mojam.com) and I'll send it to you.

def dtmlfunc(**__d):
    import sys, urllib, string
    output = []
    append = output.append
    append('<!-- Generated: Wed Mar 10 12:13:08 1999 -->')
    append('\012<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> <!-- -*-html-helper -*- -->\012<HTML>\012<HEAD>\012<TITLE>Musi-Cal Search: ')
    append("""%s""" % __d['search_key'])
    append('</TITLE>\012<LINK REV="made" HREF="mailto:concertmaster@musi-cal.com">\012</HEAD>\012<BODY bgcolor="#ffffff" text="#000000" link="#CC0000" alink="#FF3300" vlink="#330099"\012>\012\012')
    append("""%s""" % __d['banner'])
    append('\012\012<H2 align="center">Musi-Cal Search Response</H2>\012\012')
    if __d['repeat_msg']:
        append('\012  ')
        append("""%s""" % __d['repeat_msg'])
        append('\012  <hr>\012')
    append('\012\012')
    if __d['entries']:
        append('\012\012    ')
        if __d['indirect']:
            append('\012      <P>\012      You can invoke this search using the following URL.\012      Why not save it for future reference?\012      <p align=center><code>http://')
            append("""%s""" % __d['servername'])
            append('/cgi-bin/event-search?')
            append("""%s""" % __d['query_string'])
            append('</code></p>\012    ')
        append('\012    \012    <p>\012    Click <img src="http://www.musi-cal.com/icons/vdb10.gif" alt="[VDB]"> to look up venue information.<br>\012    ')
        if __d['next']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['next'])
            append('">[Next Page]</a>\012    </font>\012    ')
        append('\012    ')
        if __d['prev']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['prev'])
            append('">[Previous Page]</a><br>\012    </font>\012    ')
        else:
            append('\012      ')
            if __d['next']:
                append('<br>')
            append('\012    ')
        append('\012\012    <TABLE border=0 cellspacing="5" cellpadding="0" width="100%">\012\012    ')
        __i_entries = -1
        for __elt_entries in __d['entries']:
            __i_entries = __i_entries + 1
            append('\012\012\011<tr valign=middle>\012\012\011')
            if __d['editor']:
                append('\012\011  <TD><A href="http://')
                append("""%s""" % __d['servername'])
                append('/cgi-bin/edit-entry?editor=')
                try: append(urllib.quote(__d['editor']))
                except: append(__d['editor'].urllib.quote())
                append('&key=')
                append("""%s""" % __elt_entries['key'])
                append('">[Edit]</A><BR><A href="http://')
                append("""%s""" % __d['servername'])
                append('/cgi-bin/edit-entry?editor=')
                try: append(urllib.quote(__d['editor']))
                except: append(__d['editor'].urllib.quote())
                append('&key=')
                append("""%s""" % __elt_entries['key'])
                append('&zap=1">[Delete]</A>\012\011  <br><font size="-1">Submitter: ')
                try: append(get_email(__elt_entries))
                except: append(__elt_entries.get_email())
                append('</font>\012\011')
            else:
                append('\012\011  ')
                if __d['show_vcal']:
                    append('<TD><A href="http://')
                    append("""%s""" % __d['servername'])
                    append('/cgi-bin/gencal?type=vCalendar&key=')
                    append("""%s""" % __elt_entries['key'])
                    append('"><IMG SRC="/images/vcal.gif" ALIGN="top" ALT="vCal" width="16" height="16" border="0"></A>')
                append('\012\011')
            append('\012\012    ')
            try: append(html(__elt_entries))
            except: append(__elt_entries.html())
            append('\012\012    ')
            if (__i_entries == 0):
                append('\012\011')
                if __d['display_static']:
                    append('\012\011<td width="25%" valign=top rowspan=')
                    append("""%s""" % len(__d['entries']))
                    append('>\012\011    ')
                    if __d['static_info']:
                        append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><font size="+1"><a name="staticinfo">Notes Index</a></font></th></tr>\012\011\011  </table>\012\012\011\011')
                        if __d['stperformers']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stperf">Performers</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stperformers'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stcontributors']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th>Contributors</th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stcontributors'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stvenues']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stven">Venues</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stvenues'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stevents']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stev">Events</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stevents'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stcities']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stcity">Cities</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stcities'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011<font size="-1">You can <strong><a\012\011\011href="http://www.musi-cal.com/addstatic.shtml">add</a></strong> or\012\011\011<strong><a href="http://www.musi-cal.com/editstatic.shtml">edit</a></strong>\012\011\011Notes Index items too!</font>\012\012\011    ')
                    append('\012\011    <p>\012\011    <a href="http://www.musi-cal.com/cgi-bin/redirect/http%3a//www.amazon.com/exec/obidos/redirect-home/musical">\012\011    <img src="http://www.musi-cal.com/icons/amzn-assoc.gif" border="0" alt="In Association with Amazon.com"></a> \012\011</td>\012\011')
                append('\012    ')
            append('\012\012    ')
        append('\012\012    </TABLE>\012\012    ')
        if __d['next']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['next'])
            append('">[Next Page]</a>\012    </font>\012    ')
        append('\012    ')
        if __d['prev']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['prev'])
            append('">[Previous Page]</a><br>\012    </font>\012    ')
        else:
            append('\012      ')
            if __d['next']:
                append('<br>')
            append('\012    ')
        append('\012\012    <P>Check with venues before making plans to attend listed events.\012\012    <P>If you notice any errors, <A\012    href="mailto:concertmaster@musi-cal.com">please let us know</A> so we can\012    correct them.\012\012')
    else:
        append('\012\012    ')
        if __d['searchbyperformer']:
            append('\012      <p>We were not able to find any matches to your search.  It\'s possible\012      the artist you were searching for is not on tour or that we don\'t\012      currently have their dates in our database. You might also try <a\012      href="http://')
            append("""%s""" % __d['servername'])
            append('/cgi-bin/list-perf">browsing by performer</a>\012      in case you\'ve misspelled their name.\012      If you know of a possible source for their concert schedule,\012      <a href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\012      ')
            if __d['stperformers']:
                append('\012\011<table width="100%" cellpadding=2>\012\011<tr><th><a name="stperf">Performers</a></th></tr>\012\011<tr><td textcolor="black" bgcolor="white">\012\011  <font size="-1">\012\011  ')
                append("""%s""" % __d['stperformers'])
                append('\012\011  </font>\012\011  </td></tr>\012\011</table>\012     ')
            append('\012\012   ')
        else:
            append('\012      ')
            if __d['searchbyvenue']:
                append('\012\011<p>We were not able to find any matches to your search.  Venue\012\011names can often spelled several different ways.  You might try\012\011searching for just a single word in the venue\'s name, such as\012\011<strong>Passim</strong> instead of <strong>Club Passim</strong>.\012\011Also, some venues, such as church-sponsored coffeehouses, may\012\011be listed either under the name of the coffeehouse or the name\012\011of the hosting venue.\012\011We may also not have their schedule in our database.\012\011If you know of a possible source for their concert schedule,\012\011<a href="mailto:concertmaster@musi-cal.com">let us know</a>.\012      ')
            else:
                append('\012\011')
                if __d['searchbyevent']:
                    append('\012\011  <p>We were not able to find any matches to your search.\012\011  If you know of a possible source for event schedules,\012\011  <a href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\011')
                else:
                    append('\012\011  ')
                    if __d['searchbylocation']:
                        append('\012      <p>We were not able to find any matches to your search.\012      Please check that the city, state and country names are\012      spelled or abbreviated properly.  You might also try <a\012      href="http://')
                        append("""%s""" % __d['servername'])
                        append('/index-geog.shtml">browsing by location</a>\012      in case you misspelled the name. If you know of a\012      possible source of concert schedules for this region, <a\012      href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\011  ')
                    else:
                        append('\012      <p>We were not able to find any matches to your search.\012      If you know of a possible source of concert schedules\012      that would fill a hole in our database, <a\012      href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\011  ')
                    append('\012\011')
                append('\012      ')
            append('\012    ')
        append('\012\012')
    append('\012\012<P ALIGN="center"><CENTER>\012<p>\012<FORM METHOD="GET" ACTION="http://')
    append("""%s""" % __d['servername'])
    append('/cgi-bin/simple-search">\012<input type=radio name="key" value="performer">performer\012<input type=radio checked name="key" value="city">city\012<input type=radio name="key" value="venue">venue\012<input type=radio name="key" value="event">event<br>\012Search for: <INPUT TYPE="text" NAME="value">\012<input type="submit" value="OK">\012<br>')
    append("""%s""" % __d['survey'])
    append('\012</FORM></CENTER>\012\012\012<p align=center>\012<strong><font size="-1"><a href="/index-contribute.shtml"\012onMouseOver="window.status=\'Add events or Notes Index entries to the database\'; return true">Contribute</a> | <a href="/index-search.shtml"\012onMouseOver="window.status=\'Search the database in several ways\'; return true">Search</a> | <a href="/index-sponsor.shtml"\012onMouseOver="window.status=\'Advertise in Musi-Cal!\'; return true">Advertise</a> | <a href="/index-contents.shtml"\012onMouseOver="window.status=\'Let your mousey to the walking...\';return true">Contents</a> | <a href="/index-learn.shtml"\012onMouseOver="window.status=\'Stuck? Get help here...\'; return true">Help</a> | <a href="/Faq.shtml"\012onMouseOver="window.status=\'You got questions? We got answers...\'; return true">FAQ</a></font></strong>\012\012\012<p align=center>\012<A HREF="http://www.musi-cal.com/"><IMG border=0 WIDTH=23 HEIGHT=33 SRC="http://www.musi-cal.com/icons/not!
e.gif" ALT="[Musi-Cal Home Page]"></A>\012\012<font size="-1"><a href="mailto:concertmaster@musi-cal.com">Contact Us!</a><br><em>Copyright &#169; 1994-1999, Automatrix, Inc.</em>\012</font>\012\012\012\012</BODY>\012</HTML>\012')
    return string.join(output, '')


Follow-Ups:

Date: 2000-Oct-05 07:54
By: gvanrossum

Comment:
After 2.0 final is released.
-------------------------------------------------------

Date: 2000-Oct-05 15:26
By: tim_one

Comment:
Changed Category to Library, Summary to get "reindent" out of it, Group to Platform-specific, assigned to /F, and raised the Priority.

Skip, tell us which platform you're using.  It doesn't fail on Windows.  Also confirm that this is purely a problem with tokenize.py (e.g., does your test program also fail when run thru tabnanny.py, and/or checkappend.py?).

Since it doesn't fail for me, I can't whittle it down.  Strongly *suspect* it's due to your long string literals.  tokenize.py uses naive regexps for matching string literals, with bad performance characteristics.  If I were on a platform that failed, I'd

a) First whittle this down to a one-liner (pick on the line with the longest string literal).

b) Replace tokenize.py's string-literal regexps with the ones IDLE uses (which worked fine even on multimegabyte string literals, & much faster, in pre).

That wouldn't solve the underlying recursion limit problem, but would make it much harder to provoke.
-------------------------------------------------------

Date: 2000-Oct-05 18:45
By: montanaro

Comment:
Platform: Mandrake Linux 7.1
Python: latest CVS sources
One liner that fails is at

    http://www.musi-cal.com/~skip/srelimit.py

That fails when run through tabnanny or reindent

I can't see how to replace the tokenize string re's with IDLE's.  reindent and tabnanny both barf on

    pseudomatch = pseudoprog.match(line, pos)

As far as I can tell, PseudoToken (which is the re compiled into pseudoprog) doesn't appear to have much to do with matching strings other than recognizing the start of a triple-quoted string, which the problematic source file doesn't contain.



-------------------------------------------------------

Date: 2000-Oct-05 22:40
By: tim_one

Comment:
Thanks, Skip!  That confirms everything I suspected.

As to the connection to strings, pseudoprog *does* try to match "the first line" of single-quoted strings (via ContStr), which in your case is your entire 1200+ character single-quoted string literal.  That's where, e.g., the

([rR]?'(\\.|[^\n'\\])*('|\\\r?\n)

alternative in your pseudoprog dump comes from, and that's a terrible (for pragmatic reasons) regexp for matching long strings.  The IDLE-like alternative would be (re.VERBOSE)

(
[rR]?
'
[^\n'\\]*
(?: \\. [^\n'\\]*)*
(?: ' | \\ \r? \n)
)

This is just a vanilla instance of Friedl's

normal* (special normal*)*

"regexp unrolling", and saves your bacon for reasons spelled out in detail in his book.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116136&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 10:11:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 02:11:39 -0700
Subject: [Python-bugs-list] [Bug #115469] test_socket hangs on Debian Linux 2.2
Message-ID: <200010060911.CAA08086@bush.i.sourceforge.net>

Bug #115469, was updated on 2000-Sep-27 01:54
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 7
Summary: test_socket hangs on Debian Linux 2.2

Details: The test runs until it prints "child connecting" and then just hangs. Pressing C-c causes a traceback that points at the
s.accept() call in line 105.

uname -a says
Linux pc-larsga 2.0.36 #2 Sun Jan 17 19:38:45 EST 1999 i686  unknown

ldd python says
libdl.so.2 => /lib/libdl.so.2 (0x4001a000)
libm.so.6 => /lib/libm.so.6 (0x4001e000)
libc.so.6 => /lib/libc.so.6 (0x4003b000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

This bug is probably related to 115221.

Follow-Ups:

Date: 2000-Sep-27 11:04
By: nascheme

Comment:
I can't reproduce this on my Debian 2.2 machine running 
Linux 2.2.16.  Which libc6 are you using (dpkg -l libc6)?  
Also, it is possible that something is wrong with the loopback network.  The output from "netstat -tnp; ifconfig lo" taken during the hang may be helpful
-------------------------------------------------------

Date: 2000-Oct-05 07:17
By: jhylton

Comment:
Lars-- Is this still a problem for you?  Can you provide any of the information Neil asked for?  If not, I think we should assume it is a Debian problem.

-------------------------------------------------------

Date: 2000-Oct-05 08:58
By: larsga

Comment:
I did a cvs update, recompile and new run of the test. It
no longer hangs for me. I have not updated the system in any way, so I can only assume that this has been fixed in some 
way.
-------------------------------------------------------

Date: 2000-Oct-05 08:59
By: larsga

Comment:
I did a cvs update, recompile and new run of the test. It
no longer hangs for me. I have not updated the system in any way, so I can only assume that this has been fixed in some 
way.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115469&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 10:55:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 02:55:42 -0700
Subject: [Python-bugs-list] [Bug #115469] test_socket hangs on Debian Linux 2.2
Message-ID: <200010060955.CAA09804@bush.i.sourceforge.net>

Bug #115469, was updated on 2000-Sep-27 01:54
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 7
Summary: test_socket hangs on Debian Linux 2.2

Details: The test runs until it prints "child connecting" and then just hangs. Pressing C-c causes a traceback that points at the
s.accept() call in line 105.

uname -a says
Linux pc-larsga 2.0.36 #2 Sun Jan 17 19:38:45 EST 1999 i686  unknown

ldd python says
libdl.so.2 => /lib/libdl.so.2 (0x4001a000)
libm.so.6 => /lib/libm.so.6 (0x4001e000)
libc.so.6 => /lib/libc.so.6 (0x4003b000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

This bug is probably related to 115221.

Follow-Ups:

Date: 2000-Sep-27 11:04
By: nascheme

Comment:
I can't reproduce this on my Debian 2.2 machine running 
Linux 2.2.16.  Which libc6 are you using (dpkg -l libc6)?  
Also, it is possible that something is wrong with the loopback network.  The output from "netstat -tnp; ifconfig lo" taken during the hang may be helpful
-------------------------------------------------------

Date: 2000-Oct-05 07:17
By: jhylton

Comment:
Lars-- Is this still a problem for you?  Can you provide any of the information Neil asked for?  If not, I think we should assume it is a Debian problem.

-------------------------------------------------------

Date: 2000-Oct-05 08:58
By: larsga

Comment:
I did a cvs update, recompile and new run of the test. It
no longer hangs for me. I have not updated the system in any way, so I can only assume that this has been fixed in some 
way.
-------------------------------------------------------

Date: 2000-Oct-05 08:59
By: larsga

Comment:
I did a cvs update, recompile and new run of the test. It
no longer hangs for me. I have not updated the system in any way, so I can only assume that this has been fixed in some 
way.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115469&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 14:01:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 06:01:38 -0700
Subject: [Python-bugs-list] [Bug #116235] module_search_path in PC/getpahp.c
Message-ID: <200010061301.GAA07640@delerium.i.sourceforge.net>

Bug #116235, was updated on 2000-Oct-06 06:01
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: module_search_path in PC/getpahp.c

Details: The trouble seems to be in getpathp.c in the "pc" directory.
If I've seen well the static char pointer: 'module_search_path',
is allocated with
module_search_path = buf = malloc(bufsz);
but never erased. 
If I'm wrong, please, explain me where is destroyed.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116235&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 14:26:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 06:26:11 -0700
Subject: [Python-bugs-list] [Bug #116236] Possible leak in pystate.c
Message-ID: <200010061326.GAA08649@delerium.i.sourceforge.net>

Bug #116236, was updated on 2000-Oct-06 06:26
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Possible leak in pystate.c

Details: Possible leak in pystate.c
It seems that head_mutex allocated with the HEAD_INIT() macro is never deleted.
Please, give me explanations...

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116236&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 14:36:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 06:36:14 -0700
Subject: [Python-bugs-list] [Bug #116237] Leak in ceval.c
Message-ID: <200010061336.GAA09081@delerium.i.sourceforge.net>

Bug #116237, was updated on 2000-Oct-06 06:36
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Leak in ceval.c

Details: Allocated 'interpreter_lock' is never deleted. I'v read the problem commented in the source code, but all the allocations "must" deleted ( in the 'init' and 'reinit' functions ). I'm sure there's always a way to do everything.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116237&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 14:56:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 06:56:18 -0700
Subject: [Python-bugs-list] [Bug #116241] Possible leak in pythonrun.c
Message-ID: <200010061356.GAA09862@delerium.i.sourceforge.net>

Bug #116241, was updated on 2000-Oct-06 06:56
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Possible leak in pythonrun.c

Details: Possible leak in pythonrun.c:
The _PyCompareState_Key PyObject pointer defined in object.h, allocated in pythonrun.c with: 
"_PyCompareState_Key = PyString_InternFromString("cmp_state");", probably is never deleted.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116241&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 15:17:41 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 07:17:41 -0700
Subject: [Python-bugs-list] [Bug #115341] Todays CVS python dumps core in gcmodule.c?!
Message-ID: <200010061417.HAA10471@delerium.i.sourceforge.net>

Bug #115341, was updated on 2000-Sep-26 01:43
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Summary: Todays CVS python dumps core in gcmodule.c?!

Details: While tracing a bug in my own code, I got a core dump from python.
Since it is extremely difficult to find out WHERE in my 58k lines of code this
happens,  I can't just make a small test case. I thought at this stage it might
be useful to report anyway.

no203[204]lehmann%3% gdb =python core        
GNU gdb 19991004
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `/usr/local/nonius/bin/python /usr/local/nonius/app/gui/to
p.py new orient x.non'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdb.so.3...done.
Reading symbols from /lib/libpthread.so.0...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libutil.so.1...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/stropmodule.so.
..done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/timemodule.so..
.done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/_tkinter.so...
done.
---Type <return> to continue, or q <return> to quit---
Reading symbols from /usr/local/nonius/lib/libBLT24.so...done.
Reading symbols from /usr/local/nonius/lib/libtk8.3.so...done.
Reading symbols from /usr/local/nonius/lib/libtcl8.3.so...done.
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/mathmodule.so..
.done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/md5module.so...
done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/multi
array.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/_nump
y.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/umath
.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/structmodule.so
...done.
Reading symbols from /usr/local/nonius/app/misc/linux/_ntoolsmodule.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/_socketmodule.s
o...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/cStringIO.so...
done.
Reading symbols from /lib/libnss_files.so.2...done.
---Type <return> to continue, or q <return> to quit---
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/lapac
k_lite.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/selectmodule.so
...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/gdbmmodule.so..
.done.
Reading symbols from /usr/lib/libgdbm.so.2...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/cPickle.so...
done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/ranli
b.so...done.
#0  update_refs (containers=0x80bfec0) at ./gcmodule.c:150
150                     gc->gc_refs = PyObject_FROM_GC(gc)->ob_refcnt;
(gdb) where
#0  update_refs (containers=0x80bfec0) at ./gcmodule.c:150
#1  0x808ae9b in collect (young=0x80bfec0, old=0x80bfecc) at ./gcmodule.c:382
#2  0x808b0cc in collect_generations () at ./gcmodule.c:488
#3  0x808b10f in _PyGC_Insert (op=0x8703824) at ./gcmodule.c:507
#4  0x807fbe4 in PyTuple_New (size=3) at tupleobject.c:87
#5  0x80561df in eval_code2 (co=0x8260518, globals=0x823fcd4, locals=0x0, 
    args=0x824d258, argcount=2, kws=0x8780190, kwcount=5, defs=0x8268f50, 
    defcount=1, owner=0x82699e4) at ceval.c:1561
#6  0x8057e3b in call_function (func=0x8269a7c, arg=0x87616cc, kw=0x87743ac)
    at ceval.c:2744
#7  0x8057a4b in PyEval_CallObjectWithKeywords (func=0x87816bc, arg=0x87616cc, 
    kw=0x87743ac) at ceval.c:2588
#8  0x806df7b in PyInstance_New (class=0x82699e4, arg=0x87616cc, kw=0x87743ac)
    at classobject.c:463
#9  0x8057b51 in call_builtin (func=0x82699e4, arg=0x87616cc, kw=0x87743ac)
    at ceval.c:2625
#10 0x8057a58 in PyEval_CallObjectWithKeywords (func=0x82699e4, arg=0x87616cc, 
    kw=0x87743ac) at ceval.c:2590
#11 0x8056bab in eval_code2 (co=0x81f0c58, globals=0x8201b1c, locals=0x0, 
    args=0x875cd8c, argcount=2, kws=0x875cd94, kwcount=0, defs=0x8201248, 
    defcount=1, owner=0x81fe94c) at ceval.c:1923
#12 0x805687c in eval_code2 (co=0x81f2de8, globals=0x8201b1c, locals=0x0, 
    args=0x866e2b0, argcount=2, kws=0x866e2b8, kwcount=0, defs=0x0, 
---Type <return> to continue, or q <return> to quit---
    defcount=0, owner=0x8201a4c) at ceval.c:1822
#13 0x805687c in eval_code2 (co=0x81ef9d0, globals=0x8201b1c, locals=0x0, 
    args=0x8203314, argcount=2, kws=0x820331c, kwcount=0, defs=0x8201098, 
    defcount=1, owner=0x81f4e8c) at ceval.c:1822
#14 0x805687c in eval_code2 (co=0x83d1d10, globals=0x83d8044, locals=0x0, 
    args=0x8202840, argcount=2, kws=0x8202848, kwcount=0, defs=0x0, 
    defcount=0, owner=0x85fc974) at ceval.c:1822
#15 0x805687c in eval_code2 (co=0x83cff98, globals=0x83d8044, locals=0x0, 
    args=0x8202068, argcount=1, kws=0x820206c, kwcount=0, defs=0x0, 
    defcount=0, owner=0x85fc974) at ceval.c:1822
#16 0x805687c in eval_code2 (co=0x83af368, globals=0x83b2574, locals=0x0, 
    args=0x86134f0, argcount=2, kws=0x0, kwcount=0, defs=0x83b2120, 
    defcount=1, owner=0x83c8b8c) at ceval.c:1822
#17 0x8057e3b in call_function (func=0x83bcc7c, arg=0x860fcac, kw=0x0)
    at ceval.c:2744
#18 0x8057a4b in PyEval_CallObjectWithKeywords (func=0x8203194, arg=0x860fcac, 
    kw=0x0) at ceval.c:2588
#19 0x806df7b in PyInstance_New (class=0x85fc974, arg=0x860fcac, kw=0x0)
    at classobject.c:463
#20 0x8057b51 in call_builtin (func=0x85fc974, arg=0x860fcac, kw=0x0)
    at ceval.c:2625
#21 0x8057a58 in PyEval_CallObjectWithKeywords (func=0x85fc974, arg=0x860fcac, 
    kw=0x0) at ceval.c:2590
---Type <return> to continue, or q <return> to quit---
#22 0x8056bab in eval_code2 (co=0x8163568, globals=0x80caecc, locals=0x0, 
    args=0x80d562c, argcount=2, kws=0x80d5634, kwcount=0, defs=0x0, 
    defcount=0, owner=0x860e81c) at ceval.c:1923
#23 0x805687c in eval_code2 (co=0x810e8f8, globals=0x80caecc, 
    locals=0x80caecc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
    defcount=0, owner=0x0) at ceval.c:1822
#24 0x80545d7 in PyEval_EvalCode (co=0x810e8f8, globals=0x80caecc, 
    locals=0x80caecc) at ceval.c:319
#25 0x80660b4 in run_node (n=0x80d3cc8, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", globals=0x80caecc, 
    locals=0x80caecc) at pythonrun.c:886
#26 0x8066079 in run_err_node (n=0x80d3cc8, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", globals=0x80caecc, 
    locals=0x80caecc) at pythonrun.c:874
#27 0x8066057 in PyRun_FileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", start=257, 
    globals=0x80caecc, locals=0x80caecc, closeit=1) at pythonrun.c:866
#28 0x8065821 in PyRun_SimpleFileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", closeit=1)
    at pythonrun.c:579
#29 0x80654d0 in PyRun_AnyFileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", closeit=1)
    at pythonrun.c:459
---Type <return> to continue, or q <return> to quit---
#30 0x8051a40 in Py_Main (argc=4, argv=0xbffff814) at main.c:289
#31 0x8051566 in main (argc=5, argv=0xbffff814) at python.c:10
(gdb) 
(gdb) list
145     static void
146     update_refs(PyGC_Head *containers)
147     {
148             PyGC_Head *gc = containers->gc_next;
149             for (; gc != containers; gc=gc->gc_next) {
150                     gc->gc_refs = PyObject_FROM_GC(gc)->ob_refcnt;
151             }
152     }
153
154     static int
(gdb) print gc
$1 = (PyGC_Head *) 0x0


Follow-Ups:

Date: 2000-Sep-26 04:31
By: gvanrossum

Comment:
Neil, can you have a look at this?
-------------------------------------------------------

Date: 2000-Sep-26 09:44
By: nascheme

Comment:
Since I can't reproduce this bug here are some things to 
try:

- compile Python with Py_DEBUG defined
- compile Python with Py_DEBUG and without GC
- at the start of your application call
  gc.set_debug(gc.DEBUG_LEAK) and gc.set_threshold(1)
- at the start of your application disable GC with gc.disable()
- recompile your extension modules
-------------------------------------------------------

Date: 2000-Sep-26 09:45
By: nascheme

Comment:
Since I can't reproduce this bug here are some things to 
try:

- compile Python with Py_DEBUG defined
- compile Python with Py_DEBUG and without GC
- at the start of your application call
  gc.set_debug(gc.DEBUG_LEAK) and gc.set_threshold(1)
- at the start of your application disable GC with gc.disable()
- recompile your extension modules
- checkout Python from a few days ago (cvs -D option)
-------------------------------------------------------

Date: 2000-Sep-29 01:39
By: hooft

Comment:
Sorry that I have not been able to react quicker. Unfortunately I won't be here in the weekend either.

- Py_Debug didn't change anything, it still dumped core.
- set_debug and set_threshold(1) : it still dumps core.

#0  update_refs (containers=0x80be6f8) at ./gcmodule.c:150
150                     gc->gc_refs = PyObject_FROM_GC(gc)->ob_refcnt;
(gdb) where
#0  update_refs (containers=0x80be6f8) at ./gcmodule.c:150
#1  0x8079db3 in collect (young=0x80be6f8, old=0x80be6f8) at ./gcmodule.c:382
#2  0x8079f57 in collect_generations () at ./gcmodule.c:471
#3  0x807a044 in _PyGC_Insert (op=0x87b1c14) at ./gcmodule.c:507
#4  0x80589cb in PyTuple_New (size=3) at tupleobject.c:87

(gdb) print containers
$50 = (PyGC_Head *) 0x80be6f8
(gdb) print gc
$51 = (PyGC_Head *) 0x0

I checked the first 50 or so references, no NULL encountered yet.

- gc.disable makes it continue, but I get all kinds of weird trouble
   with Tk:
Error: 3
AttributeError Exception in Tk callback
  Function: <function <lambda> at 0x87cb8e4> (type: <type 'function'>)
  Args: ('3652', '1', '1', '0', '1', '0', '-449121110', '0', '102', '0', '??', '0', '??', '0', '.138093276.141021828.141028308.142397076.142399772.142400300.142414228', '7', '544', '454', '1')
Traceback (innermost last):
  File "/usr/local/nonius/lib/python2.0/site-packages/Pmw/Pmw_0_8_4/lib/PmwBase.py", line 1668, in __call__
    args = apply(self.subst, args)
  File "/usr/local/nonius/lib/python2.0/lib-tk/Tkinter.py", line 1048, in _substitute
    e.widget = self._nametowidget(W)
  File "/usr/local/nonius/lib/python2.0/lib-tk/Tkinter.py", line 973, in nametowidget
    w = w._root()
  File "/usr/local/nonius/lib/python2.0/lib-tk/Tkinter.py", line 1012, in _root
    while w.master: w = w.master
AttributeError: 'Frame' instance has no attribute 'master'

And when the program terminates:
  [73562 refs]
  Print left references? [ny] n
  zsh: segmentation fault (core dumped)  collect new orient
  collect new orient  6.18s user 0.33s system 2% cpu 4:06.65 total

(gdb) where
#0  0x400e7129 in chunk_free (ar_ptr=0x4017bd60, p=0x87ce2f8) at malloc.c:3111
#1  0x400e6fba in __libc_free (mem=0x87ce300) at malloc.c:3023
#2  0x805941e in PyTuple_Fini () at tupleobject.c:562
#3  0x80762b6 in Py_Finalize () at pythonrun.c:243
#4  0x80777f4 in Py_Exit (sts=0) at pythonrun.c:1120
#5  0x8076d5e in PyErr_PrintEx (set_sys_last_vars=1) at pythonrun.c:708
#6  0x8076c6a in PyErr_Print () at pythonrun.c:671
#7  0x80769c1 in PyRun_SimpleFileEx (fp=0x80ce428, filename=0xbffff9a3 "/usr/local/nonius/app/gui/top.py", closeit=1) at pythonrun.c:582
#8  0x8076610 in PyRun_AnyFileEx (fp=0x80ce428, filename=0xbffff9a3 "/usr/local/nonius/app/gui/top.py", closeit=1) at pythonrun.c:459
#9  0x8051c40 in Py_Main (argc=3, argv=0xbffff834) at main.c:289
#10 0x8051756 in main (argc=4, argv=0xbffff834) at python.c:10

- to be able to enable Py_DEBUG I had to recompile all extension modules, so that point I skipped.
- I don't think "cvs -D" will be very useful, it is just the first time I'm seeing
   this here, but it might have been present already for a long time.

I am at a loss. I really have no clue how to reduce the program while maintaining the problem to make a simple test case. I can't even trace where my program is failing?!?!?
-------------------------------------------------------

Date: 2000-Oct-03 13:41
By: loewis

Comment:
I notice a module _ntoolsmodule.so is used. Has this module been recompiled with the current header files? Is source code of this module available for review?
-------------------------------------------------------

Date: 2000-Oct-06 07:17
By: nascheme

Comment:
Fixed by the _PyTuple_Resize patch.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115341&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 15:21:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 07:21:56 -0700
Subject: [Python-bugs-list] [Bug #115912] GC crashes in 2.0b1 and 2.0b2
Message-ID: <200010061421.HAA10646@delerium.i.sourceforge.net>

Bug #115912, was updated on 2000-Oct-03 06:43
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: 3rd Party
Priority: 7
Summary: GC crashes in 2.0b1 and 2.0b2

Details: Forwarded message from Andrew Reutter at Origin:


We are experiencing crashes in both Python 2.0b1 and 2.0b2 that appear to be
related to cyclical garbage collection.
A summary of the scenario follows:

We have embedded Python as a .lib into a much larger project.  We build this
project in both Win32 and Solaris environments.
On Win32 _only_, we use custom memory management routines in order to
facilitate the tracking of memory.
The memory manager also fills memory with specific bit patterns upon both
allocation and deallocation in order to detect the use of uninitialized or
freed memory.

After several minutes of successful execution, we see a reproducible crash
in gc_list_remove.
It receives a node pointer which points to memory filled with our memory
initialization bit pattern (0xCD),
indicating to us that the allocation was successful, but the object was
never fully initialized or placed in a gc_list.
Although this crash occurs at the same point in our code each time, the
address of the node pointer varies with each execution,
making it impossible to set a breakpoint when the node allocation takes
place.

Since we only tweak memory management under Win32, our memory manager is
unlikely to be the culprit.
The crash disappears when Python is compiled without the WITH_CYCLE_GC
definition.

Unfortunately, the project is both extremely large and the source is closed,
so we are unable to send you a quick methodology for reproduction of our
crash.  We would nonetheless like to assist you in solving this problem in
any way we _are_ able, so let us know.
Are there any other reported bugs in gcmodule.c (we noted that some were
fixed when b2 was released)?
Is there any information you could provide us that would help us debug it
ourselves?  An example would be to direct us to the single method by which
all objects are allocated, if such a method exists.



Follow-Ups:

Date: 2000-Oct-03 13:37
By: loewis

Comment:
It might help to find out which C extension modules are used; i.e. printing sys.modules shortly before the crash. Have all extension modules been recompiled with the 2.0bx header files?
-------------------------------------------------------

Date: 2000-Oct-06 07:21
By: nascheme

Comment:
I think this is fixed by the recent _PyTuple_Resize patch.  I have not
heard from the Origin guys but the symptoms of this bug are similar to
#115341.  I'm closing this bug for now.  If I find out from Origin that it
is not fixed in the release candidate then I will reopen it.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115912&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 15:37:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 07:37:03 -0700
Subject: [Python-bugs-list] [Bug #116236] Possible leak in pystate.c
Message-ID: <200010061437.HAA20351@bush.i.sourceforge.net>

Bug #116236, was updated on 2000-Oct-06 06:26
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: None
Bug Group: None
Priority: 5
Summary: Possible leak in pystate.c

Details: Possible leak in pystate.c
It seems that head_mutex allocated with the HEAD_INIT() macro is never deleted.
Please, give me explanations...

Follow-Ups:

Date: 2000-Oct-06 07:37
By: gvanrossum

Comment:
It would only be a leak if head was ever overwritten. The way the code is written however, head_mutex is a global that is initialized the first time HEAD_INIT() is used and never again. While you may argue that this allocates some dynamic memory that is never deleted, the memory is still live (from the static global head_mutex pointer variable) so it is not a leak.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116236&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 15:37:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 07:37:45 -0700
Subject: [Python-bugs-list] [Bug #112786] Build under Cygwin fails
Message-ID: <200010061437.HAA20361@bush.i.sourceforge.net>

Bug #112786, was updated on 2000-Aug-26 01:39
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: Build under Cygwin fails

Details: Py1.6b1
========
1) socketmodule.c -- looks for netinet/tcp.h, which does not exist on cygwin.

2) gcc   python.o \
          ../libpython1.6.a    -lm  -o python
python.o: In function `main':
/usr/local/bin/Python-1.6b1/Modules/python.c:12: undefined reference to `Py_Main


Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-13 04:13
By: gvanrossum

Comment:
I don't have cygwin. Does anyone here have cygwin? I know Tim said the cygwin installer failed for him, so he doesn't have it. Is there someone outside the PythonLabs to whom we could assign this?
-------------------------------------------------------

Date: 2000-Sep-16 01:56
By: tim_one

Comment:
A fellow named Norman mailto:nhv@yahoo.com posted to c.l.py with some evidence of real Cygwin knowledge, so I emailed him a link to this bug and asked whether he'd help out.
-------------------------------------------------------

Date: 2000-Sep-16 20:29
By: nhv

Comment:
Hi I am that fellow Norman

FYI I have been doing bi-weekly builds of the Python CVS source with the 'current' Cygwin distribution for about a year.

I sent Tim my small set of diffs

Basically threading with Cygwin Python is still broken
and dll building with Cygwin has some problems but other then that everything including tkinter works for me with very minor changes.

FWIW We are succesfully embedding Python in PrettyPoly
http://prettypoly.sourceforge.net and I am using Cygwin
as my development enviroment for this

If helpful I can mail someone my diffs and the results of make test after each of my CVS sessions or apon request

Also FWIW I build Cygwin from source and have access to the Cygwin development team

I will help in anyway I can to make Python compile with Cygwin 'out of the box'  


Norman Vine nhv@yahoo.com

-------------------------------------------------------

Date: 2000-Sep-17 05:41
By: tim_one

Comment:
Here's the body of email from Norman:

I will certainly help in anyway that I can :-)

Below is a diff of my PY_SRC and the Python CVS at SourceForge

specifically

1) socketmodule.c -- looks for netinet/tcp.h, which does not exist on cygwin.

Cygwin does not have netinet / tcp.h
There has been some discussion about including a dummy tcp.h
into the distribution but I am noy sure that this is a standard header ?
see
http://sources.redhat.com/ml/cygwin/2000-09/msg00011.html

2) gcc python.o \
../libpython1.6.a -lm -o python
python.o: In function `main':
/usr/local/bin/Python-1.6b1/Modules/python.c:12: undefined reference to
`Py_Main

Before rerunning make after a failed build it is occasionally necessary to from top_level python_src directory it is necessary to do
% rm *.a *.o *.exe
I believe that this will solve this problem

I am working with the 2.0 srource tree though and I notice that this is reported against the 1.6 tree


IMHO the two main 'issues'  with Python and Cygwin remaining
are threads and dll support.

I am working on the dll stuff and am aware of Distutils

The thread stuff is beyond me and I could use some help.

I will gladly be a Cygwin 'tester' for Python.

and can forward Cygwin specific Python questions that
I can not answer directly to the appropriate Cygwin list(s)

Cheers

Norman


Index: _tkinter.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/_tkinter.c,v
retrieving revision 1.111
diff -r1.111 _tkinter.c
0a1
>
60,62c61,63
< #if !defined(MS_WINDOWS)
< #define HAVE_CREATEFILEHANDLER
< #endif
---
> //#if !(defined(MS_WINDOWS) || defined(__CYGWIN__))
> //#define HAVE_CREATEFILEHANDLER
> //#endif
64a66
> #undef HAVE_CREATEFILEHANDLER
71c73
< #ifdef MS_WINDOWS
---
> #if defined(MS_WINDOWS) || defined(__CYGWIN__)
Index: main.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/main.c,v
retrieving revision 1.44
diff -r1.44 main.c
11c11
< #ifdef MS_WINDOWS
---
> #if defined(MS_WINDOWS) || defined(__CYGWIN__)
187c187
< #ifdef MS_WINDOWS
---
> #if defined(MS_WINDOWS) || defined(__CYGWIN__)
209c209
< #ifdef MS_WINDOWS
---
> #if defined(MS_WINDOWS) || defined(__CYGWIN__)
Index: socketmodule.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v
retrieving revision 1.127
diff -r1.127 socketmodule.c
125c125
< #ifndef __BEOS__
---
> #if !defined(__BEOS__) && !defined(__CYGWIN__)

-------------------------------------------------------

Date: 2000-Oct-05 13:29
By: jhylton

Comment:
Can we close this bug now?

-------------------------------------------------------

Date: 2000-Oct-05 14:58
By: tim_one

Comment:
I doubt it.  These changes don't match the ones Norman posted in his other "bug" report.  Until he submits a proper context-diff patch or says "nevermind", I expect all Cygwin bugs should remain open.
-------------------------------------------------------

Date: 2000-Oct-05 21:47
By: nhv

Comment:
See patch: 101802 
Titled: Cygwin Fix -- missing tcp.h 
Filed: 2000-Oct-06 03:56 

After applying above patch
Cygwin V1.1.4 on w2k with
./configure --without-threads --with-suffix='exe --with-libm=
against CVS checkout as of 2200 EST 05 Oct

compiled and ran make test
minor problems still in 
test_poll
test_strftime
test_time

Win9X has a problem with
test_select

I believe the problems in test_poll will be fixed in the
next Cygwin release

Would you like me to submit Cygwin specific patches for
these problematical patches ??

Other then these minor points I believe that this 
Bug can be considered closed.

Norman



-------------------------------------------------------

Date: 2000-Oct-06 07:37
By: jlt63

Comment:
The current Cygwin CVS source has an empty netinet/tcp.h which solves this problem.  See
the following for more details:

    http://sources.redhat.com/ml/cygwin/2000-10/msg00157.html

Unfortunately, Cygwin 1.1.4 does not include an empty netinet/tcp.h but 1.1.5 will.  My
suggestion is to close this item anyway.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112786&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 15:38:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 07:38:37 -0700
Subject: [Python-bugs-list] [Bug #116235] module_search_path in PC/getpahp.c
Message-ID: <200010061438.HAA20378@bush.i.sourceforge.net>

Bug #116235, was updated on 2000-Oct-06 06:01
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: module_search_path in PC/getpahp.c

Details: The trouble seems to be in getpathp.c in the "pc" directory.
If I've seen well the static char pointer: 'module_search_path',
is allocated with
module_search_path = buf = malloc(bufsz);
but never erased. 
If I'm wrong, please, explain me where is destroyed.

Follow-Ups:

Date: 2000-Oct-06 07:38
By: gvanrossum

Comment:
This is not a memory leak as you seem to believe. The variable module_search_path must remain available until Python exits.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116235&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 15:41:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 07:41:52 -0700
Subject: [Python-bugs-list] [Bug #116237] Leak in ceval.c
Message-ID: <200010061441.HAA20546@bush.i.sourceforge.net>

Bug #116237, was updated on 2000-Oct-06 06:36
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: Leak in ceval.c

Details: Allocated 'interpreter_lock' is never deleted. I'v read the problem commented in the source code, but all the allocations "must" deleted ( in the 'init' and 'reinit' functions ). I'm sure there's always a way to do everything.

Follow-Ups:

Date: 2000-Oct-06 07:41
By: gvanrossum

Comment:
Nonsense. This is not a leak, because the variable pointing to it remains live. It will not be leaked when you call Py_Initialize() and Py_Finalize() repeatedly.

Note that there's no way you can expect a large application like Python to free() *everything* it has allocated before calling exit(). Even the C standard library doesn't guarantee this!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116237&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 15:47:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 07:47:11 -0700
Subject: [Python-bugs-list] [Bug #116241] Possible leak in pythonrun.c
Message-ID: <200010061447.HAA20731@bush.i.sourceforge.net>

Bug #116241, was updated on 2000-Oct-06 06:56
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Wont Fix
Bug Group: Not a Bug
Priority: 5
Summary: Possible leak in pythonrun.c

Details: Possible leak in pythonrun.c:
The _PyCompareState_Key PyObject pointer defined in object.h, allocated in pythonrun.c with: 
"_PyCompareState_Key = PyString_InternFromString("cmp_state");", probably is never deleted.


Follow-Ups:

Date: 2000-Oct-06 07:47
By: gvanrossum

Comment:
This would be a leak if the interned database were ever to be emptied, but it isn't, so it's not a leak.

Please stop submitting bug reports about "leaks". If you want to mail me a list of all the "leaks" you have found, please go ahead and mail them to pythoneers@beopen.com.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116241&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 15:47:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 07:47:38 -0700
Subject: [Python-bugs-list] [Bug #116236] Possible leak in pystate.c
Message-ID: <200010061447.HAA20740@bush.i.sourceforge.net>

Bug #116236, was updated on 2000-Oct-06 06:26
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: Possible leak in pystate.c

Details: Possible leak in pystate.c
It seems that head_mutex allocated with the HEAD_INIT() macro is never deleted.
Please, give me explanations...

Follow-Ups:

Date: 2000-Oct-06 07:37
By: gvanrossum

Comment:
It would only be a leak if head was ever overwritten. The way the code is written however, head_mutex is a global that is initialized the first time HEAD_INIT() is used and never again. While you may argue that this allocates some dynamic memory that is never deleted, the memory is still live (from the static global head_mutex pointer variable) so it is not a leak.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116236&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 15:48:02 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 07:48:02 -0700
Subject: [Python-bugs-list] [Bug #116235] module_search_path in PC/getpahp.c
Message-ID: <200010061448.HAA20778@bush.i.sourceforge.net>

Bug #116235, was updated on 2000-Oct-06 06:01
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: module_search_path in PC/getpahp.c

Details: The trouble seems to be in getpathp.c in the "pc" directory.
If I've seen well the static char pointer: 'module_search_path',
is allocated with
module_search_path = buf = malloc(bufsz);
but never erased. 
If I'm wrong, please, explain me where is destroyed.

Follow-Ups:

Date: 2000-Oct-06 07:38
By: gvanrossum

Comment:
This is not a memory leak as you seem to believe. The variable module_search_path must remain available until Python exits.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116235&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 15:50:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 07:50:44 -0700
Subject: [Python-bugs-list] [Bug #116172] 2.0b2 curses module fails to build on SGI
Message-ID: <200010061450.HAA20922@bush.i.sourceforge.net>

Bug #116172, was updated on 2000-Oct-05 12:40
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 2.0b2 curses module fails to build on SGI

Details: I didn't see this in the database.

Trying to build 2.0b2 here on SGI IRIX 6.5.  I have this
line in Setup:

     _curses _cursesmodule.c -lcurses -ltermcap

This used to work on 1.5.2 on IRIX 6.5, but it doesn't with 2.0b2.

Here is a digested version of the errors:

cc -n32  -O -KPIC -I./../Include -I.. -DHAVE_CONFIG_H -c ./_cursesmodule.c
...
  The identifier "attr_t" is undefined.
  The identifier "ACS_S3" is undefined.
  The identifier "ACS_LEQUAL" is undefined.
  The identifier "ACS_GEQUAL" is undefined.
  The identifier "ACS_PI" is undefined.
  The identifier "ACS_NEQUAL" is undefined.
  The identifier "ACS_STERLING" is undefined.
  A value of type "int" cannot be assigned to an entity of type "char *".
        capname = tigetstr( capname );
                ^
  The identifier "A_HORIZONTAL" is undefined.
  The identifier "A_LEFT" is undefined.
  The identifier "A_LOW" is undefined.
  The identifier "A_RIGHT" is undefined.
  The identifier "A_TOP" is undefined.
  The identifier "A_VERTICAL" is undefined.


Follow-Ups:

Date: 2000-Oct-06 07:50
By: gvanrossum

Comment:
I don't know, but I think this may be caused by IRIX having an old, incompatible version of curses. So it probably won't work. Too bad. You may be able to get a different curses implementation (there must be a free one that comes with Linux???).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116172&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 16:31:15 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 08:31:15 -0700
Subject: [Python-bugs-list] [Bug #116244] 2.0b2 xml.dom.minidom: no attributes allowed
Message-ID: <200010061531.IAA13452@delerium.i.sourceforge.net>

Bug #116244, was updated on 2000-Oct-06 08:31
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 2.0b2 xml.dom.minidom: no attributes allowed

Details: C:\>python
Python 2.0b2 (#6, Sep 26 2000, 14:59:21) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import xml.dom.minidom
>>> adom = xml.dom.minidom.parseString("<a b='c'/>")
Traceback (most recent call last):
    [snip]
  File "D:\Python20\lib\xml\dom\pulldom.py", line 49, in startElementNS
    node.setAttributeNode(qname,attr)
UnboundLocalError: Local variable 'qname' referenced before assignment
>>>

And indeed, peeking around line 49 of the pulldom.py file, one sees variable qname assigned only along one branch of an if statement, but then used unconditionally at line 49.

Trying to fix this bug by adding some assignment for qname further fails since the setAttributeNote method called at 49 only wants one arg (the attr), not two.  Trying to fix this by only passing the attr lets the dom object be constructed, but then:

>>> adom.writexml(sys.stdout)
<a None="Traceback (most recent call last):
   [snip]
  File "D:\Python20\lib\xml\dom\minidom.py", line 145, in _write_data
    data = string.replace(data, "&", "&amp;")
  File "D:\Python20\lib\string.py", line 363, in replace
    return s.replace(old, new, maxsplit)
  File "D:\Python20\lib\xml\dom\minidom.py", line 74, in __getattr__
    raise AttributeError, key
AttributeError: replace
>>>

The "data" argument to method _write_data is not really a string object -- so it doesn't have a .replace method, and string.replace now uses the object's replace method, so it fails.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116244&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 16:40:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 08:40:03 -0700
Subject: [Python-bugs-list] [Bug #116244] 2.0b2 xml.dom.minidom: no attributes allowed
Message-ID: <200010061540.IAA13849@delerium.i.sourceforge.net>

Bug #116244, was updated on 2000-Oct-06 08:31
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Open
Resolution: None
Bug Group: None
Priority: 8
Summary: 2.0b2 xml.dom.minidom: no attributes allowed

Details: C:\>python
Python 2.0b2 (#6, Sep 26 2000, 14:59:21) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import xml.dom.minidom
>>> adom = xml.dom.minidom.parseString("<a b='c'/>")
Traceback (most recent call last):
    [snip]
  File "D:\Python20\lib\xml\dom\pulldom.py", line 49, in startElementNS
    node.setAttributeNode(qname,attr)
UnboundLocalError: Local variable 'qname' referenced before assignment
>>>

And indeed, peeking around line 49 of the pulldom.py file, one sees variable qname assigned only along one branch of an if statement, but then used unconditionally at line 49.

Trying to fix this bug by adding some assignment for qname further fails since the setAttributeNote method called at 49 only wants one arg (the attr), not two.  Trying to fix this by only passing the attr lets the dom object be constructed, but then:

>>> adom.writexml(sys.stdout)
<a None="Traceback (most recent call last):
   [snip]
  File "D:\Python20\lib\xml\dom\minidom.py", line 145, in _write_data
    data = string.replace(data, "&", "&amp;")
  File "D:\Python20\lib\string.py", line 363, in replace
    return s.replace(old, new, maxsplit)
  File "D:\Python20\lib\xml\dom\minidom.py", line 74, in __getattr__
    raise AttributeError, key
AttributeError: replace
>>>

The "data" argument to method _write_data is not really a string object -- so it doesn't have a .replace method, and string.replace now uses the object's replace method, so it fails.


Follow-Ups:

Date: 2000-Oct-06 08:40
By: jhylton

Comment:
Paul-- We need this fixed ASAP.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116244&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 16:42:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 08:42:14 -0700
Subject: [Python-bugs-list] [Bug #116172] 2.0b2 curses module fails to build on SGI
Message-ID: <200010061542.IAA13909@delerium.i.sourceforge.net>

Bug #116172, was updated on 2000-Oct-05 12:40
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: 2.0b2 curses module fails to build on SGI

Details: I didn't see this in the database.

Trying to build 2.0b2 here on SGI IRIX 6.5.  I have this
line in Setup:

     _curses _cursesmodule.c -lcurses -ltermcap

This used to work on 1.5.2 on IRIX 6.5, but it doesn't with 2.0b2.

Here is a digested version of the errors:

cc -n32  -O -KPIC -I./../Include -I.. -DHAVE_CONFIG_H -c ./_cursesmodule.c
...
  The identifier "attr_t" is undefined.
  The identifier "ACS_S3" is undefined.
  The identifier "ACS_LEQUAL" is undefined.
  The identifier "ACS_GEQUAL" is undefined.
  The identifier "ACS_PI" is undefined.
  The identifier "ACS_NEQUAL" is undefined.
  The identifier "ACS_STERLING" is undefined.
  A value of type "int" cannot be assigned to an entity of type "char *".
        capname = tigetstr( capname );
                ^
  The identifier "A_HORIZONTAL" is undefined.
  The identifier "A_LEFT" is undefined.
  The identifier "A_LOW" is undefined.
  The identifier "A_RIGHT" is undefined.
  The identifier "A_TOP" is undefined.
  The identifier "A_VERTICAL" is undefined.


Follow-Ups:

Date: 2000-Oct-06 07:50
By: gvanrossum

Comment:
I don't know, but I think this may be caused by IRIX having an old, incompatible version of curses. So it probably won't work. Too bad. You may be able to get a different curses implementation (there must be a free one that comes with Linux???).
-------------------------------------------------------

Date: 2000-Oct-06 08:42
By: jhylton

Comment:
Eric, can you look at this today?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116172&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 16:55:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 08:55:46 -0700
Subject: [Python-bugs-list] [Bug #115555] Parser crashes for deeply nested list displays
Message-ID: <200010061555.IAA23536@bush.i.sourceforge.net>

Bug #115555, was updated on 2000-Sep-28 03:42
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 5
Summary: Parser crashes for deeply nested list displays

Details: Compiling

s=[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]

gives an error message

s_push: parser stack overflow

Python 1.5.2 then reports a MemoryError, 2.0b2 a SyntaxError.

Follow-Ups:

Date: 2000-Sep-28 12:35
By: jhylton

Comment:
What is the desired outcome here?  Python is reporting a SyntaxError; it's not crashing.  Would you like to increase the max stack size for the parser?  What should it's limit be?

The current parser stack limit allows eval("["*x+"]"*x) for values of x up to and including 35.  I'm not sure why the limit is set this low.  I bumped the value of MAXSTACK in parser.c from 500 to 5000 and it accepted the nest list expression for values of x up to 357.

-------------------------------------------------------

Date: 2000-Sep-29 09:08
By: loewis

Comment:
It was confusing that Python would produce a SyntaxError for an obviously-correct script, and that such a small limit was found in the parser.

Since the limit is not due to recursion on the C stack:  Would a patch removing this limitation be accepted (certainly not for 2.0). The two alternatives I see are to make the array completely dynamic, or to allocate a dynamic array in the stack if the static one overflows.
-------------------------------------------------------

Date: 2000-Sep-29 21:48
By: jhylton

Comment:
There is a limit that is based on the C stack, because the parser is recursive descent.  If I set the max stack size to 100000, I get a seg fault.
I'm not sure if a patch for this would be accepted post 2.0 or not; I'll talk to Guido and see what he thinks.

I think we could safely increase the static limit before 2.0, though I'm not 100% certain.  What nesting level did your application come up with?
I would guess that max stack == 10000 (700 nested lists) should be safe on all reasonable platforms and much more useful.

-------------------------------------------------------

Date: 2000-Sep-30 19:12
By: bwarsaw

Comment:
BTW, JPython gets to 133 nestings (on my RH6.1 system) before a java.lang.StackOverflow gets thrown.

Ever heard the old joke "Doctor, it hurts when I do this?" ... 
-------------------------------------------------------

Date: 2000-Oct-02 02:23
By: loewis

Comment:
The problem was found when printing an expression like parser.suite("3*4").tolist(),
then modifying the string, and feeding the outcome back to Python. It is not a serious problem that this works for every possible Python code - it is just confusing to get a SyntaxError when there is no syntax error in the input.

BTW, I believe the parser is *not* recursive on the C stack; I could not find any sign of recursion inside Parser/parser.c. Most likely, the crash you got when increasing the parser stack size comes from Python/compile.c; the com_* functions are recursive on the C stack. It would be possible to remove the recursion here as well (using an explicit stack that lives on the heap); that would require a larger rewrite of compile.c, though.
-------------------------------------------------------

Date: 2000-Oct-02 03:22
By: gvanrossum

Comment:
The SyntaxError is actually caused by a bug in the parser code! When s_push() reports a stack overflow it returns -1, which is passed through unchanged by push() -- but the code that calls it only checks for positive error codes! I've fixed this by returning E_NOMEM from s_push() instead.

The only downside I see of making MAXSTACK larger is that a stack of maximal size is allocated each time the parser is invoked. With MAXSTACK=500 on a 32-bit machine, that's 6K. Switch to 5000 and it's 60K. No big deal except perhaps for ports to PalmPilots and the like...

Note that with MAXSTACK=500, you can "only" have 35 nested lists.
-------------------------------------------------------

Date: 2000-Oct-06 08:55
By: jhylton

Comment:
Guido fixed the bug part.  Defer any other changes to post 2.0.
Added to PEP 42.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115555&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 17:01:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 09:01:03 -0700
Subject: [Python-bugs-list] [Bug #113773] Python 2.0b1 selectmodule compile error under Redhat 5.2
Message-ID: <200010061601.JAA14783@delerium.i.sourceforge.net>

Bug #113773, was updated on 2000-Sep-06 18:26
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: Python 2.0b1 selectmodule compile error under Redhat 5.2

Details: Environment: Redhat 5.2 running the gcc compiler that comes with the
distribution (gcc 2.7.2.3).

'make' failed when compiling selectmodule.c ('./configure' ran ok)because
the following constants were undefined:

POLLRDNORM, POLLRDBAND, POLLWRBAND

The /usr/include/sys/poll.h file does not contain these constants.
Under Redhat 6.2 the constants are defined in the /usr/include/bits/poll.h
file (which is not present in the Redhat 5.2 distribution).

I used the Redhat 6.2 poll.h file and the selectmodule compiled (under
Redhat 5.2) but got the following error when running 
'make test' (it looks like it might be related to the compile problem):

test test_poll crashed -- select.error: (9, 'Bad file descriptor')

1 test failed: test_poll



Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 23:08
By: tim_one

Comment:
Boosted the priority and assigned to Fred.  Don't know what you can do about an older Redhat build problem, and it's not clear that the test failure isn't simply due to mixing files across OS releases.  I'm inclined to blame it on the OS.
-------------------------------------------------------

Date: 2000-Sep-15 13:11
By: fdrake

Comment:
I've asked SourceForge if there are ways to use older versions of operating systems on their compile farm.  Until then, we'll need a volunteer with a RH5.2 system to help with this.

Stuart:  Are you willing to test a patch if I mail it to you?  Thanks.
-------------------------------------------------------

Date: 2000-Sep-15 19:50
By: fdrake

Comment:
SourceForge will try and provide a RH5.2 installation for us; now that's service!
-------------------------------------------------------

Date: 2000-Sep-20 22:33
By: fdrake

Comment:
Reducing priority since the platform is old and we still don't have access to it.
-------------------------------------------------------

Date: 2000-Sep-22 07:32
By: fdrake

Comment:
For the record, SF stills plans to attempt to provide a RH5.2 installation / "virtual environment" we can use, but the person who handles it says it will be this weekend or next week before he can get to it.
-------------------------------------------------------

Date: 2000-Oct-06 09:01
By: twouters

Comment:
I have access to a few RedHat 5.2 machines. I'll see if I can reproduce the problem there. 

(I consider the undefined values the problem, *not* the test crash. RedHat 6 uses glibc 2.1, RedHat 5 uses glibc 2.0, and those header files should not be considered portable. At best it defined the constants to values that are meaningless to the underlying library, at worst it made select.poll() delete random files from the filesystem ;-)
 
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113773&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 17:06:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 09:06:54 -0700
Subject: [Python-bugs-list] [Bug #116144] Python 2.0b1  hangs
Message-ID: <200010061606.JAA15009@delerium.i.sourceforge.net>

Bug #116144, was updated on 2000-Oct-05 08:35
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Python 2.0b1  hangs

Details: Hi

My python program hangs after a while,  cannot even kill through ^C.  just hangs!

I am running python on the DEC Alpha system.   The program goes through 
a large flat file biological database. Reads entry by entry and prints 
some information after parsing each entry.  (an entry consists of number of lines).
I can give you more detail, if this was an unknown problem.


Ramu


Follow-Ups:

Date: 2000-Oct-05 11:07
By: gvanrossum

Comment:
We definitely need more information! One problem is that we don't have a DEC Alpha system to test on, so we can't easily try if out even if you gave us the source of your script and the input data!

Of course it's also possible that it's a bug in your program, or a change in Python that has nothing to do with DEC Alpha. But we can't tell from what you're saying! Can you reproduce the problem with a small test script? Also, please try if this is still broken with Python 2.0b2.
-------------------------------------------------------

Date: 2000-Oct-06 09:06
By: chennaramu

Comment:
Hi

Thanks for the response.  Actually I tested with  version 1.5.2  1.6  and 2.0b on Dec
machines . Same problem.

I am trying with linux, so far it is running (it will take another 5-7 hours to finish).
If  this succeeds with linux,  I will again try with DEC machine and let you know.

The data file is too large, I can give you ftp address to copy . 

Ramu

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116144&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 17:09:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 09:09:28 -0700
Subject: [Python-bugs-list] [Bug #113773] Python 2.0b1 selectmodule compile error under Redhat 5.2
Message-ID: <200010061609.JAA15154@delerium.i.sourceforge.net>

Bug #113773, was updated on 2000-Sep-06 18:26
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 1
Summary: Python 2.0b1 selectmodule compile error under Redhat 5.2

Details: Environment: Redhat 5.2 running the gcc compiler that comes with the
distribution (gcc 2.7.2.3).

'make' failed when compiling selectmodule.c ('./configure' ran ok)because
the following constants were undefined:

POLLRDNORM, POLLRDBAND, POLLWRBAND

The /usr/include/sys/poll.h file does not contain these constants.
Under Redhat 6.2 the constants are defined in the /usr/include/bits/poll.h
file (which is not present in the Redhat 5.2 distribution).

I used the Redhat 6.2 poll.h file and the selectmodule compiled (under
Redhat 5.2) but got the following error when running 
'make test' (it looks like it might be related to the compile problem):

test test_poll crashed -- select.error: (9, 'Bad file descriptor')

1 test failed: test_poll



Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 23:08
By: tim_one

Comment:
Boosted the priority and assigned to Fred.  Don't know what you can do about an older Redhat build problem, and it's not clear that the test failure isn't simply due to mixing files across OS releases.  I'm inclined to blame it on the OS.
-------------------------------------------------------

Date: 2000-Sep-15 13:11
By: fdrake

Comment:
I've asked SourceForge if there are ways to use older versions of operating systems on their compile farm.  Until then, we'll need a volunteer with a RH5.2 system to help with this.

Stuart:  Are you willing to test a patch if I mail it to you?  Thanks.
-------------------------------------------------------

Date: 2000-Sep-15 19:50
By: fdrake

Comment:
SourceForge will try and provide a RH5.2 installation for us; now that's service!
-------------------------------------------------------

Date: 2000-Sep-20 22:33
By: fdrake

Comment:
Reducing priority since the platform is old and we still don't have access to it.
-------------------------------------------------------

Date: 2000-Sep-22 07:32
By: fdrake

Comment:
For the record, SF stills plans to attempt to provide a RH5.2 installation / "virtual environment" we can use, but the person who handles it says it will be this weekend or next week before he can get to it.
-------------------------------------------------------

Date: 2000-Oct-06 09:01
By: twouters

Comment:
I have access to a few RedHat 5.2 machines. I'll see if I can reproduce the problem there. 

(I consider the undefined values the problem, *not* the test crash. RedHat 6 uses glibc 2.1, RedHat 5 uses glibc 2.0, and those header files should not be considered portable. At best it defined the constants to values that are meaningless to the underlying library, at worst it made select.poll() delete random files from the filesystem ;-)
 
-------------------------------------------------------

Date: 2000-Oct-06 09:09
By: twouters

Comment:
Actually, this was already fixed by akuchling, in revision 2.48 of selectmodule.c (based on a patch by Neil Schemenauer.) I've confirmed that this indeed fixes the problem on RedHat 5.2: selectmodule compiles fine, and the relevant tests all pass.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113773&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 17:11:15 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 09:11:15 -0700
Subject: [Python-bugs-list] [Bug #113811] Python 2.0 beta 1 -- urllib.urlopen() fails
Message-ID: <200010061611.JAA24115@bush.i.sourceforge.net>

Bug #113811, was updated on 2000-Sep-07 09:45
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Irreproducible
Priority: 3
Summary: Python 2.0 beta 1 -- urllib.urlopen() fails

Details: In performing a urllib.urlopen(url) with "url" containing a valid URL, I got the following error message:

Traceback (most recent call last):
  File "IGNRatings.py", line 249, in ?
    main(sys.argv[1:])
  File "IGNRatings.py", line 132, in main
    inStream = urllib.urlopen(url)
  File "E:\Python20\lib\urllib.py", line 61, in urlopen
    return _urlopener.open(url)
  File "E:\Python20\lib\urllib.py", line 163, in open
    return getattr(self, name)(url)
  File "E:\Python20\lib\urllib.py", line 259, in open_http
    h = httplib.HTTP(host)
  File "E:\Python20\lib\httplib.py", line 626, in __init__
    self._conn = self._connection_class(host, port)
  File "E:\Python20\lib\httplib.py", line 325, in __init__
    self._set_hostport(host, port)
  File "E:\Python20\lib\httplib.py", line 332, in _set_hostport
    port = int(host[i+1:])
ValueError: invalid literal for int():


I looked into this a tiny bit and found that HTTPConnection.__init__() is called with host="http:" -- probably not the right thing. Python 1.6 works correctly.

Thanks,
Bob Alexander
bobalex@home.com

Follow-Ups:

Date: 2000-Sep-07 15:02
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-11 15:04
By: gvanrossum

Comment:
My suspicion is that this is caused by an invalid URL.
The stacktrace doesn't show what URL is being used, but I bet that on close inspection there's a tiny problem with it.

We'll have to close this for lack of information unless the original submittor can help us to debug this by printing the value of url in urlopen().
-------------------------------------------------------

Date: 2000-Oct-06 09:11
By: jhylton

Comment:
Have not heard back from original submittor.  I do not believe this is a bug and do not intend to fix it for 2.0.  Waiting a little longer to hear from Bob before closing this report.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113811&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 17:12:41 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 09:12:41 -0700
Subject: [Python-bugs-list] [Bug #116251] SRE miscompiles character class containing -
Message-ID: <200010061612.JAA24146@bush.i.sourceforge.net>

Bug #116251, was updated on 2000-Oct-06 09:12
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: SRE miscompiles character class containing -

Details: (Found by Neil Schemenauer)  Consider this test program:

import re

p = re.compile('[\w]+')
m = p.match('laser_beam')
print m and m.span()

p = re.compile('[\w-]+')
m = p.match('laser_beam')
print m and m.span()

This prints (0,10) and None, but the second pattern just adds a - inside the character class, so it should still match.  Printing the code generated by the two patterns 
shows that they're compiled differently.

(Is there a disassembler for SRE byte code hiding somewhere? 
I'd have dug further if there was...)

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116251&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 17:22:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 09:22:58 -0700
Subject: [Python-bugs-list] [Bug #116251] SRE miscompiles character class containing -
Message-ID: <200010061622.JAA15654@delerium.i.sourceforge.net>

Bug #116251, was updated on 2000-Oct-06 09:12
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: SRE miscompiles character class containing -

Details: (Found by Neil Schemenauer)  Consider this test program:

import re

p = re.compile('[\w]+')
m = p.match('laser_beam')
print m and m.span()

p = re.compile('[\w-]+')
m = p.match('laser_beam')
print m and m.span()

This prints (0,10) and None, but the second pattern just adds a - inside the character class, so it should still match.  Printing the code generated by the two patterns 
shows that they're compiled differently.

(Is there a disassembler for SRE byte code hiding somewhere? 
I'd have dug further if there was...)

Follow-Ups:

Date: 2000-Oct-06 09:22
By: akuchling

Comment:
Found the .dump() method; it seems to me that the pattern is
being tokenized and compiled to a sequence all right.  

Incidentally, [\w+]+ matches correctly, even though
[\w-]+ doesn't.  
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116251&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 18:02:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 10:02:00 -0700
Subject: [Python-bugs-list] [Bug #113803] [2.0b1 NT4.0] printing non asci char causes idle to abort
Message-ID: <200010061702.KAA26044@bush.i.sourceforge.net>

Bug #113803, was updated on 2000-Sep-07 08:33
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: Fixed
Bug Group: None
Priority: 7
Summary: [2.0b1 NT4.0] printing non asci char causes idle to abort

Details: try:

alef = u'\u05d0'
print alef.encode('utf-8')

any enter after the last statement will cause idle to abort

on 'bare' python this does not cause any problem.

[tebeka@lycosmail.com]

Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-12 15:13
By: gvanrossum

Comment:
Crash confirmed in IDLE on Win98SE.
Prints (expected) garbage and doesn't crash in command line on Win98SE.
No crash in IDLE or command line on Linux.

Tim, can you take a look with the VC debugger?

-------------------------------------------------------

Date: 2000-Sep-12 19:45
By: tim_one

Comment:
Changed group to platform-specific.

Note that this is a simpler test case w/ the same symptom:

print "\327\220"

Don't know why, do know that _tkinter.pyd and tk83.dll crap out w/ page faults at the end, assigned to Fredrik on the chance he's bumped into this before.  /F, bounce it back at me if it's unclear to you.
-------------------------------------------------------

Date: 2000-Sep-12 23:38
By: tim_one

Comment:
Bad news:  this doesn't always fail in the debugger (sometimes it just prints an alef glyph and nothing odd happens at all).

Better news:  it usually fails, and when it does it dies here (_tkinter.c):

static char *
AsString(PyObject *value, PyObject *tmp)
{
	if (PyString_Check(value))
		return PyString_AsString(value);
	else {
		PyObject *v = PyObject_Str(value);
		PyList_Append(tmp, v);
		Py_DECREF(v);
		return PyString_AsString(v);
	}
}

It's in the "else" branch, v is NULL, and the Py_DECREF expansion blows up with an access violation.  Py_ObjectStr certainly *can* return NULL, and I don't understand the intent of this code well enough to know why it believes that needn't be guarded against.

"value" at this point has type PyUnicode_Type.  For whatever reason, the debugger won't let me cast it to a PyUnicodeObject*.
-------------------------------------------------------

Date: 2000-Sep-20 00:30
By: micpro

Comment:
Crash confirmed for python 2.0 on Linux.
Segfault in _tkinter:267 when called from _tkinter.c:1260
Reason: string object expected, but unicode is given.
AsObj does treat this correctly, so this gets better after
changing line 1260
   Tcl_SetResult(Tkapp_Interp(self), AsString(res, tmp),
                 TCL_VOLATILE);

to
   Tcl_SetObjResult(Tkapp_Interp(self), AsObj(res));

After this change, idle does not segfault anymore and prints
alef correctly, but it still behaves strange after printing. it.
-------------------------------------------------------

Date: 2000-Sep-30 21:32
By: gvanrossum

Comment:
This looks kinda important, so I've raised the priority.
-------------------------------------------------------

Date: 2000-Oct-03 08:19
By: gvanrossum

Comment:
Reassigned to Guido so Fredrik can concentrate on SRE.
-------------------------------------------------------

Date: 2000-Oct-06 10:02
By: gvanrossum

Comment:
Fixed in CVS. The AsString() routine was incredibly naive, as was the error handling in Merge().
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113803&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 18:06:41 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 10:06:41 -0700
Subject: [Python-bugs-list] [Bug #116255] 2.0b2:  LDSHARED incorrect on SGI IRIX
Message-ID: <200010061706.KAA17371@delerium.i.sourceforge.net>

Bug #116255, was updated on 2000-Oct-06 10:06
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 2.0b2:  LDSHARED incorrect on SGI IRIX

Details: I think that's the problem.  But someone versed in Python Distutils will have to judge whether my fix is the right one.

NumPy 17.0 fails to build for me on 2.0b2 on IRIX 6.5.  This patch to the Python 2.0b2 installed tree fixes it and let's NumPy build correctly on IRIX.

config/Makefile:
-LDSHARED=       ld
+LDSHARED=       ld -shared $(LDFLAGS)

------------------------------------------------------------
Here is more detail on the error and the fix:

The NumPy build (for the latest version) fails on IRIX.

  cc -n32 -O ... 
  cc -n32 -O ... 
  ... 
  ld <list of .o's> -o build/lib.irix64-6.5-2.0/_numpy.so 

  ld: FATAL 12 : Expecting o32 objects:  
  build/temp.irix64-6.5-2.0/Src/_numpymodule.o is n32. 

There are two things failing the NumPy build. First, the ld invocation (in Distutils I assume) isn't specifying $LDFLAGS on the invocation line (which contains -n32), and second the ld invocation isn't specifying -shared.  The former is needed so the linker links a file with the same architecture as the source files it compiles; the latter is needed in order to build a shared object.

Thanks,

Randall



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116255&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 18:10:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 10:10:40 -0700
Subject: [Python-bugs-list] [Bug #113803] [2.0b1 NT4.0] printing non asci char causes idle to abort
Message-ID: <200010061710.KAA17572@delerium.i.sourceforge.net>

Bug #113803, was updated on 2000-Sep-07 08:33
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Summary: [2.0b1 NT4.0] printing non asci char causes idle to abort

Details: try:

alef = u'\u05d0'
print alef.encode('utf-8')

any enter after the last statement will cause idle to abort

on 'bare' python this does not cause any problem.

[tebeka@lycosmail.com]

Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-12 15:13
By: gvanrossum

Comment:
Crash confirmed in IDLE on Win98SE.
Prints (expected) garbage and doesn't crash in command line on Win98SE.
No crash in IDLE or command line on Linux.

Tim, can you take a look with the VC debugger?

-------------------------------------------------------

Date: 2000-Sep-12 19:45
By: tim_one

Comment:
Changed group to platform-specific.

Note that this is a simpler test case w/ the same symptom:

print "\327\220"

Don't know why, do know that _tkinter.pyd and tk83.dll crap out w/ page faults at the end, assigned to Fredrik on the chance he's bumped into this before.  /F, bounce it back at me if it's unclear to you.
-------------------------------------------------------

Date: 2000-Sep-12 23:38
By: tim_one

Comment:
Bad news:  this doesn't always fail in the debugger (sometimes it just prints an alef glyph and nothing odd happens at all).

Better news:  it usually fails, and when it does it dies here (_tkinter.c):

static char *
AsString(PyObject *value, PyObject *tmp)
{
	if (PyString_Check(value))
		return PyString_AsString(value);
	else {
		PyObject *v = PyObject_Str(value);
		PyList_Append(tmp, v);
		Py_DECREF(v);
		return PyString_AsString(v);
	}
}

It's in the "else" branch, v is NULL, and the Py_DECREF expansion blows up with an access violation.  Py_ObjectStr certainly *can* return NULL, and I don't understand the intent of this code well enough to know why it believes that needn't be guarded against.

"value" at this point has type PyUnicode_Type.  For whatever reason, the debugger won't let me cast it to a PyUnicodeObject*.
-------------------------------------------------------

Date: 2000-Sep-20 00:30
By: micpro

Comment:
Crash confirmed for python 2.0 on Linux.
Segfault in _tkinter:267 when called from _tkinter.c:1260
Reason: string object expected, but unicode is given.
AsObj does treat this correctly, so this gets better after
changing line 1260
   Tcl_SetResult(Tkapp_Interp(self), AsString(res, tmp),
                 TCL_VOLATILE);

to
   Tcl_SetObjResult(Tkapp_Interp(self), AsObj(res));

After this change, idle does not segfault anymore and prints
alef correctly, but it still behaves strange after printing. it.
-------------------------------------------------------

Date: 2000-Sep-30 21:32
By: gvanrossum

Comment:
This looks kinda important, so I've raised the priority.
-------------------------------------------------------

Date: 2000-Oct-03 08:19
By: gvanrossum

Comment:
Reassigned to Guido so Fredrik can concentrate on SRE.
-------------------------------------------------------

Date: 2000-Oct-06 10:02
By: gvanrossum

Comment:
Fixed in CVS. The AsString() routine was incredibly naive, as was the error handling in Merge().
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113803&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 18:11:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 10:11:59 -0700
Subject: [Python-bugs-list] [Bug #112265] Impossible to get Win32 default font encoding in Tk widgets
Message-ID: <200010061711.KAA17600@delerium.i.sourceforge.net>

Bug #112265, was updated on 2000-Aug-18 13:37
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Closed
Resolution: Wont Fix
Bug Group: Not a Bug
Priority: 6
Summary: Impossible to get Win32 default font encoding in Tk widgets

Details: I did not managed to obtain correct font encoding in widgets on Win32 (NT Workstation, Polish version, default encoding cp1250). All cp1250 Polish characters were displayed incorrectly. I think, all characters that do not belong to Latin-1 will be displayed incorrectly. Regarding Python1.6b1, I checked the Tcl/Tk installation (8.3.2). The pure Tcl/Tk programs DO display characters in cp1250 correctly.
As far as I know, the Tcl interpreter woks with UTF-8 encoded strings. Does Python1.6b1 really know about it?

Follow-Ups:

Date: 2000-Aug-26 08:04
By: effbot

Comment:
this is really a "how do I", rather than a bug
report ;-)

:::

In 1.6 and beyond, Python's default 8-bit
encoding is plain ASCII.  this encoding is only
used when you're using 8-bit strings in "unicode
contexts" -- for example, if you compare an
8-bit string to a unicode string, or pass it to
a subsystem designed to use unicode strings.

If you pass an 8-bit string containing
characters outside the ASCII range to a function
expecting a unicode string, the result is
undefined (it's usually results in an exception,
but some subsystems may have other ideas).

Finally, Tkinter now supports Unicode.  In fact,
it assumes that all strings passed to it are
Unicode.  When using 8-bit strings, it's only
safe to use plain ASCII.

Tkinter currently doesn't raise exceptions for
8-bit strings with non-ASCII characters, but it
probably should.  Otherwise, Tk will attempt to
parse the string as an UTF-8 string, and if that
fails, it assumes ISO-8859-1.

:::

Anyway, to write portable code using characters
outside the ASCII character set, you should use
unicode strings.

in your case, you can use:

   s = unicode("<a cp1250 string>", "cp1250")

to get the platform's default encoding, you can do:

   import locale
   language, encoding = locale.getdefaultlocale()

where encoding should be cp1250 on your box.

:::

The reason this work under Tcl/Tk is that Tcl
assumes that your source code uses the
platform's default encoding, and converts things
to Unicode (not necessarily UTF-8) for you under
the hood.  Python 2.1 will hopefully support
*explicit* source encodings, but 1.6/2.0
doesn't.

-------------------------------------------------------

Date: 2000-Sep-30 21:18
By: gvanrossum

Comment:
If it's a howto, should the bug report be closed?
-------------------------------------------------------

Date: 2000-Oct-03 08:20
By: gvanrossum

Comment:
Reassigned so Fredrik can concentrate on SRE.
-------------------------------------------------------

Date: 2000-Oct-06 10:11
By: gvanrossum

Comment:
Closed, assuming it's a how-to.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112265&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 18:13:41 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 10:13:41 -0700
Subject: [Python-bugs-list] [Bug #115690] Dr. Watson error on Python2.0b2 Idle 0.6 WinNT4.0 SP6
Message-ID: <200010061713.KAA17667@delerium.i.sourceforge.net>

Bug #115690, was updated on 2000-Sep-29 14:55
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: Fixed
Bug Group: None
Priority: 6
Summary: Dr. Watson error on Python2.0b2 Idle 0.6 WinNT4.0 SP6

Details: I get a Dr. Watson error:

    pythonw.exe
    Exception: access violation (0xc0000005), 
    Address: 0x00e31652

when I run the following code in Idle 0.6, using Edit->Run Script:

---%<---cut---%<---

import unicodedata
for c in range(0x10000):
    x=unichr(c)
    try:
        b = unicodedata.numeric(x)
        #print "numeric:", repr(x)
        try:
            a = unicodedata.digit(x)
            if a != b:
                print "bad" , repr(x)
        except:
            print "Numeric but not digit", hex(c), x.encode("utf8"), \
                  "numeric ->", b
    except:
        pass

---%<---cut---%<---

(This code was recently posted on python-dev)

I've modified my .idle file, adding 

    [EditorWindow]
    font-name=tahoma


Follow-Ups:

Date: 2000-Sep-29 21:42
By: jhylton

Comment:
Marc-Andre can you check whether this is a Unicode bug that is going to come up with or without idle.  If it seems Idle specific, please assign it to Guido or Tim.  If not, it's yours :-).


-------------------------------------------------------

Date: 2000-Oct-03 10:23
By: lemburg

Comment:
I can't reproduce this on Linux, so it seems that it is related to the way TCL/Tk
displays UTF-8 data. Another possibility would be an optimization error
which doesn't happen with gcc.

Tim, could you try this on Windows and possibly tell me where the segfault
occurs in the code ?

-------------------------------------------------------

Date: 2000-Oct-03 11:27
By: gvanrossum

Comment:
Can't reproduce it on Win98SE either. (And I did try setting font-name to tahoma.)
-------------------------------------------------------

Date: 2000-Oct-04 20:42
By: tim_one

Comment:
Assigned back to Guido, because it appears identical to bug 113803, which Guido assigned to himself.

Guido, I can reproduce the problem, and regardless of font (e.g., let it use the default) on Win98SE by letting the program run to completion, and then hitting the ENTER key *twice* (first time gets an IDLE prompt, second time blows up).  It's in exactly the same place then as 113803, trying to decref a NULL pointer in _tkinter.c's AsString.

Note that there *may* be another bug here specific to NT and/or W2K too, in that W9x have much feebler Unicode support.

-------------------------------------------------------

Date: 2000-Oct-06 10:13
By: gvanrossum

Comment:
Fixed the Tkinter bug, so closing this. Please check that this is indeed fixed in the CVS version (or wait for release candidate 1, Monday).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115690&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 18:14:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 10:14:03 -0700
Subject: [Python-bugs-list] [Bug #115690] Dr. Watson error on Python2.0b2 Idle 0.6 WinNT4.0 SP6
Message-ID: <200010061714.KAA17761@delerium.i.sourceforge.net>

Bug #115690, was updated on 2000-Sep-29 14:55
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 6
Summary: Dr. Watson error on Python2.0b2 Idle 0.6 WinNT4.0 SP6

Details: I get a Dr. Watson error:

    pythonw.exe
    Exception: access violation (0xc0000005), 
    Address: 0x00e31652

when I run the following code in Idle 0.6, using Edit->Run Script:

---%<---cut---%<---

import unicodedata
for c in range(0x10000):
    x=unichr(c)
    try:
        b = unicodedata.numeric(x)
        #print "numeric:", repr(x)
        try:
            a = unicodedata.digit(x)
            if a != b:
                print "bad" , repr(x)
        except:
            print "Numeric but not digit", hex(c), x.encode("utf8"), \
                  "numeric ->", b
    except:
        pass

---%<---cut---%<---

(This code was recently posted on python-dev)

I've modified my .idle file, adding 

    [EditorWindow]
    font-name=tahoma


Follow-Ups:

Date: 2000-Sep-29 21:42
By: jhylton

Comment:
Marc-Andre can you check whether this is a Unicode bug that is going to come up with or without idle.  If it seems Idle specific, please assign it to Guido or Tim.  If not, it's yours :-).


-------------------------------------------------------

Date: 2000-Oct-03 10:23
By: lemburg

Comment:
I can't reproduce this on Linux, so it seems that it is related to the way TCL/Tk
displays UTF-8 data. Another possibility would be an optimization error
which doesn't happen with gcc.

Tim, could you try this on Windows and possibly tell me where the segfault
occurs in the code ?

-------------------------------------------------------

Date: 2000-Oct-03 11:27
By: gvanrossum

Comment:
Can't reproduce it on Win98SE either. (And I did try setting font-name to tahoma.)
-------------------------------------------------------

Date: 2000-Oct-04 20:42
By: tim_one

Comment:
Assigned back to Guido, because it appears identical to bug 113803, which Guido assigned to himself.

Guido, I can reproduce the problem, and regardless of font (e.g., let it use the default) on Win98SE by letting the program run to completion, and then hitting the ENTER key *twice* (first time gets an IDLE prompt, second time blows up).  It's in exactly the same place then as 113803, trying to decref a NULL pointer in _tkinter.c's AsString.

Note that there *may* be another bug here specific to NT and/or W2K too, in that W9x have much feebler Unicode support.

-------------------------------------------------------

Date: 2000-Oct-06 10:13
By: gvanrossum

Comment:
Fixed the Tkinter bug, so closing this. Please check that this is indeed fixed in the CVS version (or wait for release candidate 1, Monday).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115690&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 18:19:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 10:19:06 -0700
Subject: [Python-bugs-list] [Bug #110659] IDLE-0.5 copy command (PR#354)
Message-ID: <200010061719.KAA17984@delerium.i.sourceforge.net>

Bug #110659, was updated on 2000-Jul-31 14:11
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 3
Summary: IDLE-0.5 copy command (PR#354)

Details: Jitterbug-Id: 354
Submitted-By: gpk@bell-labs.com
Date: Tue, 13 Jun 2000 10:05:35 -0400 (EDT)
Version: 1.6a2+
OS: Solaris sparc 2.6


Alt-w is advertised to copy the selected text.
It doesn't.   It pops up the 'window' menu.
However, even if you are in the 'edit' menu,
alt-w apparently does nothing.

I can select text, do alt-E alt-W, move the pointer,
then do ctrl-Y, and nothing pops up.


By the way, 'ctl-U ctl-U ctl-S' is an absurdly long
sequence for something as common as searching for text.



====================================================================
Audit trail:
Tue Jul 11 08:26:00 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Oct-06 10:19
By: gvanrossum

Comment:
This is still broken in IDLE 0.6 in Python 2.0. I doubt that I'll have time to fix it -- the keyboard bindings in general are utterly weird and inconsistent.
So I'll add an item to PEP-42 (the wish-list) and close this bug report.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110659&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 18:20:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 10:20:45 -0700
Subject: [Python-bugs-list] [Bug #116144] Python 2.0b1  hangs
Message-ID: <200010061720.KAA18015@delerium.i.sourceforge.net>

Bug #116144, was updated on 2000-Oct-05 08:35
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: Python 2.0b1  hangs

Details: Hi

My python program hangs after a while,  cannot even kill through ^C.  just hangs!

I am running python on the DEC Alpha system.   The program goes through 
a large flat file biological database. Reads entry by entry and prints 
some information after parsing each entry.  (an entry consists of number of lines).
I can give you more detail, if this was an unknown problem.


Ramu


Follow-Ups:

Date: 2000-Oct-05 11:07
By: gvanrossum

Comment:
We definitely need more information! One problem is that we don't have a DEC Alpha system to test on, so we can't easily try if out even if you gave us the source of your script and the input data!

Of course it's also possible that it's a bug in your program, or a change in Python that has nothing to do with DEC Alpha. But we can't tell from what you're saying! Can you reproduce the problem with a small test script? Also, please try if this is still broken with Python 2.0b2.
-------------------------------------------------------

Date: 2000-Oct-06 09:06
By: chennaramu

Comment:
Hi

Thanks for the response.  Actually I tested with  version 1.5.2  1.6  and 2.0b on Dec
machines . Same problem.

I am trying with linux, so far it is running (it will take another 5-7 hours to finish).
If  this succeeds with linux,  I will again try with DEC machine and let you know.

The data file is too large, I can give you ftp address to copy . 

Ramu

-------------------------------------------------------

Date: 2000-Oct-06 10:20
By: gvanrossum

Comment:
So at least show us your code! If you dont' want to make it public, mail it to guido@beopen.com.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116144&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 18:23:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 10:23:20 -0700
Subject: [Python-bugs-list] [Bug #114027] Compiling on alpha-osf1v4: libpthreads is called libpthread
Message-ID: <200010061723.KAA18072@delerium.i.sourceforge.net>

Bug #114027, was updated on 2000-Sep-10 22:43
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: Compiling on alpha-osf1v4: libpthreads is called libpthread

Details: change -lpthreads into -lpthread

Follow-Ups:

Date: 2000-Sep-16 09:59
By: gvanrossum

Comment:
I don't have enough information to resolve this problem.
What Python version were you using?

Did you use the configure script? It should automtically select -lpthreads or -lpthread depending on which one is present. Did this fail for you? Please check the config.log file to find out more about this.

Since I don't have an Alpha OSF1v1 system, I can't debug this for you!
-------------------------------------------------------

Date: 2000-Sep-18 08:01
By: janw

Comment:
Python-2.0b1, with configure. And it looks like configure doesn't get this right.

I asked a colleague to look a bit more into this. He found the following:
1) You can use either pthreads? or decthreads. If you call configure with decthreads it compiles and runs fine, but the manpage says that decthreads are only there for backwards compatibility.
2) In the pthreads? case there are different possibilities:
- You can include the phtread.h file or not.
- You can call pthread_create with arguments or not.
- You can link with -lpthread or with -lpthreads
The manpage for pthread(2) suggests to use the compiler option -pthread, which boils down to cc -D_REENTRANT and ld -lpthread -lexc (modulo other options).
It looks like configure tries with a testfile without including pthread.h, thusly -lpthreads gets used. The sources *do* include pthread.h, but then you have to link against -lpthread.
Suggested fix: Change configure test file so that pthread.h gets included and call pthread_create(0,0,0,0) (eg. give four dummy arguments).
This works for OSF1, but we did not test if it breaks anything on other platforms.

Hope you can understand the description.
-------------------------------------------------------

Date: 2000-Oct-06 10:23
By: gvanrossum

Comment:
I'm afraid I can't quite decypher what you meant by your (clearly well-intended!) diagnosis. Do you think you could whip up a patch for configure.in? (Your suggestion to change the configure test is not specific enough for me to figure oput what needs to be done.)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114027&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 18:27:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 10:27:44 -0700
Subject: [Python-bugs-list] [Bug #115928] UserList.__getslice__ and co break previous behaviour
Message-ID: <200010061727.KAA18238@delerium.i.sourceforge.net>

Bug #115928, was updated on 2000-Oct-03 09:41
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: UserList.__getslice__ and co break previous behaviour

Details: When I make a class MyL derived from UserList, and a MyL instance named l, then l[:] returns a true list (in the sense that it responds to list operators).

Well, this is the behaviour in version 1.5.1. I recently upgraded to 1.5.2 (by switching my Linux distro to Debian Potato), and it breaks lots of my code, because the slice operator tries to create a new instance of MyL !

Unfortunately, MyL's constructor does not respond to UserList prototype expectance (no arguments), because MyL is a complex object that needs extra arguments at construction.

Additionally, it is not advisable, in that context, to create new MyL instances (or copies) like this, because of database connection / open files.

I triple checked the documentation of UserList/Sequences for 1.5.1, 1.5.2 and 1.6.0, and there is no such requirement that the slice operator should return a result of the same class as the operand, nor any specification on the constructor's arguments.

I understand anyway, that it has to return an object of the same sequence nature, be it tuple, list or string. But since I derive from a UserList, I expect it to look, smell and act like a python list... Hence the slice operator should return a plain list, that will in turn look, smell and act like a list, which it actually is !

The same reasonning holds for +/*/copy operators.

One could object, that if I do l=l[1:], or l=l+[x], then l would not be an MyL instance any more, and that is probably annoying.

That's perfectly true, but on one hand that's perhaps what I want, and on the other hand, it's my job to specify that + on a MyL instance should return a MyL instance, to specify how it should be done, and to implement it by overloading the adequate method. I don't want UserList implementation to decide for me !

If UserList is implemented the minimal way, then I'm free to overload it's methods to change its behaviour. That's what a class is for !
On the contrary, if it's implemented the current way, I have no choice. One solution is to bring back the old UserList implementation and put it in front of the python provided one in PYTHONPATH. Another is to overload methods to restore its generic behaviour.

Both solutions virtually make a library module useless, which I don't like. Why not making the default implementation the generic way, and provide another UserList2 implementation with different specification and requirements on its derived classes ?

Anyway, one of the implementation or the documentation/specification should be changed, so that they are in accordance to each other...


Follow-Ups:

Date: 2000-Oct-06 10:27
By: gvanrossum

Comment:
Let's update the documentation to say that for derived classes __getslice__ and others return an instance of the derived class. Since this was changed in 1.5.2 already, it's really too late to revert to the 1.5.1 specs -- it would break code relying on the 1.5.1 behavior! Plus, I really like the 1.5.2 (and 2.0) behavior better.

The best solution for you would be to override __getslice__ in your class to return a real list (or a UserList, if you prefer).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115928&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 18:37:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 10:37:24 -0700
Subject: [Python-bugs-list] [Bug #115609] Please include regexdemo.py in main distribution
Message-ID: <200010061737.KAA18639@delerium.i.sourceforge.net>

Bug #115609, was updated on 2000-Sep-28 13:11
Here is a current snapshot of the bug.

Project: Python
Category: demos and tools
Status: Closed
Resolution: Fixed
Bug Group: Feature Request
Priority: 5
Summary: Please include regexdemo.py in main distribution

Details: I would like to recommend that Guido's regexdemo.py be included in the main distribution of 2.0.  (It was included in as a "demo" in the source distribution of v1.5.2.)

I find regexdemo to be a very useful tool for debugging my REs.  I think others would find it useful too, but since it is buried fairly far down in the source distribution, it is rather hard for newcomers to find.  I therefore recommend you include it in the "tools" directory of the main distribution.

As you know, REs are very difficult to learn (and even to use after you "learn" them!), so I think an excellent aid like regexdemo.py should be given more prominence.

thanks as always,

=g2

Follow-Ups:

Date: 2000-Sep-28 16:23
By: fdrake

Comment:
regexdemo.py is located in Demo/tkinter/guido/ and should be in the source distribution (don't know about Windows).  It is out of date as it uses regex instead of re; Guido will need to decide whether to update this or drop it before 2.0.  If it can't be updated before then, it should be dropped as regex is obsolete.

If someone decides to resurrect or replace it with an up to date version at a later time, it can be added back.

Patches to update it would be welcome.  Assigned to Guido for a decision on the disposition of this demo.
-------------------------------------------------------

Date: 2000-Oct-06 10:37
By: gvanrossum

Comment:
There's Demo/tkinter/guido/redemo.py, which uses the "re" module.
I'll move that to Tools/scripts/redemo.py so it will be installed on Windows (in python20\tools\scripts\redemo.py).

Since the regex module is obsolete, I won't bother with regexdemo.py.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115609&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 18:40:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 10:40:13 -0700
Subject: [Python-bugs-list] [Bug #110665] Compiling python on hpux 11.00 with threads (PR#360)
Message-ID: <200010061740.KAA18769@delerium.i.sourceforge.net>

Bug #110665, was updated on 2000-Jul-31 14:12
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: Compiling python on hpux 11.00 with threads (PR#360)

Details: Jitterbug-Id: 360
Submitted-By: philipp.jocham@salomon.at
Date: Fri, 16 Jun 2000 08:47:06 -0400 (EDT)
Version: 1.5.2
OS: HP-UX 11.00


There are two missing details in the configure process to make this work
out of the box.

First: The function 
	pthread_create
isn't found in library libpthread.a but in libcma.a, because
pthread_create is just a macro in sys/pthread.h pointing to 
	__pthread_create_system

After patching ./configure directly and running 
	./configure --with-thread
(now detecting the correct library /usr/lib/libpthread.a) I also
added -lcl to Modules/Makefile at
	LIBS=           -lnet -lnsl -ldld  -lpthread -lcl

otherwise importing of modules with threads didn't work 
(in this case oci_.sl from DCOracle). 

I'm not sure about the correct syntax or wether it's the correct
place and method, but I would suggest a solution like the following
code snippet.

[...]
AC_MSG_CHECKING(for --with-thread)
[...]
AC_DEFINE(_POSIX_THREADS)
LIBS="$LIBS -lpthread -lcl"
LIBOBJS="$LIBOBJS thread.o"], [
AC_CHECK_LIB(pthread, __pthread_create_system, [AC_DEFINE(WITH_THREAD)
[...]

I hope this helps to make installation process smoother.
Fell free to contact me, if there are further questions.
Philipp
-- 
I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.



====================================================================
Audit trail:
Tue Jul 11 08:26:01 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-22 02:56
By: gvanrossum

Comment:
Taking this because I'm considering to redesign the thread configuration section in configure.in anyway -- there's a similar bug report for Alpha OSF1.
-------------------------------------------------------

Date: 2000-Sep-25 06:10
By: gvanrossum

Comment:
I'm hoping that this was fixed by recent changes. Sent an email to the original submittor to verify.
-------------------------------------------------------

Date: 2000-Oct-06 10:40
By: gvanrossum

Comment:
I have two reports from people for whom configure, build and run  with threads now works on HP-UX 10 and 11. I'm not sure what to do about this report... What's different on Philipp's system???
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110665&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 18:41:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 10:41:40 -0700
Subject: [Python-bugs-list] [Bug #110650] [HP-UX] python with-threads core-dumps (PR#342)
Message-ID: <200010061741.KAA18825@delerium.i.sourceforge.net>

Bug #110650, was updated on 2000-Jul-31 14:10
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: [HP-UX] python with-threads core-dumps (PR#342)

Details: Jitterbug-Id: 342
Submitted-By: michael.exner@mrz.uni-magdeburg.de
Date: Wed, 31 May 2000 09:43:38 -0400 (EDT)
Version: 1.5.2
OS: hpux-11.00


When I compile python with threads python core-dumps:
$ ./python
pthread_mutex_init: Invalid argument
Memory fault(coredump)
without thread-support everything works fine
I tried this with hpux-ansi-c and with gcc (2.95.2) but got the same result




====================================================================
Audit trail:
Tue Jul 11 08:25:57 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-28 20:43
By: tim_one

Comment:
Note that the only call to pthread_mutex_init Python makes is in function PyThread_allocate_lock in file phread_pthread.h.  If Python compiled at all, it's extremely unlikely that the first argument is in error.  It's very likely that the second argument is in error, though:  there were many imcompatible revisions of the pthreads std, and pthread_mutexattr_default is a macro conditionally defined near the top of the file.  If this OS actually support pthreads, you have to figure out which *version* of pthreads it defines and arrange for config to define the *correct* one of the

PY_PTHREAD_D4
PY_PTHREAD_D7
PY_PTHREAD_STD
PY_PTHREAD_D6

symbols for your platform.  Else disable threads entirely.
-------------------------------------------------------

Date: 2000-Aug-29 07:34
By: memaul

Comment:
Goto link below for instructions and patches for building
python 152 with threads on hpux 10.20

http://memaul.tripod.com/index.html
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-15 02:34
By: harripasanen

Comment:
I can verify that the bug exists not only in 1.5.2 but also in 1.6.

gcc 2.95.2
HPUX 11.00

I'll see if tim_one's suggestions help.

Regards,

Harri Pasanen
-------------------------------------------------------

Date: 2000-Sep-15 04:55
By: harripasanen

Comment:
The problems seems to be that configure gets the libraries wrong on HP-UX 11.0.   It links with -lcma, when it should link with -lpthread.

So a quick and dirty solution is to relink the python by hand, replacing -lcma with -lpthread.

-------------------------------------------------------

Date: 2000-Sep-15 10:04
By: fdrake

Comment:
Noted that this is HP-UX specific in summary.
-------------------------------------------------------

Date: 2000-Sep-22 03:02
By: gvanrossum

Comment:
Assigned to myself because this is another one about thread configuration on HP-UX, which I plan to tackle. Note that Harri (hi, Harri!) contradicts what another HP-UX bug report (#110665) says -- Harri says you shouldn't link with -lcma, the other says you should. (Or does it? It's ambiguous!)
-------------------------------------------------------

Date: 2000-Sep-25 06:10
By: gvanrossum

Comment:
I'm hoping that this was fixed by recent changes. Sent an email to the original submittor to verify.
-------------------------------------------------------

Date: 2000-Oct-06 10:41
By: gvanrossum

Comment:
Haven't heard back from the original submittor after sending a reminder last week. Closing this -- there's still another HP-UX threads bug report open from a submitter who *did* write back and still has his particular problem.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110650&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 18:42:41 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 10:42:41 -0700
Subject: [Python-bugs-list] [Bug #115690] Dr. Watson error on Python2.0b2 Idle 0.6 WinNT4.0 SP6
Message-ID: <200010061742.KAA27677@bush.i.sourceforge.net>

Bug #115690, was updated on 2000-Sep-29 14:55
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 6
Summary: Dr. Watson error on Python2.0b2 Idle 0.6 WinNT4.0 SP6

Details: I get a Dr. Watson error:

    pythonw.exe
    Exception: access violation (0xc0000005), 
    Address: 0x00e31652

when I run the following code in Idle 0.6, using Edit->Run Script:

---%<---cut---%<---

import unicodedata
for c in range(0x10000):
    x=unichr(c)
    try:
        b = unicodedata.numeric(x)
        #print "numeric:", repr(x)
        try:
            a = unicodedata.digit(x)
            if a != b:
                print "bad" , repr(x)
        except:
            print "Numeric but not digit", hex(c), x.encode("utf8"), \
                  "numeric ->", b
    except:
        pass

---%<---cut---%<---

(This code was recently posted on python-dev)

I've modified my .idle file, adding 

    [EditorWindow]
    font-name=tahoma


Follow-Ups:

Date: 2000-Sep-29 21:42
By: jhylton

Comment:
Marc-Andre can you check whether this is a Unicode bug that is going to come up with or without idle.  If it seems Idle specific, please assign it to Guido or Tim.  If not, it's yours :-).


-------------------------------------------------------

Date: 2000-Oct-03 10:23
By: lemburg

Comment:
I can't reproduce this on Linux, so it seems that it is related to the way TCL/Tk
displays UTF-8 data. Another possibility would be an optimization error
which doesn't happen with gcc.

Tim, could you try this on Windows and possibly tell me where the segfault
occurs in the code ?

-------------------------------------------------------

Date: 2000-Oct-03 11:27
By: gvanrossum

Comment:
Can't reproduce it on Win98SE either. (And I did try setting font-name to tahoma.)
-------------------------------------------------------

Date: 2000-Oct-04 20:42
By: tim_one

Comment:
Assigned back to Guido, because it appears identical to bug 113803, which Guido assigned to himself.

Guido, I can reproduce the problem, and regardless of font (e.g., let it use the default) on Win98SE by letting the program run to completion, and then hitting the ENTER key *twice* (first time gets an IDLE prompt, second time blows up).  It's in exactly the same place then as 113803, trying to decref a NULL pointer in _tkinter.c's AsString.

Note that there *may* be another bug here specific to NT and/or W2K too, in that W9x have much feebler Unicode support.

-------------------------------------------------------

Date: 2000-Oct-06 10:13
By: gvanrossum

Comment:
Fixed the Tkinter bug, so closing this. Please check that this is indeed fixed in the CVS version (or wait for release candidate 1, Monday).
-------------------------------------------------------

Date: 2000-Oct-06 10:42
By: tim_one

Comment:
The crash went away for me (Win98SE, default font), but upon hitting the 2nd RETURN I get a new problem:

>>> Exception in Tkinter callback
Traceback (most recent call last):
  File "c:\code\python\dist\src\lib\lib-tk\Tkinter.py", line 1287, in __call__
    return apply(self.func, args)
  File "../tools/idle\PyShell.py", line 573, in enter_callback
    self.auto.auto_indent(event)
  File "C:\Code\python\dist\src\tools\idle\AutoIndent.py", line 269, in newline_and_indent_event
    c = y.get_continuation_type()
  File "C:\Code\python\dist\src\tools\idle\PyParse.py", line 332, in get_continuation_type
    self._study1()
  File "C:\Code\python\dist\src\tools\idle\PyParse.py", line 220, in _study1
    str = string.translate(str, _tran)
  File "c:\code\python\dist\src\lib\string.py", line 308, in translate
    return s.translate(table, deletions)
TypeError: translate requires exactly 1 argument; 2 given

I'll look into it.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115690&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 18:56:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 10:56:27 -0700
Subject: [Python-bugs-list] [Bug #116251] SRE miscompiles character class containing -
Message-ID: <200010061756.KAA19431@delerium.i.sourceforge.net>

Bug #116251, was updated on 2000-Oct-06 09:12
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: SRE miscompiles character class containing -

Details: (Found by Neil Schemenauer)  Consider this test program:

import re

p = re.compile('[\w]+')
m = p.match('laser_beam')
print m and m.span()

p = re.compile('[\w-]+')
m = p.match('laser_beam')
print m and m.span()

This prints (0,10) and None, but the second pattern just adds a - inside the character class, so it should still match.  Printing the code generated by the two patterns 
shows that they're compiled differently.

(Is there a disassembler for SRE byte code hiding somewhere? 
I'd have dug further if there was...)

Follow-Ups:

Date: 2000-Oct-06 09:22
By: akuchling

Comment:
Found the .dump() method; it seems to me that the pattern is
being tokenized and compiled to a sequence all right.  

Incidentally, [\w+]+ matches correctly, even though
[\w-]+ doesn't.  
-------------------------------------------------------

Date: 2000-Oct-06 10:56
By: akuchling

Comment:
The bug is in sre_parse._parse(); it produces a bad 
parse tree when a category such as \w is followed by -.
Something like \w0- works fine.  Not sure what the fix is...

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116251&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 19:04:41 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 11:04:41 -0700
Subject: [Python-bugs-list] [Bug #116144] Python 2.0b1  hangs
Message-ID: <200010061804.LAA28644@bush.i.sourceforge.net>

Bug #116144, was updated on 2000-Oct-05 08:35
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: Python 2.0b1  hangs

Details: Hi

My python program hangs after a while,  cannot even kill through ^C.  just hangs!

I am running python on the DEC Alpha system.   The program goes through 
a large flat file biological database. Reads entry by entry and prints 
some information after parsing each entry.  (an entry consists of number of lines).
I can give you more detail, if this was an unknown problem.


Ramu


Follow-Ups:

Date: 2000-Oct-05 11:07
By: gvanrossum

Comment:
We definitely need more information! One problem is that we don't have a DEC Alpha system to test on, so we can't easily try if out even if you gave us the source of your script and the input data!

Of course it's also possible that it's a bug in your program, or a change in Python that has nothing to do with DEC Alpha. But we can't tell from what you're saying! Can you reproduce the problem with a small test script? Also, please try if this is still broken with Python 2.0b2.
-------------------------------------------------------

Date: 2000-Oct-06 09:06
By: chennaramu

Comment:
Hi

Thanks for the response.  Actually I tested with  version 1.5.2  1.6  and 2.0b on Dec
machines . Same problem.

I am trying with linux, so far it is running (it will take another 5-7 hours to finish).
If  this succeeds with linux,  I will again try with DEC machine and let you know.

The data file is too large, I can give you ftp address to copy . 

Ramu

-------------------------------------------------------

Date: 2000-Oct-06 10:20
By: gvanrossum

Comment:
So at least show us your code! If you dont' want to make it public, mail it to guido@beopen.com.
-------------------------------------------------------

Date: 2000-Oct-06 11:04
By: tim_one

Comment:
The combination of "parsing" and "can't kill via ^C" suggests it's hung in the bowels of a regexp search (if so, should be reducible to a 1-liner!).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116144&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 19:10:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 11:10:30 -0700
Subject: [Python-bugs-list] [Bug #115690] Dr. Watson error on Python2.0b2 Idle 0.6 WinNT4.0 SP6
Message-ID: <200010061810.LAA28860@bush.i.sourceforge.net>

Bug #115690, was updated on 2000-Sep-29 14:55
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: Dr. Watson error on Python2.0b2 Idle 0.6 WinNT4.0 SP6

Details: I get a Dr. Watson error:

    pythonw.exe
    Exception: access violation (0xc0000005), 
    Address: 0x00e31652

when I run the following code in Idle 0.6, using Edit->Run Script:

---%<---cut---%<---

import unicodedata
for c in range(0x10000):
    x=unichr(c)
    try:
        b = unicodedata.numeric(x)
        #print "numeric:", repr(x)
        try:
            a = unicodedata.digit(x)
            if a != b:
                print "bad" , repr(x)
        except:
            print "Numeric but not digit", hex(c), x.encode("utf8"), \
                  "numeric ->", b
    except:
        pass

---%<---cut---%<---

(This code was recently posted on python-dev)

I've modified my .idle file, adding 

    [EditorWindow]
    font-name=tahoma


Follow-Ups:

Date: 2000-Sep-29 21:42
By: jhylton

Comment:
Marc-Andre can you check whether this is a Unicode bug that is going to come up with or without idle.  If it seems Idle specific, please assign it to Guido or Tim.  If not, it's yours :-).


-------------------------------------------------------

Date: 2000-Oct-03 10:23
By: lemburg

Comment:
I can't reproduce this on Linux, so it seems that it is related to the way TCL/Tk
displays UTF-8 data. Another possibility would be an optimization error
which doesn't happen with gcc.

Tim, could you try this on Windows and possibly tell me where the segfault
occurs in the code ?

-------------------------------------------------------

Date: 2000-Oct-03 11:27
By: gvanrossum

Comment:
Can't reproduce it on Win98SE either. (And I did try setting font-name to tahoma.)
-------------------------------------------------------

Date: 2000-Oct-04 20:42
By: tim_one

Comment:
Assigned back to Guido, because it appears identical to bug 113803, which Guido assigned to himself.

Guido, I can reproduce the problem, and regardless of font (e.g., let it use the default) on Win98SE by letting the program run to completion, and then hitting the ENTER key *twice* (first time gets an IDLE prompt, second time blows up).  It's in exactly the same place then as 113803, trying to decref a NULL pointer in _tkinter.c's AsString.

Note that there *may* be another bug here specific to NT and/or W2K too, in that W9x have much feebler Unicode support.

-------------------------------------------------------

Date: 2000-Oct-06 10:13
By: gvanrossum

Comment:
Fixed the Tkinter bug, so closing this. Please check that this is indeed fixed in the CVS version (or wait for release candidate 1, Monday).
-------------------------------------------------------

Date: 2000-Oct-06 10:42
By: tim_one

Comment:
The crash went away for me (Win98SE, default font), but upon hitting the 2nd RETURN I get a new problem:

>>> Exception in Tkinter callback
Traceback (most recent call last):
  File "c:\code\python\dist\src\lib\lib-tk\Tkinter.py", line 1287, in __call__
    return apply(self.func, args)
  File "../tools/idle\PyShell.py", line 573, in enter_callback
    self.auto.auto_indent(event)
  File "C:\Code\python\dist\src\tools\idle\AutoIndent.py", line 269, in newline_and_indent_event
    c = y.get_continuation_type()
  File "C:\Code\python\dist\src\tools\idle\PyParse.py", line 332, in get_continuation_type
    self._study1()
  File "C:\Code\python\dist\src\tools\idle\PyParse.py", line 220, in _study1
    str = string.translate(str, _tran)
  File "c:\code\python\dist\src\lib\string.py", line 308, in translate
    return s.translate(table, deletions)
TypeError: translate requires exactly 1 argument; 2 given

I'll look into it.
-------------------------------------------------------

Date: 2000-Oct-06 11:10
By: tim_one

Comment:
Reopened this bug, cuz I need another set of eyes!  Guido, does the latest symptom occur for you too (run the program, hit ENTER twice, get a traceback from string.translate)?  The complaint doesn't make sense (the code for string.translate does *not* require exactly 1 arg, and I can't trigger this msg unless I run the test program first).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115690&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 19:17:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 11:17:34 -0700
Subject: [Python-bugs-list] [Bug #116263] Tools/compiler cannot  handle "from foo import *"
Message-ID: <200010061817.LAA29132@bush.i.sourceforge.net>

Bug #116263, was updated on 2000-Oct-06 11:17
Here is a current snapshot of the bug.

Project: Python
Category: demos and tools
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Tools/compiler cannot  handle "from foo import *"

Details: Try compiling a file containing "from types import *" to see the
traceback.  The compiler does not seem to know about the 
IMPORT_STAR opcode.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116263&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 19:19:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 11:19:50 -0700
Subject: [Python-bugs-list] [Bug #116263] Tools/compiler cannot  handle "from foo import *"
Message-ID: <200010061819.LAA29277@bush.i.sourceforge.net>

Bug #116263, was updated on 2000-Oct-06 11:17
Here is a current snapshot of the bug.

Project: Python
Category: demos and tools
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Tools/compiler cannot  handle "from foo import *"

Details: Try compiling a file containing "from types import *" to see the
traceback.  The compiler does not seem to know about the 
IMPORT_STAR opcode.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116263&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 19:25:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 11:25:45 -0700
Subject: [Python-bugs-list] [Bug #116251] SRE miscompiles character class containing -
Message-ID: <200010061825.LAA29494@bush.i.sourceforge.net>

Bug #116251, was updated on 2000-Oct-06 09:12
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: SRE miscompiles character class containing -

Details: (Found by Neil Schemenauer)  Consider this test program:

import re

p = re.compile('[\w]+')
m = p.match('laser_beam')
print m and m.span()

p = re.compile('[\w-]+')
m = p.match('laser_beam')
print m and m.span()

This prints (0,10) and None, but the second pattern just adds a - inside the character class, so it should still match.  Printing the code generated by the two patterns 
shows that they're compiled differently.

(Is there a disassembler for SRE byte code hiding somewhere? 
I'd have dug further if there was...)

Follow-Ups:

Date: 2000-Oct-06 09:22
By: akuchling

Comment:
Found the .dump() method; it seems to me that the pattern is
being tokenized and compiled to a sequence all right.  

Incidentally, [\w+]+ matches correctly, even though
[\w-]+ doesn't.  
-------------------------------------------------------

Date: 2000-Oct-06 10:56
By: akuchling

Comment:
The bug is in sre_parse._parse(); it produces a bad 
parse tree when a category such as \w is followed by -.
Something like \w0- works fine.  Not sure what the fix is...

-------------------------------------------------------

Date: 2000-Oct-06 11:25
By: akuchling

Comment:
Proposed 2-line patch submitted as patch #101807.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116251&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 19:26:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 11:26:20 -0700
Subject: [Python-bugs-list] [Bug #116172] 2.0b2 curses module fails to build on SGI
Message-ID: <200010061826.LAA20698@delerium.i.sourceforge.net>

Bug #116172, was updated on 2000-Oct-05 12:40
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: 2.0b2 curses module fails to build on SGI

Details: I didn't see this in the database.

Trying to build 2.0b2 here on SGI IRIX 6.5.  I have this
line in Setup:

     _curses _cursesmodule.c -lcurses -ltermcap

This used to work on 1.5.2 on IRIX 6.5, but it doesn't with 2.0b2.

Here is a digested version of the errors:

cc -n32  -O -KPIC -I./../Include -I.. -DHAVE_CONFIG_H -c ./_cursesmodule.c
...
  The identifier "attr_t" is undefined.
  The identifier "ACS_S3" is undefined.
  The identifier "ACS_LEQUAL" is undefined.
  The identifier "ACS_GEQUAL" is undefined.
  The identifier "ACS_PI" is undefined.
  The identifier "ACS_NEQUAL" is undefined.
  The identifier "ACS_STERLING" is undefined.
  A value of type "int" cannot be assigned to an entity of type "char *".
        capname = tigetstr( capname );
                ^
  The identifier "A_HORIZONTAL" is undefined.
  The identifier "A_LEFT" is undefined.
  The identifier "A_LOW" is undefined.
  The identifier "A_RIGHT" is undefined.
  The identifier "A_TOP" is undefined.
  The identifier "A_VERTICAL" is undefined.


Follow-Ups:

Date: 2000-Oct-06 07:50
By: gvanrossum

Comment:
I don't know, but I think this may be caused by IRIX having an old, incompatible version of curses. So it probably won't work. Too bad. You may be able to get a different curses implementation (there must be a free one that comes with Linux???).
-------------------------------------------------------

Date: 2000-Oct-06 08:42
By: jhylton

Comment:
Eric, can you look at this today?
-------------------------------------------------------

Date: 2000-Oct-06 11:26
By: VizNut

Comment:
A quick grep reveals Sun Solaris 7 doesn't have them either.

If the intent is to break with standard curses, to avoid confusion it might be best to rename the module from curses to "linux_curses" or "ncurses" (if that's the appropriate curses variety).

Thanks,

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116172&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 19:37:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 11:37:39 -0700
Subject: [Python-bugs-list] [Bug #116267] zlib.decompress memory allocation "infinite" loop
Message-ID: <200010061837.LAA29924@bush.i.sourceforge.net>

Bug #116267, was updated on 2000-Oct-06 11:37
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: zlib.decompress memory allocation "infinite" loop

Details: Either of the following will cause Python to enter into a loop in which it progressively allocates more and more memory until it eventually generaes an out of memory error (or, under Win9X, the machine becomes unusable):

import zlib

s = zlib.decompress('')
s = zlib.decompress('\010')

There are probably many other strings which, when passed to decompress, will cause Python to enter this loop.  The problem appears to be that the inflate function (in the zlib library) will return Z_BUF_ERROR both for an invalid input buffer and if there is not enough space in the output buffer.  However, zlibmodule.c assumes Z_BUF_ERROR always means the output buffer is too small, so it keeps allocating a larger one.  I reported this error on the python-list mailing list and received a reply with the following patch (which I have updated so that it applies to the zlibmodule.c which comes with Python 2.0b2).  I have not actually applied or tested this patch (that's why I'm not submitting it as a patch), but it looks like it should solve the problem:

*** zlibmodule.c.orig	Wed Aug 02 19:04:04 2000
--- zlibmodule.c	Fri Oct 06 10:58:22 2000
***************
*** 213,219 ****
          {
          case(Z_STREAM_END):
  	    break;
! 	case(Z_BUF_ERROR):
          case(Z_OK):
  	    /* need more memory */
  	    if (_PyString_Resize(&result_str, r_strlen << 1) == -1)
--- 213,232 ----
          {
          case(Z_STREAM_END):
  	    break;
!         case(Z_BUF_ERROR):
! 	    /*
! 	     * If there is at least 1 byte of room in zst.next_out
! 	     * and get this error, I assume that it means zlib cannot
! 	     * process inflate.
! 	     */
! 	    if (0 < zst.avail_out)
! 	    {
! 	      PyErr_Format(ZlibError, "Error %i while decompressing data",
! 	                   err);
! 	      inflateEnd(&zst);
! 	      Py_DECREF(result_str);
! 	      return NULL;
! 	    }
          case(Z_OK):
  	    /* need more memory */
  	    if (_PyString_Resize(&result_str, r_strlen << 1) == -1)


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116267&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 19:38:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 11:38:38 -0700
Subject: [Python-bugs-list] [Bug #115690] Dr. Watson error on Python2.0b2 Idle 0.6 WinNT4.0 SP6
Message-ID: <200010061838.LAA21128@delerium.i.sourceforge.net>

Bug #115690, was updated on 2000-Sep-29 14:55
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: Dr. Watson error on Python2.0b2 Idle 0.6 WinNT4.0 SP6

Details: I get a Dr. Watson error:

    pythonw.exe
    Exception: access violation (0xc0000005), 
    Address: 0x00e31652

when I run the following code in Idle 0.6, using Edit->Run Script:

---%<---cut---%<---

import unicodedata
for c in range(0x10000):
    x=unichr(c)
    try:
        b = unicodedata.numeric(x)
        #print "numeric:", repr(x)
        try:
            a = unicodedata.digit(x)
            if a != b:
                print "bad" , repr(x)
        except:
            print "Numeric but not digit", hex(c), x.encode("utf8"), \
                  "numeric ->", b
    except:
        pass

---%<---cut---%<---

(This code was recently posted on python-dev)

I've modified my .idle file, adding 

    [EditorWindow]
    font-name=tahoma


Follow-Ups:

Date: 2000-Sep-29 21:42
By: jhylton

Comment:
Marc-Andre can you check whether this is a Unicode bug that is going to come up with or without idle.  If it seems Idle specific, please assign it to Guido or Tim.  If not, it's yours :-).


-------------------------------------------------------

Date: 2000-Oct-03 10:23
By: lemburg

Comment:
I can't reproduce this on Linux, so it seems that it is related to the way TCL/Tk
displays UTF-8 data. Another possibility would be an optimization error
which doesn't happen with gcc.

Tim, could you try this on Windows and possibly tell me where the segfault
occurs in the code ?

-------------------------------------------------------

Date: 2000-Oct-03 11:27
By: gvanrossum

Comment:
Can't reproduce it on Win98SE either. (And I did try setting font-name to tahoma.)
-------------------------------------------------------

Date: 2000-Oct-04 20:42
By: tim_one

Comment:
Assigned back to Guido, because it appears identical to bug 113803, which Guido assigned to himself.

Guido, I can reproduce the problem, and regardless of font (e.g., let it use the default) on Win98SE by letting the program run to completion, and then hitting the ENTER key *twice* (first time gets an IDLE prompt, second time blows up).  It's in exactly the same place then as 113803, trying to decref a NULL pointer in _tkinter.c's AsString.

Note that there *may* be another bug here specific to NT and/or W2K too, in that W9x have much feebler Unicode support.

-------------------------------------------------------

Date: 2000-Oct-06 10:13
By: gvanrossum

Comment:
Fixed the Tkinter bug, so closing this. Please check that this is indeed fixed in the CVS version (or wait for release candidate 1, Monday).
-------------------------------------------------------

Date: 2000-Oct-06 10:42
By: tim_one

Comment:
The crash went away for me (Win98SE, default font), but upon hitting the 2nd RETURN I get a new problem:

>>> Exception in Tkinter callback
Traceback (most recent call last):
  File "c:\code\python\dist\src\lib\lib-tk\Tkinter.py", line 1287, in __call__
    return apply(self.func, args)
  File "../tools/idle\PyShell.py", line 573, in enter_callback
    self.auto.auto_indent(event)
  File "C:\Code\python\dist\src\tools\idle\AutoIndent.py", line 269, in newline_and_indent_event
    c = y.get_continuation_type()
  File "C:\Code\python\dist\src\tools\idle\PyParse.py", line 332, in get_continuation_type
    self._study1()
  File "C:\Code\python\dist\src\tools\idle\PyParse.py", line 220, in _study1
    str = string.translate(str, _tran)
  File "c:\code\python\dist\src\lib\string.py", line 308, in translate
    return s.translate(table, deletions)
TypeError: translate requires exactly 1 argument; 2 given

I'll look into it.
-------------------------------------------------------

Date: 2000-Oct-06 11:10
By: tim_one

Comment:
Reopened this bug, cuz I need another set of eyes!  Guido, does the latest symptom occur for you too (run the program, hit ENTER twice, get a traceback from string.translate)?  The complaint doesn't make sense (the code for string.translate does *not* require exactly 1 arg, and I can't trigger this msg unless I run the test program first).
-------------------------------------------------------

Date: 2000-Oct-06 11:38
By: tim_one

Comment:
*Something* is really hosed here.  We haven't even entered stringobject.c's string_translate by the time the traceback is generated (I know that because I set a breakpoint there and it wasn't hit).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115690&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 19:57:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 11:57:44 -0700
Subject: [Python-bugs-list] [Bug #115690] Dr. Watson error on Python2.0b2 Idle 0.6 WinNT4.0 SP6
Message-ID: <200010061857.LAA21924@delerium.i.sourceforge.net>

Bug #115690, was updated on 2000-Sep-29 14:55
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: Dr. Watson error on Python2.0b2 Idle 0.6 WinNT4.0 SP6

Details: I get a Dr. Watson error:

    pythonw.exe
    Exception: access violation (0xc0000005), 
    Address: 0x00e31652

when I run the following code in Idle 0.6, using Edit->Run Script:

---%<---cut---%<---

import unicodedata
for c in range(0x10000):
    x=unichr(c)
    try:
        b = unicodedata.numeric(x)
        #print "numeric:", repr(x)
        try:
            a = unicodedata.digit(x)
            if a != b:
                print "bad" , repr(x)
        except:
            print "Numeric but not digit", hex(c), x.encode("utf8"), \
                  "numeric ->", b
    except:
        pass

---%<---cut---%<---

(This code was recently posted on python-dev)

I've modified my .idle file, adding 

    [EditorWindow]
    font-name=tahoma


Follow-Ups:

Date: 2000-Sep-29 21:42
By: jhylton

Comment:
Marc-Andre can you check whether this is a Unicode bug that is going to come up with or without idle.  If it seems Idle specific, please assign it to Guido or Tim.  If not, it's yours :-).


-------------------------------------------------------

Date: 2000-Oct-03 10:23
By: lemburg

Comment:
I can't reproduce this on Linux, so it seems that it is related to the way TCL/Tk
displays UTF-8 data. Another possibility would be an optimization error
which doesn't happen with gcc.

Tim, could you try this on Windows and possibly tell me where the segfault
occurs in the code ?

-------------------------------------------------------

Date: 2000-Oct-03 11:27
By: gvanrossum

Comment:
Can't reproduce it on Win98SE either. (And I did try setting font-name to tahoma.)
-------------------------------------------------------

Date: 2000-Oct-04 20:42
By: tim_one

Comment:
Assigned back to Guido, because it appears identical to bug 113803, which Guido assigned to himself.

Guido, I can reproduce the problem, and regardless of font (e.g., let it use the default) on Win98SE by letting the program run to completion, and then hitting the ENTER key *twice* (first time gets an IDLE prompt, second time blows up).  It's in exactly the same place then as 113803, trying to decref a NULL pointer in _tkinter.c's AsString.

Note that there *may* be another bug here specific to NT and/or W2K too, in that W9x have much feebler Unicode support.

-------------------------------------------------------

Date: 2000-Oct-06 10:13
By: gvanrossum

Comment:
Fixed the Tkinter bug, so closing this. Please check that this is indeed fixed in the CVS version (or wait for release candidate 1, Monday).
-------------------------------------------------------

Date: 2000-Oct-06 10:42
By: tim_one

Comment:
The crash went away for me (Win98SE, default font), but upon hitting the 2nd RETURN I get a new problem:

>>> Exception in Tkinter callback
Traceback (most recent call last):
  File "c:\code\python\dist\src\lib\lib-tk\Tkinter.py", line 1287, in __call__
    return apply(self.func, args)
  File "../tools/idle\PyShell.py", line 573, in enter_callback
    self.auto.auto_indent(event)
  File "C:\Code\python\dist\src\tools\idle\AutoIndent.py", line 269, in newline_and_indent_event
    c = y.get_continuation_type()
  File "C:\Code\python\dist\src\tools\idle\PyParse.py", line 332, in get_continuation_type
    self._study1()
  File "C:\Code\python\dist\src\tools\idle\PyParse.py", line 220, in _study1
    str = string.translate(str, _tran)
  File "c:\code\python\dist\src\lib\string.py", line 308, in translate
    return s.translate(table, deletions)
TypeError: translate requires exactly 1 argument; 2 given

I'll look into it.
-------------------------------------------------------

Date: 2000-Oct-06 11:10
By: tim_one

Comment:
Reopened this bug, cuz I need another set of eyes!  Guido, does the latest symptom occur for you too (run the program, hit ENTER twice, get a traceback from string.translate)?  The complaint doesn't make sense (the code for string.translate does *not* require exactly 1 arg, and I can't trigger this msg unless I run the test program first).
-------------------------------------------------------

Date: 2000-Oct-06 11:38
By: tim_one

Comment:
*Something* is really hosed here.  We haven't even entered stringobject.c's string_translate by the time the traceback is generated (I know that because I set a breakpoint there and it wasn't hit).
-------------------------------------------------------

Date: 2000-Oct-06 11:57
By: gvanrossum

Comment:
Betcha it's a Unicode object! There, translate() only takes 1 arg.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115690&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 20:00:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 12:00:12 -0700
Subject: [Python-bugs-list] [Bug #114756] test_linuxaudiodev uses wrong format
Message-ID: <200010061900.MAA30877@bush.i.sourceforge.net>

Bug #114756, was updated on 2000-Sep-18 16:50
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: test_linuxaudiodev uses wrong format

Details: test_linuxaudiodev sounds *horrible*.  This has come up several times on python-dev, but nobody seems to have a fix that works -- or at least nothing has been checked in, so I'm contributing this bug report to the collective memory.

Here's how the bug manifests on my machine (a Dell Dimension with built-in sound hardware [Yamaha YMF-724F], using ALSA 0.5.8a drivers in a 2.2.14 kernel):

$ ./python Lib/test/test_linuxaudiodev.py
plays the entire sample without complaint, but it sounds *horrible* -- apparently because it's treating an .au file incorrectly.

See also my python-dev post of 29 June 2000: http://www.python.org/pipermail/python-dev/2000-June/011808.html

Ping suggested setting AUDIODEV=/dev/audio before running the script, and Michael Hudson contributed an alternate version of the test script which writes to /dev/audio (same idea, no environment variable needed).  Either of these fixes has the same result:

$ ./python Lib/test/test_linuxaudiodev-hudson.py
Traceback (most recent call last):
  File "Lib/test/test_linuxaudiodev-hudson.py", line 62, in ?
    test()
  File "Lib/test/test_linuxaudiodev-hudson.py", line 60, in test
    play_au_file(findfile('audiotest.au'))
  File "Lib/test/test_linuxaudiodev-hudson.py", line 55, in play_au_file
    dsp.write(data)
linuxaudiodev.error: (11, 'Resource temporarily unavailable')

The traceback appears immediately, but the script keeps running while the sample plays -- well, about half of it.  The sample is cut off midway through, and my shell prompt returns.

Finally, Ping posted another variation on the test script (http://www.python.org/pipermail/python-dev/2000-June/011834.html) which does not work at all for me:
$ ./python Lib/test/test_linuxaudiodev-ping.py
Traceback (most recent call last):
  File "Lib/test/test_linuxaudiodev-ping.py", line 37, in ?
    test()
  File "Lib/test/test_linuxaudiodev-ping.py", line 35, in test
    play_au_file(findfile('audiotest.au'))
  File "Lib/test/test_linuxaudiodev-ping.py", line 26, in play_au_file
    raise "audio format not supported by linuxaudiodev"
audio format not supported by linuxaudiodev

No sound at all from this one.

Charles Waldman <cgw@fnal.gov> also took a look at linuxaudiodev.c and didn't like what he found: http://www.python.org/pipermail/python-dev/2000-August/015746.html; Charles has said he's working on a rewrite of this module.



Follow-Ups:

Date: 2000-Sep-18 21:13
By: gvanrossum

Comment:
You do have a sound card, don't you, Jeremy?
-------------------------------------------------------

Date: 2000-Oct-06 12:00
By: jhylton

Comment:
I just read the Open Sound System Programmer's Guide from www.opensound.com.  It gives me the impression that the sample sounds horrible because Linux doesn't support the 8-bit mu-law format natively.  Instead it is emulating that format in software.

Regardless of whether it sounds horrible, I don't hear it at all when I run the test suite because the test script calls close() immediately -- before the kernel has a chance to dump any data from the audio buffer to the device.

On top of all that, the code had many other problems, including lots of calls to PyErr_SetFromErrno when errno was not set!

I have a fix that will be checked in soon, but it will need to be tested by other Linux users.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114756&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 20:07:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 12:07:16 -0700
Subject: [Python-bugs-list] [Bug #116267] zlib.decompress memory allocation "infinite" loop
Message-ID: <200010061907.MAA31115@bush.i.sourceforge.net>

Bug #116267, was updated on 2000-Oct-06 11:37
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: zlib.decompress memory allocation "infinite" loop

Details: Either of the following will cause Python to enter into a loop in which it progressively allocates more and more memory until it eventually generaes an out of memory error (or, under Win9X, the machine becomes unusable):

import zlib

s = zlib.decompress('')
s = zlib.decompress('\010')

There are probably many other strings which, when passed to decompress, will cause Python to enter this loop.  The problem appears to be that the inflate function (in the zlib library) will return Z_BUF_ERROR both for an invalid input buffer and if there is not enough space in the output buffer.  However, zlibmodule.c assumes Z_BUF_ERROR always means the output buffer is too small, so it keeps allocating a larger one.  I reported this error on the python-list mailing list and received a reply with the following patch (which I have updated so that it applies to the zlibmodule.c which comes with Python 2.0b2).  I have not actually applied or tested this patch (that's why I'm not submitting it as a patch), but it looks like it should solve the problem:

*** zlibmodule.c.orig	Wed Aug 02 19:04:04 2000
--- zlibmodule.c	Fri Oct 06 10:58:22 2000
***************
*** 213,219 ****
          {
          case(Z_STREAM_END):
  	    break;
! 	case(Z_BUF_ERROR):
          case(Z_OK):
  	    /* need more memory */
  	    if (_PyString_Resize(&result_str, r_strlen << 1) == -1)
--- 213,232 ----
          {
          case(Z_STREAM_END):
  	    break;
!         case(Z_BUF_ERROR):
! 	    /*
! 	     * If there is at least 1 byte of room in zst.next_out
! 	     * and get this error, I assume that it means zlib cannot
! 	     * process inflate.
! 	     */
! 	    if (0 < zst.avail_out)
! 	    {
! 	      PyErr_Format(ZlibError, "Error %i while decompressing data",
! 	                   err);
! 	      inflateEnd(&zst);
! 	      Py_DECREF(result_str);
! 	      return NULL;
! 	    }
          case(Z_OK):
  	    /* need more memory */
  	    if (_PyString_Resize(&result_str, r_strlen << 1) == -1)


Follow-Ups:

Date: 2000-Oct-06 12:07
By: jhylton

Comment:
Andrew, do you have time to look at this today?  If not, bounce it back to me.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116267&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 20:08:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 12:08:30 -0700
Subject: [Python-bugs-list] [Bug #116255] 2.0b2:  LDSHARED incorrect on SGI IRIX
Message-ID: <200010061908.MAA31166@bush.i.sourceforge.net>

Bug #116255, was updated on 2000-Oct-06 10:06
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 2.0b2:  LDSHARED incorrect on SGI IRIX

Details: I think that's the problem.  But someone versed in Python Distutils will have to judge whether my fix is the right one.

NumPy 17.0 fails to build for me on 2.0b2 on IRIX 6.5.  This patch to the Python 2.0b2 installed tree fixes it and let's NumPy build correctly on IRIX.

config/Makefile:
-LDSHARED=       ld
+LDSHARED=       ld -shared $(LDFLAGS)

------------------------------------------------------------
Here is more detail on the error and the fix:

The NumPy build (for the latest version) fails on IRIX.

  cc -n32 -O ... 
  cc -n32 -O ... 
  ... 
  ld <list of .o's> -o build/lib.irix64-6.5-2.0/_numpy.so 

  ld: FATAL 12 : Expecting o32 objects:  
  build/temp.irix64-6.5-2.0/Src/_numpymodule.o is n32. 

There are two things failing the NumPy build. First, the ld invocation (in Distutils I assume) isn't specifying $LDFLAGS on the invocation line (which contains -n32), and second the ld invocation isn't specifying -shared.  The former is needed so the linker links a file with the same architecture as the source files it compiles; the latter is needed in order to build a shared object.

Thanks,

Randall



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116255&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 20:23:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 12:23:17 -0700
Subject: [Python-bugs-list] [Bug #114598] Blue Screen crash, popen, Win98, Norton Antivirus 2000
Message-ID: <200010061923.MAA22942@delerium.i.sourceforge.net>

Bug #114598, was updated on 2000-Sep-16 13:24
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 3
Summary: Blue Screen crash, popen, Win98, Norton Antivirus 2000

Details: On Windows 98, all of the os.popen*() functions cause a hard "blue screen" crash requiring a reboot, when Nortin Antivirus 2000 is installed and enabled. (Not with Norton Antivirus version 5, not on Windows 2000.)

While this is probably a bug in Norton Antivirus 2000, and we're already warning for this on the download page, that's not enough (we've seen at least one report in the newsgroup), and it would be good if we could somehow prevent it. Even a call to Py_FatalError is better than the blue screen, and raising os.error would be a *lot* better.

Follow-Ups:

Date: 2000-Sep-16 14:26
By: tim_one

Comment:
I don't know how to stop this.  Pissed away an hour trying to get help on the Symantec site, and eventually found a support board to which I posted this msg:

Product: Norton AntiVirus 2000 6.0 for Windows 95/98/NT
Supported operating system: Windows 98
Action: Run Another Program
Error Message: 
Summary: Blue screen crash

I develop the Windows version of the core Python language. Several reports of blue-screen death on Win98 have been traced to NAV2000.  Here's the exact msg from one such:

An exception 0E has occurred at 0028:C02AD9D0 in VxD IFSMGR(04) + 000050E4. This was called from 0028:C000B511 in VxD VMM(01) + 0000A511. It may be possible to continue normally.

This occurs whenever a user executes a member of the popen family of functions from within Python; for example, this Python program:

import os
p = os.popen("dir")

popen is a std C library function, poorly implemented by Microsoft, but not *that* poorly <wink>.

You can get our latest installer here:

http://www.pythonlabs.com/tech/python2.0/download.html

As the warning there says:

-----------------
Incompatibility warning: Norton Antivirus 2000 can cause blue screen crashes on Windows 98 when a function in the os.popen*() family is invoked. To prevent this problem, disable Norton Antivirus when using Python. (Confirmed on Windows 98 Second Edition with Norton Antivirus version 6.10.20. The same Norton Antivirus version doesn't have this
problem on Windows 2000. Norton Antivirus version 5 on Windows 98SE doesn't have this problem either.) 
-----------------

ActiveState is seeing the same problem with their derivative work ActivePython, as is PythonWare with their derivative work PythonWorks. So this affects a lot of people. A recent change to the implementation of a popular library module has made it acutely visible recently (didn't use to use popen, but does now).

A workaround would be nice. More importantly, how can I *detect* whether an affected version of NAV is in use, so that we can shut down Python gracefully with an appropriate message before executing any of the popen functions that throw NAV into blue-screen territory? We try to be a very user-friendly language, and we'll do anything to prevent a crash. Alas, right now I don't know how to stop it.

-------------------------------------------------------

Date: 2000-Sep-19 02:21
By: tim_one

Comment:
1. Sent Guido a small self-contained C program in the hope that it's enough to provoke the problem by itself.  Reassigned this bug to Guido since he has to tell me what happens with that next (then assign back to me).

2. That's because Symantec is being no help at all.  They suggest upgrading to NAV 2001(!).  If I can post a tiny C program, maybe it will embarrass then into doing something.  You can follow this soap opera at:

http://servicenews.symantec.com/cgi-bin/displayArticle.cgi?group=symantec.support.win9x.nortonantivirus2000.general&article=57765

-------------------------------------------------------

Date: 2000-Sep-19 09:06
By: gvanrossum

Comment:
Tim's little C program crashes in the same way as Python when NAV2000 is enabled. back to Tim...
-------------------------------------------------------

Date: 2000-Sep-21 11:32
By: tim_one

Comment:
I cranked up my obnoxiousness level on the Symantec board (URL two comments down), and they may be on the edge of taking this seriously now.
-------------------------------------------------------

Date: 2000-Sep-22 20:46
By: tim_one

Comment:
Reduced the priority a notch.  The biggest trigger here was IDLE's use of os.popen (indirectly via webbrowser.py) to launch the Python HTML docs.  I put in a new Windows function (os.startfile) that uses Win32 ShellExecute instead, and changed webbrowser.py to use that.  IDLE now lives peacefully with NAV 6.10.20.

This was all Guido's idea, and he suggested that the priority of this bug should be dropped now.
-------------------------------------------------------

Date: 2000-Oct-06 12:23
By: gvanrossum

Comment:
Reduced priority even more. There's not much else we can do about this, it seems, except yell at Norton. :-(
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114598&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 20:27:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 12:27:50 -0700
Subject: [Python-bugs-list] [Bug #115530] cStringIO.StringIO() doesn't raise ValueError when closed
Message-ID: <200010061927.MAA31975@bush.i.sourceforge.net>

Bug #115530, was updated on 2000-Sep-27 20:48
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: cStringIO.StringIO() doesn't raise ValueError when closed

Details: When write() is called on a closed StringO instance, ValueError should be raised.  Other methods should be checked for this as well.

>>> import cStringIO, StringIO
>>> f = cStringIO.StringIO()
>>> f.close()
>>> f.write('')

>>> f = StringIO.StringIO()    
>>> f.close()
>>> f.write('')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "./../Lib/StringIO.py", line 119, in write
    raise ValueError, "I/O operation on closed file"
ValueError: I/O operation on closed file

>>> f = open('junk.txt', 'w')
>>> f.close()
>>> f.write('abc')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: I/O operation on closed file

Assigned to Ken since he works at Digital Creations and can pester Jim Fulton about this.

Follow-Ups:

Date: 2000-Sep-27 20:53
By: fdrake

Comment:
Oops -- fixed summary to refer to the proper exception.
-------------------------------------------------------

Date: 2000-Sep-27 21:27
By: fdrake

Comment:
A simple test for this is commented out in Lib/test/test_StringIO.py; please uncomment and regenerate output when fixing this bug.
-------------------------------------------------------

Date: 2000-Sep-30 07:29
By: loewis

Comment:
A patch is in http://sourceforge.net/patch/?func=detailpatch&patch_id=101721&group_id=5470

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115530&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 20:30:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 12:30:44 -0700
Subject: [Python-bugs-list] [Bug #115531] cStringIO truncate() doesn't support size parameter
Message-ID: <200010061930.MAA32129@bush.i.sourceforge.net>

Bug #115531, was updated on 2000-Sep-27 20:57
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: cStringIO truncate() doesn't support size parameter

Details: The truncate() method doesn't handle the optional size parameter to truncate, nor does it check its parameters in any way.  Many (all?) methods don't check arguments when they don't expect any.

Assigned to Ken because he works at Digital Creations and can pester Jim about this.

Follow-Ups:

Date: 2000-Sep-27 21:27
By: fdrake

Comment:
A simple test for this is commented out in Lib/test/test_StringIO.py; please uncomment and regenerate output when fixing this bug.
-------------------------------------------------------

Date: 2000-Sep-30 09:27
By: loewis

Comment:
A patch for that is in http://sourceforge.net/patch/?func=detailpatch&patch_id=101721&group_id=5470
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115531&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 20:33:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 12:33:38 -0700
Subject: [Python-bugs-list] [Bug #115690] Dr. Watson error on Python2.0b2 Idle 0.6 WinNT4.0 SP6
Message-ID: <200010061933.MAA23323@delerium.i.sourceforge.net>

Bug #115690, was updated on 2000-Sep-29 14:55
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: Dr. Watson error on Python2.0b2 Idle 0.6 WinNT4.0 SP6

Details: I get a Dr. Watson error:

    pythonw.exe
    Exception: access violation (0xc0000005), 
    Address: 0x00e31652

when I run the following code in Idle 0.6, using Edit->Run Script:

---%<---cut---%<---

import unicodedata
for c in range(0x10000):
    x=unichr(c)
    try:
        b = unicodedata.numeric(x)
        #print "numeric:", repr(x)
        try:
            a = unicodedata.digit(x)
            if a != b:
                print "bad" , repr(x)
        except:
            print "Numeric but not digit", hex(c), x.encode("utf8"), \
                  "numeric ->", b
    except:
        pass

---%<---cut---%<---

(This code was recently posted on python-dev)

I've modified my .idle file, adding 

    [EditorWindow]
    font-name=tahoma


Follow-Ups:

Date: 2000-Sep-29 21:42
By: jhylton

Comment:
Marc-Andre can you check whether this is a Unicode bug that is going to come up with or without idle.  If it seems Idle specific, please assign it to Guido or Tim.  If not, it's yours :-).


-------------------------------------------------------

Date: 2000-Oct-03 10:23
By: lemburg

Comment:
I can't reproduce this on Linux, so it seems that it is related to the way TCL/Tk
displays UTF-8 data. Another possibility would be an optimization error
which doesn't happen with gcc.

Tim, could you try this on Windows and possibly tell me where the segfault
occurs in the code ?

-------------------------------------------------------

Date: 2000-Oct-03 11:27
By: gvanrossum

Comment:
Can't reproduce it on Win98SE either. (And I did try setting font-name to tahoma.)
-------------------------------------------------------

Date: 2000-Oct-04 20:42
By: tim_one

Comment:
Assigned back to Guido, because it appears identical to bug 113803, which Guido assigned to himself.

Guido, I can reproduce the problem, and regardless of font (e.g., let it use the default) on Win98SE by letting the program run to completion, and then hitting the ENTER key *twice* (first time gets an IDLE prompt, second time blows up).  It's in exactly the same place then as 113803, trying to decref a NULL pointer in _tkinter.c's AsString.

Note that there *may* be another bug here specific to NT and/or W2K too, in that W9x have much feebler Unicode support.

-------------------------------------------------------

Date: 2000-Oct-06 10:13
By: gvanrossum

Comment:
Fixed the Tkinter bug, so closing this. Please check that this is indeed fixed in the CVS version (or wait for release candidate 1, Monday).
-------------------------------------------------------

Date: 2000-Oct-06 10:42
By: tim_one

Comment:
The crash went away for me (Win98SE, default font), but upon hitting the 2nd RETURN I get a new problem:

>>> Exception in Tkinter callback
Traceback (most recent call last):
  File "c:\code\python\dist\src\lib\lib-tk\Tkinter.py", line 1287, in __call__
    return apply(self.func, args)
  File "../tools/idle\PyShell.py", line 573, in enter_callback
    self.auto.auto_indent(event)
  File "C:\Code\python\dist\src\tools\idle\AutoIndent.py", line 269, in newline_and_indent_event
    c = y.get_continuation_type()
  File "C:\Code\python\dist\src\tools\idle\PyParse.py", line 332, in get_continuation_type
    self._study1()
  File "C:\Code\python\dist\src\tools\idle\PyParse.py", line 220, in _study1
    str = string.translate(str, _tran)
  File "c:\code\python\dist\src\lib\string.py", line 308, in translate
    return s.translate(table, deletions)
TypeError: translate requires exactly 1 argument; 2 given

I'll look into it.
-------------------------------------------------------

Date: 2000-Oct-06 11:10
By: tim_one

Comment:
Reopened this bug, cuz I need another set of eyes!  Guido, does the latest symptom occur for you too (run the program, hit ENTER twice, get a traceback from string.translate)?  The complaint doesn't make sense (the code for string.translate does *not* require exactly 1 arg, and I can't trigger this msg unless I run the test program first).
-------------------------------------------------------

Date: 2000-Oct-06 11:38
By: tim_one

Comment:
*Something* is really hosed here.  We haven't even entered stringobject.c's string_translate by the time the traceback is generated (I know that because I set a breakpoint there and it wasn't hit).
-------------------------------------------------------

Date: 2000-Oct-06 11:57
By: gvanrossum

Comment:
Betcha it's a Unicode object! There, translate() only takes 1 arg.
-------------------------------------------------------

Date: 2000-Oct-06 12:33
By: gvanrossum

Comment:
I think I understand what's going on, but I don't want to fix it. It's actually in a piece of IDLE that Tim hacked long ago! The VC++ debugger is quite useless in figuring this out, but if you use the IDLE stack viewer you can track exactly what happens.

- string.translate() gets called with a Unicode string arg -- this causes the crash.

- This is because self.str is u'\012'. That seems to have been extracted from the text buffer. I'm not quite sure how, but

- a few calls further up the stack, AutoIndent.newline_and_indent() seems to have extracted the last non-blank line from the PyShell outbut buffer, which happens to contain a Unicode character.

- I can reproduce this quite easily by something like 
   >>> print u"\u1234".encode("utf8")
and then hit return twice.

Back to Tim!


-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115690&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 20:52:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 12:52:35 -0700
Subject: [Python-bugs-list] [Bug #116267] zlib.decompress memory allocation "infinite" loop
Message-ID: <200010061952.MAA24138@delerium.i.sourceforge.net>

Bug #116267, was updated on 2000-Oct-06 11:37
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: zlib.decompress memory allocation "infinite" loop

Details: Either of the following will cause Python to enter into a loop in which it progressively allocates more and more memory until it eventually generaes an out of memory error (or, under Win9X, the machine becomes unusable):

import zlib

s = zlib.decompress('')
s = zlib.decompress('\010')

There are probably many other strings which, when passed to decompress, will cause Python to enter this loop.  The problem appears to be that the inflate function (in the zlib library) will return Z_BUF_ERROR both for an invalid input buffer and if there is not enough space in the output buffer.  However, zlibmodule.c assumes Z_BUF_ERROR always means the output buffer is too small, so it keeps allocating a larger one.  I reported this error on the python-list mailing list and received a reply with the following patch (which I have updated so that it applies to the zlibmodule.c which comes with Python 2.0b2).  I have not actually applied or tested this patch (that's why I'm not submitting it as a patch), but it looks like it should solve the problem:

*** zlibmodule.c.orig	Wed Aug 02 19:04:04 2000
--- zlibmodule.c	Fri Oct 06 10:58:22 2000
***************
*** 213,219 ****
          {
          case(Z_STREAM_END):
  	    break;
! 	case(Z_BUF_ERROR):
          case(Z_OK):
  	    /* need more memory */
  	    if (_PyString_Resize(&result_str, r_strlen << 1) == -1)
--- 213,232 ----
          {
          case(Z_STREAM_END):
  	    break;
!         case(Z_BUF_ERROR):
! 	    /*
! 	     * If there is at least 1 byte of room in zst.next_out
! 	     * and get this error, I assume that it means zlib cannot
! 	     * process inflate.
! 	     */
! 	    if (0 < zst.avail_out)
! 	    {
! 	      PyErr_Format(ZlibError, "Error %i while decompressing data",
! 	                   err);
! 	      inflateEnd(&zst);
! 	      Py_DECREF(result_str);
! 	      return NULL;
! 	    }
          case(Z_OK):
  	    /* need more memory */
  	    if (_PyString_Resize(&result_str, r_strlen << 1) == -1)


Follow-Ups:

Date: 2000-Oct-06 12:07
By: jhylton

Comment:
Andrew, do you have time to look at this today?  If not, bounce it back to me.

-------------------------------------------------------

Date: 2000-Oct-06 12:52
By: akuchling

Comment:
The patch looks OK as-is; I'll submit a patch that rewrites the comments a bit.
See DejaNews at http://x73.deja.com/getdoc.xp?AN=632287656
for the original c.l.p post.

The patch number is #101810.

(At some point we should reformat the zlibmodule to match the 
Python standard for C code; maybe after 2.0...)

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116267&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 21:05:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 13:05:25 -0700
Subject: [Python-bugs-list] [Bug #116271] corrupted wave file header
Message-ID: <200010062005.NAA01081@bush.i.sourceforge.net>

Bug #116271, was updated on 2000-Oct-06 13:05
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: corrupted wave file header

Details: In module wave.py at line 442 (python2.0b2)
in method _write_header of Wave_write class
the format argument of struct.pack is incorrect:

it should be '<l4s4slhhllhh4s'
(sizes for strings were missing)

by the way, there is no test_wave.py.

here is a simple one:

import os, tempfile
import wave

nchannels = 2
sampwidth = 2
framerate = 8000
nframes = 100

testfile = tempfile.mktemp()

f = wave.open(testfile, 'w')
f.setnchannels(nchannels)
f.setsampwidth(sampwidth)
f.setframerate(framerate)
f.setnframes(nframes)
output = '\0' * nframes * nchannels * sampwidth
f.writeframes(output)
f.close()

f = wave.open(testfile, 'r')
assert nchannels == f.getnchannels()
assert sampwidth == f.getsampwidth()
assert framerate == f.getframerate()
assert nframes == f.getnframes()
input = f.readframes(nframes)
assert input == output
f.close()

os.remove(testfile)

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116271&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 21:11:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 13:11:56 -0700
Subject: [Python-bugs-list] [Bug #115928] UserList.__getslice__ and co break previous behaviour
Message-ID: <200010062011.NAA01313@bush.i.sourceforge.net>

Bug #115928, was updated on 2000-Oct-03 09:41
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: Fixed
Bug Group: Not a Bug
Priority: 5
Summary: UserList.__getslice__ and co break previous behaviour

Details: When I make a class MyL derived from UserList, and a MyL instance named l, then l[:] returns a true list (in the sense that it responds to list operators).

Well, this is the behaviour in version 1.5.1. I recently upgraded to 1.5.2 (by switching my Linux distro to Debian Potato), and it breaks lots of my code, because the slice operator tries to create a new instance of MyL !

Unfortunately, MyL's constructor does not respond to UserList prototype expectance (no arguments), because MyL is a complex object that needs extra arguments at construction.

Additionally, it is not advisable, in that context, to create new MyL instances (or copies) like this, because of database connection / open files.

I triple checked the documentation of UserList/Sequences for 1.5.1, 1.5.2 and 1.6.0, and there is no such requirement that the slice operator should return a result of the same class as the operand, nor any specification on the constructor's arguments.

I understand anyway, that it has to return an object of the same sequence nature, be it tuple, list or string. But since I derive from a UserList, I expect it to look, smell and act like a python list... Hence the slice operator should return a plain list, that will in turn look, smell and act like a list, which it actually is !

The same reasonning holds for +/*/copy operators.

One could object, that if I do l=l[1:], or l=l+[x], then l would not be an MyL instance any more, and that is probably annoying.

That's perfectly true, but on one hand that's perhaps what I want, and on the other hand, it's my job to specify that + on a MyL instance should return a MyL instance, to specify how it should be done, and to implement it by overloading the adequate method. I don't want UserList implementation to decide for me !

If UserList is implemented the minimal way, then I'm free to overload it's methods to change its behaviour. That's what a class is for !
On the contrary, if it's implemented the current way, I have no choice. One solution is to bring back the old UserList implementation and put it in front of the python provided one in PYTHONPATH. Another is to overload methods to restore its generic behaviour.

Both solutions virtually make a library module useless, which I don't like. Why not making the default implementation the generic way, and provide another UserList2 implementation with different specification and requirements on its derived classes ?

Anyway, one of the implementation or the documentation/specification should be changed, so that they are in accordance to each other...


Follow-Ups:

Date: 2000-Oct-06 10:27
By: gvanrossum

Comment:
Let's update the documentation to say that for derived classes __getslice__ and others return an instance of the derived class. Since this was changed in 1.5.2 already, it's really too late to revert to the 1.5.1 specs -- it would break code relying on the 1.5.1 behavior! Plus, I really like the 1.5.2 (and 2.0) behavior better.

The best solution for you would be to override __getslice__ in your class to return a real list (or a UserList, if you prefer).
-------------------------------------------------------

Date: 2000-Oct-06 13:11
By: fdrake

Comment:
Documented the requirements for subclassing UserList (Doc/lib/libuserdict.tex revision 1.17).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115928&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 21:12:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 13:12:55 -0700
Subject: [Python-bugs-list] [Bug #115928] UserList.__getslice__ and co break previous behaviour
Message-ID: <200010062012.NAA01331@bush.i.sourceforge.net>

Bug #115928, was updated on 2000-Oct-03 09:41
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: Not a Bug
Priority: 5
Summary: UserList.__getslice__ and co break previous behaviour

Details: When I make a class MyL derived from UserList, and a MyL instance named l, then l[:] returns a true list (in the sense that it responds to list operators).

Well, this is the behaviour in version 1.5.1. I recently upgraded to 1.5.2 (by switching my Linux distro to Debian Potato), and it breaks lots of my code, because the slice operator tries to create a new instance of MyL !

Unfortunately, MyL's constructor does not respond to UserList prototype expectance (no arguments), because MyL is a complex object that needs extra arguments at construction.

Additionally, it is not advisable, in that context, to create new MyL instances (or copies) like this, because of database connection / open files.

I triple checked the documentation of UserList/Sequences for 1.5.1, 1.5.2 and 1.6.0, and there is no such requirement that the slice operator should return a result of the same class as the operand, nor any specification on the constructor's arguments.

I understand anyway, that it has to return an object of the same sequence nature, be it tuple, list or string. But since I derive from a UserList, I expect it to look, smell and act like a python list... Hence the slice operator should return a plain list, that will in turn look, smell and act like a list, which it actually is !

The same reasonning holds for +/*/copy operators.

One could object, that if I do l=l[1:], or l=l+[x], then l would not be an MyL instance any more, and that is probably annoying.

That's perfectly true, but on one hand that's perhaps what I want, and on the other hand, it's my job to specify that + on a MyL instance should return a MyL instance, to specify how it should be done, and to implement it by overloading the adequate method. I don't want UserList implementation to decide for me !

If UserList is implemented the minimal way, then I'm free to overload it's methods to change its behaviour. That's what a class is for !
On the contrary, if it's implemented the current way, I have no choice. One solution is to bring back the old UserList implementation and put it in front of the python provided one in PYTHONPATH. Another is to overload methods to restore its generic behaviour.

Both solutions virtually make a library module useless, which I don't like. Why not making the default implementation the generic way, and provide another UserList2 implementation with different specification and requirements on its derived classes ?

Anyway, one of the implementation or the documentation/specification should be changed, so that they are in accordance to each other...


Follow-Ups:

Date: 2000-Oct-06 10:27
By: gvanrossum

Comment:
Let's update the documentation to say that for derived classes __getslice__ and others return an instance of the derived class. Since this was changed in 1.5.2 already, it's really too late to revert to the 1.5.1 specs -- it would break code relying on the 1.5.1 behavior! Plus, I really like the 1.5.2 (and 2.0) behavior better.

The best solution for you would be to override __getslice__ in your class to return a real list (or a UserList, if you prefer).
-------------------------------------------------------

Date: 2000-Oct-06 13:11
By: fdrake

Comment:
Documented the requirements for subclassing UserList (Doc/lib/libuserdict.tex revision 1.17).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115928&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 21:16:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 13:16:00 -0700
Subject: [Python-bugs-list] [Bug #116271] corrupted wave file header
Message-ID: <200010062016.NAA25124@delerium.i.sourceforge.net>

Bug #116271, was updated on 2000-Oct-06 13:05
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: corrupted wave file header

Details: In module wave.py at line 442 (python2.0b2)
in method _write_header of Wave_write class
the format argument of struct.pack is incorrect:

it should be '<l4s4slhhllhh4s'
(sizes for strings were missing)

by the way, there is no test_wave.py.

here is a simple one:

import os, tempfile
import wave

nchannels = 2
sampwidth = 2
framerate = 8000
nframes = 100

testfile = tempfile.mktemp()

f = wave.open(testfile, 'w')
f.setnchannels(nchannels)
f.setsampwidth(sampwidth)
f.setframerate(framerate)
f.setnframes(nframes)
output = '\0' * nframes * nchannels * sampwidth
f.writeframes(output)
f.close()

f = wave.open(testfile, 'r')
assert nchannels == f.getnchannels()
assert sampwidth == f.getsampwidth()
assert framerate == f.getframerate()
assert nframes == f.getnframes()
input = f.readframes(nframes)
assert input == output
f.close()

os.remove(testfile)

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116271&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 21:56:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 13:56:52 -0700
Subject: [Python-bugs-list] [Bug #115530] cStringIO.StringIO() doesn't raise ValueError when closed
Message-ID: <200010062056.NAA03058@bush.i.sourceforge.net>

Bug #115530, was updated on 2000-Sep-27 20:48
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: cStringIO.StringIO() doesn't raise ValueError when closed

Details: When write() is called on a closed StringO instance, ValueError should be raised.  Other methods should be checked for this as well.

>>> import cStringIO, StringIO
>>> f = cStringIO.StringIO()
>>> f.close()
>>> f.write('')

>>> f = StringIO.StringIO()    
>>> f.close()
>>> f.write('')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "./../Lib/StringIO.py", line 119, in write
    raise ValueError, "I/O operation on closed file"
ValueError: I/O operation on closed file

>>> f = open('junk.txt', 'w')
>>> f.close()
>>> f.write('abc')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: I/O operation on closed file

Assigned to Ken since he works at Digital Creations and can pester Jim Fulton about this.

Follow-Ups:

Date: 2000-Sep-27 20:53
By: fdrake

Comment:
Oops -- fixed summary to refer to the proper exception.
-------------------------------------------------------

Date: 2000-Sep-27 21:27
By: fdrake

Comment:
A simple test for this is commented out in Lib/test/test_StringIO.py; please uncomment and regenerate output when fixing this bug.
-------------------------------------------------------

Date: 2000-Sep-30 07:29
By: loewis

Comment:
A patch is in http://sourceforge.net/patch/?func=detailpatch&patch_id=101721&group_id=5470

-------------------------------------------------------

Date: 2000-Oct-06 13:56
By: fdrake

Comment:
Fixed by Jim's checkin of Modules/cStringIO.c revision 2.27.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115530&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 23:43:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 15:43:57 -0700
Subject: [Python-bugs-list] [Bug #116244] 2.0b2 xml.dom.minidom: no attributes allowed
Message-ID: <200010062243.PAA07275@bush.i.sourceforge.net>

Bug #116244, was updated on 2000-Oct-06 08:31
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 8
Summary: 2.0b2 xml.dom.minidom: no attributes allowed

Details: C:\>python
Python 2.0b2 (#6, Sep 26 2000, 14:59:21) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import xml.dom.minidom
>>> adom = xml.dom.minidom.parseString("<a b='c'/>")
Traceback (most recent call last):
    [snip]
  File "D:\Python20\lib\xml\dom\pulldom.py", line 49, in startElementNS
    node.setAttributeNode(qname,attr)
UnboundLocalError: Local variable 'qname' referenced before assignment
>>>

And indeed, peeking around line 49 of the pulldom.py file, one sees variable qname assigned only along one branch of an if statement, but then used unconditionally at line 49.

Trying to fix this bug by adding some assignment for qname further fails since the setAttributeNote method called at 49 only wants one arg (the attr), not two.  Trying to fix this by only passing the attr lets the dom object be constructed, but then:

>>> adom.writexml(sys.stdout)
<a None="Traceback (most recent call last):
   [snip]
  File "D:\Python20\lib\xml\dom\minidom.py", line 145, in _write_data
    data = string.replace(data, "&", "&amp;")
  File "D:\Python20\lib\string.py", line 363, in replace
    return s.replace(old, new, maxsplit)
  File "D:\Python20\lib\xml\dom\minidom.py", line 74, in __getattr__
    raise AttributeError, key
AttributeError: replace
>>>

The "data" argument to method _write_data is not really a string object -- so it doesn't have a .replace method, and string.replace now uses the object's replace method, so it fails.


Follow-Ups:

Date: 2000-Oct-06 08:40
By: jhylton

Comment:
Paul-- We need this fixed ASAP.

-------------------------------------------------------

Date: 2000-Oct-06 15:43
By: loewis

Comment:
Fixed in minidom and pulldom 1.7, test case added in test_minidom 1.9.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116244&group_id=5470


From noreply@sourceforge.net  Fri Oct  6 23:55:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 15:55:40 -0700
Subject: [Python-bugs-list] [Bug #116280] writing to closed cStringIO inst does not raise ValueError
Message-ID: <200010062255.PAA31366@delerium.i.sourceforge.net>

Bug #116280, was updated on 2000-Oct-06 15:55
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: writing to closed cStringIO inst does not raise ValueError

Details: See Lib/test/test_StringIO.py.  It's final test is to see if ValueError is raised if write is called after the object is closed.  This test fails after your most recent checkin.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116280&group_id=5470


From noreply@sourceforge.net  Sat Oct  7 00:09:15 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 16:09:15 -0700
Subject: [Python-bugs-list] [Bug #115690] Dr. Watson error on Python2.0b2 Idle 0.6 WinNT4.0 SP6
Message-ID: <200010062309.QAA08201@bush.i.sourceforge.net>

Bug #115690, was updated on 2000-Sep-29 14:55
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 6
Summary: Dr. Watson error on Python2.0b2 Idle 0.6 WinNT4.0 SP6

Details: I get a Dr. Watson error:

    pythonw.exe
    Exception: access violation (0xc0000005), 
    Address: 0x00e31652

when I run the following code in Idle 0.6, using Edit->Run Script:

---%<---cut---%<---

import unicodedata
for c in range(0x10000):
    x=unichr(c)
    try:
        b = unicodedata.numeric(x)
        #print "numeric:", repr(x)
        try:
            a = unicodedata.digit(x)
            if a != b:
                print "bad" , repr(x)
        except:
            print "Numeric but not digit", hex(c), x.encode("utf8"), \
                  "numeric ->", b
    except:
        pass

---%<---cut---%<---

(This code was recently posted on python-dev)

I've modified my .idle file, adding 

    [EditorWindow]
    font-name=tahoma


Follow-Ups:

Date: 2000-Sep-29 21:42
By: jhylton

Comment:
Marc-Andre can you check whether this is a Unicode bug that is going to come up with or without idle.  If it seems Idle specific, please assign it to Guido or Tim.  If not, it's yours :-).


-------------------------------------------------------

Date: 2000-Oct-03 10:23
By: lemburg

Comment:
I can't reproduce this on Linux, so it seems that it is related to the way TCL/Tk
displays UTF-8 data. Another possibility would be an optimization error
which doesn't happen with gcc.

Tim, could you try this on Windows and possibly tell me where the segfault
occurs in the code ?

-------------------------------------------------------

Date: 2000-Oct-03 11:27
By: gvanrossum

Comment:
Can't reproduce it on Win98SE either. (And I did try setting font-name to tahoma.)
-------------------------------------------------------

Date: 2000-Oct-04 20:42
By: tim_one

Comment:
Assigned back to Guido, because it appears identical to bug 113803, which Guido assigned to himself.

Guido, I can reproduce the problem, and regardless of font (e.g., let it use the default) on Win98SE by letting the program run to completion, and then hitting the ENTER key *twice* (first time gets an IDLE prompt, second time blows up).  It's in exactly the same place then as 113803, trying to decref a NULL pointer in _tkinter.c's AsString.

Note that there *may* be another bug here specific to NT and/or W2K too, in that W9x have much feebler Unicode support.

-------------------------------------------------------

Date: 2000-Oct-06 10:13
By: gvanrossum

Comment:
Fixed the Tkinter bug, so closing this. Please check that this is indeed fixed in the CVS version (or wait for release candidate 1, Monday).
-------------------------------------------------------

Date: 2000-Oct-06 10:42
By: tim_one

Comment:
The crash went away for me (Win98SE, default font), but upon hitting the 2nd RETURN I get a new problem:

>>> Exception in Tkinter callback
Traceback (most recent call last):
  File "c:\code\python\dist\src\lib\lib-tk\Tkinter.py", line 1287, in __call__
    return apply(self.func, args)
  File "../tools/idle\PyShell.py", line 573, in enter_callback
    self.auto.auto_indent(event)
  File "C:\Code\python\dist\src\tools\idle\AutoIndent.py", line 269, in newline_and_indent_event
    c = y.get_continuation_type()
  File "C:\Code\python\dist\src\tools\idle\PyParse.py", line 332, in get_continuation_type
    self._study1()
  File "C:\Code\python\dist\src\tools\idle\PyParse.py", line 220, in _study1
    str = string.translate(str, _tran)
  File "c:\code\python\dist\src\lib\string.py", line 308, in translate
    return s.translate(table, deletions)
TypeError: translate requires exactly 1 argument; 2 given

I'll look into it.
-------------------------------------------------------

Date: 2000-Oct-06 11:10
By: tim_one

Comment:
Reopened this bug, cuz I need another set of eyes!  Guido, does the latest symptom occur for you too (run the program, hit ENTER twice, get a traceback from string.translate)?  The complaint doesn't make sense (the code for string.translate does *not* require exactly 1 arg, and I can't trigger this msg unless I run the test program first).
-------------------------------------------------------

Date: 2000-Oct-06 11:38
By: tim_one

Comment:
*Something* is really hosed here.  We haven't even entered stringobject.c's string_translate by the time the traceback is generated (I know that because I set a breakpoint there and it wasn't hit).
-------------------------------------------------------

Date: 2000-Oct-06 11:57
By: gvanrossum

Comment:
Betcha it's a Unicode object! There, translate() only takes 1 arg.
-------------------------------------------------------

Date: 2000-Oct-06 12:33
By: gvanrossum

Comment:
I think I understand what's going on, but I don't want to fix it. It's actually in a piece of IDLE that Tim hacked long ago! The VC++ debugger is quite useless in figuring this out, but if you use the IDLE stack viewer you can track exactly what happens.

- string.translate() gets called with a Unicode string arg -- this causes the crash.

- This is because self.str is u'\012'. That seems to have been extracted from the text buffer. I'm not quite sure how, but

- a few calls further up the stack, AutoIndent.newline_and_indent() seems to have extracted the last non-blank line from the PyShell outbut buffer, which happens to contain a Unicode character.

- I can reproduce this quite easily by something like 
   >>> print u"\u1234".encode("utf8")
and then hit return twice.

Back to Tim!


-------------------------------------------------------

Date: 2000-Oct-06 16:09
By: tim_one

Comment:
Thanks for the clues, Guido!  Fixed and Closed.

The Unicode newline is coming straight from text.get().  PyParse doesn't care about Unicode characters, but wasn't expecting any either.  Added code to change non-7-bit Unicode chars into "x" before parsing, so the parse functions can continue to work with 8-bit strings.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115690&group_id=5470


From noreply@sourceforge.net  Sat Oct  7 00:23:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 16:23:26 -0700
Subject: [Python-bugs-list] [Bug #114598] Blue Screen crash, popen, Win98, Norton Antivirus 2000
Message-ID: <200010062323.QAA08743@bush.i.sourceforge.net>

Bug #114598, was updated on 2000-Sep-16 13:24
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 3
Summary: Blue Screen crash, popen, Win98, Norton Antivirus 2000

Details: On Windows 98, all of the os.popen*() functions cause a hard "blue screen" crash requiring a reboot, when Nortin Antivirus 2000 is installed and enabled. (Not with Norton Antivirus version 5, not on Windows 2000.)

While this is probably a bug in Norton Antivirus 2000, and we're already warning for this on the download page, that's not enough (we've seen at least one report in the newsgroup), and it would be good if we could somehow prevent it. Even a call to Py_FatalError is better than the blue screen, and raising os.error would be a *lot* better.

Follow-Ups:

Date: 2000-Sep-16 14:26
By: tim_one

Comment:
I don't know how to stop this.  Pissed away an hour trying to get help on the Symantec site, and eventually found a support board to which I posted this msg:

Product: Norton AntiVirus 2000 6.0 for Windows 95/98/NT
Supported operating system: Windows 98
Action: Run Another Program
Error Message: 
Summary: Blue screen crash

I develop the Windows version of the core Python language. Several reports of blue-screen death on Win98 have been traced to NAV2000.  Here's the exact msg from one such:

An exception 0E has occurred at 0028:C02AD9D0 in VxD IFSMGR(04) + 000050E4. This was called from 0028:C000B511 in VxD VMM(01) + 0000A511. It may be possible to continue normally.

This occurs whenever a user executes a member of the popen family of functions from within Python; for example, this Python program:

import os
p = os.popen("dir")

popen is a std C library function, poorly implemented by Microsoft, but not *that* poorly <wink>.

You can get our latest installer here:

http://www.pythonlabs.com/tech/python2.0/download.html

As the warning there says:

-----------------
Incompatibility warning: Norton Antivirus 2000 can cause blue screen crashes on Windows 98 when a function in the os.popen*() family is invoked. To prevent this problem, disable Norton Antivirus when using Python. (Confirmed on Windows 98 Second Edition with Norton Antivirus version 6.10.20. The same Norton Antivirus version doesn't have this
problem on Windows 2000. Norton Antivirus version 5 on Windows 98SE doesn't have this problem either.) 
-----------------

ActiveState is seeing the same problem with their derivative work ActivePython, as is PythonWare with their derivative work PythonWorks. So this affects a lot of people. A recent change to the implementation of a popular library module has made it acutely visible recently (didn't use to use popen, but does now).

A workaround would be nice. More importantly, how can I *detect* whether an affected version of NAV is in use, so that we can shut down Python gracefully with an appropriate message before executing any of the popen functions that throw NAV into blue-screen territory? We try to be a very user-friendly language, and we'll do anything to prevent a crash. Alas, right now I don't know how to stop it.

-------------------------------------------------------

Date: 2000-Sep-19 02:21
By: tim_one

Comment:
1. Sent Guido a small self-contained C program in the hope that it's enough to provoke the problem by itself.  Reassigned this bug to Guido since he has to tell me what happens with that next (then assign back to me).

2. That's because Symantec is being no help at all.  They suggest upgrading to NAV 2001(!).  If I can post a tiny C program, maybe it will embarrass then into doing something.  You can follow this soap opera at:

http://servicenews.symantec.com/cgi-bin/displayArticle.cgi?group=symantec.support.win9x.nortonantivirus2000.general&article=57765

-------------------------------------------------------

Date: 2000-Sep-19 09:06
By: gvanrossum

Comment:
Tim's little C program crashes in the same way as Python when NAV2000 is enabled. back to Tim...
-------------------------------------------------------

Date: 2000-Sep-21 11:32
By: tim_one

Comment:
I cranked up my obnoxiousness level on the Symantec board (URL two comments down), and they may be on the edge of taking this seriously now.
-------------------------------------------------------

Date: 2000-Sep-22 20:46
By: tim_one

Comment:
Reduced the priority a notch.  The biggest trigger here was IDLE's use of os.popen (indirectly via webbrowser.py) to launch the Python HTML docs.  I put in a new Windows function (os.startfile) that uses Win32 ShellExecute instead, and changed webbrowser.py to use that.  IDLE now lives peacefully with NAV 6.10.20.

This was all Guido's idea, and he suggested that the priority of this bug should be dropped now.
-------------------------------------------------------

Date: 2000-Oct-06 12:23
By: gvanrossum

Comment:
Reduced priority even more. There's not much else we can do about this, it seems, except yell at Norton. :-(
-------------------------------------------------------

Date: 2000-Oct-06 16:23
By: tim_one

Comment:
Indeed, I can detect whether AutoProtect is loaded at system startup, but not whether it's currently running.  Just left another nag on the Symantec board but don't expect a useful response.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114598&group_id=5470


From noreply@sourceforge.net  Sat Oct  7 01:32:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 17:32:09 -0700
Subject: [Python-bugs-list] [Bug #116285] Unicode encoders don't report errors properly
Message-ID: <200010070032.RAA02325@delerium.i.sourceforge.net>

Bug #116285, was updated on 2000-Oct-06 17:32
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Unicode encoders don't report errors properly

Details: In current CVS, u"\366".encode("koi8-r") gives '\366'. This is incorrect -
koi8-r does not support LATIN SMALL LETTER O WITH DIAERESIS, so it should raise a UnicodeError instead.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116285&group_id=5470


From noreply@sourceforge.net  Sat Oct  7 03:25:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 19:25:20 -0700
Subject: [Python-bugs-list] [Bug #116289] Programs using Tkinter sometimes can't shut down
Message-ID: <200010070225.TAA06481@delerium.i.sourceforge.net>

Bug #116289, was updated on 2000-Oct-06 19:25
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 4
Summary: Programs using Tkinter sometimes can't shut down

Details: The following msg from the Tutor list is about 1.6, but I noticed the same thing several times today using 2.0b2+CVS.  In my case, I was running IDLE via

python ../tool/idle/idle.pyw

from a DOS box in my PCbuild directory.  Win98SE.  *Most* of the time, shutting down IDLE via Ctrl+Q left the DOS box hanging.  As with the poster, the only way to regain control was to use the Task Manager to kill off Winoldap.

-----Original Message-----
From: Joseph Stubenrauch <nothingisgoingtochangemyworld@yahoo.com>
Sent: Friday, October 06, 2000 9:23 PM
To: tutor@python.org
Subject: Re: [Tutor] Python 1.6 BUG


Strange, I have been experiencing the same bug myself.
Here's the low down for me:

Python 1.6 with win95
I am running a little Tkinter program
The command line I use is simply: "python foo.py"
About 25-35% of the time, when I close the Tkinter
window, DOS seems to "freeze" and never returns to the
c:\ command prompt.  I have to ctrl-alt-delete
repeatedly and shut down "winoldapp" to get rid of the
window and then shell back into DOS and keep working.
It's a bit of a pain, since I have the habit of
testing EVERYTHING in tiny little stages, so I change
one little thing, test it ... freeze ... ARGH!  Change
one more tiny thing, test it ... freeze ... ARGH! 
However, sometimes it seems to behave and doesn't
bother me for an entire several hour session of python
work.

That's my report on the problem.

Cheers,

Joe


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116289&group_id=5470


From noreply@sourceforge.net  Sat Oct  7 05:21:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 21:21:38 -0700
Subject: [Python-bugs-list] [Bug #116295] pickle fails to reduce class instances as documented
Message-ID: <200010070421.VAA10335@delerium.i.sourceforge.net>

Bug #116295, was updated on 2000-Oct-06 21:21
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: pickle fails to reduce class instances as documented

Details: According to the documentation of module copy_reg, copy_reg.pickle registers reduction functions for types and classes, which are then used by module pickle to reduce objects to a function and a tuple of arguments.  However, module pickle (and probably also cPickle) does not use registered reduction functions to reduce class instances.  Therefore, either the documentation of module copy_reg or the implementation of module pickle (and cPickle) is wrong.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116295&group_id=5470


From noreply@sourceforge.net  Sat Oct  7 06:13:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 22:13:18 -0700
Subject: [Python-bugs-list] [Bug #116136] sre recursion limit hit in tokenize.py
Message-ID: <200010070513.WAA20370@bush.i.sourceforge.net>

Bug #116136, was updated on 2000-Oct-05 07:21
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: sre recursion limit hit in tokenize.py

Details: While running Tim Peters' new reindent script over my code,
I received the following traceback:

checking ./dtcout.py ...
Traceback (most recent call last):
  File "/usr/local/bin/reindent", line 258, in ?
    main()
  File "/usr/local/bin/reindent", line 65, in main
    check(arg)
  File "/usr/local/bin/reindent", line 77, in check
    check(fullname)
  File "/usr/local/bin/reindent", line 90, in check
    if r.run():
  File "/usr/local/bin/reindent", line 135, in run
    tokenize.tokenize(self.getline, self.tokeneater)
  File "/usr/local/lib/python2.0/tokenize.py", line 152, in tokenize
    pseudomatch = pseudoprog.match(line, pos)
RuntimeError: maximum recursion limit exceeded

The pattern compiled into pseudoprog is

[ \f\t]*((\\\r?\n|#[^\r\n]*|([rR]?'''|[rR]?"""))|((0[jJ]|[1-9]\d*[jJ]|((\d+\.\d*|\.\d+)([eE][-+]?\d+)?|[1-9]\d*[eE][-+]?\d+)[jJ])|((\d+\.\d*|\.\d+)([eE][-+]?\d+)?|[1-9]\d*[eE][-+]?\d+)|(0[xX][\da-fA-F]*[lL]?|0[0-7]*[lL]?|[1-9]\d*[lL]?))|((\+=|\-=|\*=|%=|/=|\*\*=|&=|\|=|\^=|>>=|<<=|\+|\-|\*\*|\*|\^|~|/|%|&|\||<<|>>|==|<=|<>|!=|>=|=|<|>)|[][(){}]|(\r?\n|[:;.,`]))|([rR]?'(\\.|[^\n'\\])*('|\\\r?\n)|[rR]?"(\\.|[^\n"\\])*("|\\\r?\n))|[a-zA-Z_]\w*)

I am not even going to try to figure out what part of the re triggers the excessive recursion.  Here is the source file reindent was munching on when the exception was raised.  Hopefully the bug submission process won't destroy it.  If so, let me know (skip@mojam.com) and I'll send it to you.

def dtmlfunc(**__d):
    import sys, urllib, string
    output = []
    append = output.append
    append('<!-- Generated: Wed Mar 10 12:13:08 1999 -->')
    append('\012<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> <!-- -*-html-helper -*- -->\012<HTML>\012<HEAD>\012<TITLE>Musi-Cal Search: ')
    append("""%s""" % __d['search_key'])
    append('</TITLE>\012<LINK REV="made" HREF="mailto:concertmaster@musi-cal.com">\012</HEAD>\012<BODY bgcolor="#ffffff" text="#000000" link="#CC0000" alink="#FF3300" vlink="#330099"\012>\012\012')
    append("""%s""" % __d['banner'])
    append('\012\012<H2 align="center">Musi-Cal Search Response</H2>\012\012')
    if __d['repeat_msg']:
        append('\012  ')
        append("""%s""" % __d['repeat_msg'])
        append('\012  <hr>\012')
    append('\012\012')
    if __d['entries']:
        append('\012\012    ')
        if __d['indirect']:
            append('\012      <P>\012      You can invoke this search using the following URL.\012      Why not save it for future reference?\012      <p align=center><code>http://')
            append("""%s""" % __d['servername'])
            append('/cgi-bin/event-search?')
            append("""%s""" % __d['query_string'])
            append('</code></p>\012    ')
        append('\012    \012    <p>\012    Click <img src="http://www.musi-cal.com/icons/vdb10.gif" alt="[VDB]"> to look up venue information.<br>\012    ')
        if __d['next']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['next'])
            append('">[Next Page]</a>\012    </font>\012    ')
        append('\012    ')
        if __d['prev']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['prev'])
            append('">[Previous Page]</a><br>\012    </font>\012    ')
        else:
            append('\012      ')
            if __d['next']:
                append('<br>')
            append('\012    ')
        append('\012\012    <TABLE border=0 cellspacing="5" cellpadding="0" width="100%">\012\012    ')
        __i_entries = -1
        for __elt_entries in __d['entries']:
            __i_entries = __i_entries + 1
            append('\012\012\011<tr valign=middle>\012\012\011')
            if __d['editor']:
                append('\012\011  <TD><A href="http://')
                append("""%s""" % __d['servername'])
                append('/cgi-bin/edit-entry?editor=')
                try: append(urllib.quote(__d['editor']))
                except: append(__d['editor'].urllib.quote())
                append('&key=')
                append("""%s""" % __elt_entries['key'])
                append('">[Edit]</A><BR><A href="http://')
                append("""%s""" % __d['servername'])
                append('/cgi-bin/edit-entry?editor=')
                try: append(urllib.quote(__d['editor']))
                except: append(__d['editor'].urllib.quote())
                append('&key=')
                append("""%s""" % __elt_entries['key'])
                append('&zap=1">[Delete]</A>\012\011  <br><font size="-1">Submitter: ')
                try: append(get_email(__elt_entries))
                except: append(__elt_entries.get_email())
                append('</font>\012\011')
            else:
                append('\012\011  ')
                if __d['show_vcal']:
                    append('<TD><A href="http://')
                    append("""%s""" % __d['servername'])
                    append('/cgi-bin/gencal?type=vCalendar&key=')
                    append("""%s""" % __elt_entries['key'])
                    append('"><IMG SRC="/images/vcal.gif" ALIGN="top" ALT="vCal" width="16" height="16" border="0"></A>')
                append('\012\011')
            append('\012\012    ')
            try: append(html(__elt_entries))
            except: append(__elt_entries.html())
            append('\012\012    ')
            if (__i_entries == 0):
                append('\012\011')
                if __d['display_static']:
                    append('\012\011<td width="25%" valign=top rowspan=')
                    append("""%s""" % len(__d['entries']))
                    append('>\012\011    ')
                    if __d['static_info']:
                        append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><font size="+1"><a name="staticinfo">Notes Index</a></font></th></tr>\012\011\011  </table>\012\012\011\011')
                        if __d['stperformers']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stperf">Performers</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stperformers'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stcontributors']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th>Contributors</th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stcontributors'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stvenues']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stven">Venues</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stvenues'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stevents']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stev">Events</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stevents'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stcities']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stcity">Cities</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stcities'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011<font size="-1">You can <strong><a\012\011\011href="http://www.musi-cal.com/addstatic.shtml">add</a></strong> or\012\011\011<strong><a href="http://www.musi-cal.com/editstatic.shtml">edit</a></strong>\012\011\011Notes Index items too!</font>\012\012\011    ')
                    append('\012\011    <p>\012\011    <a href="http://www.musi-cal.com/cgi-bin/redirect/http%3a//www.amazon.com/exec/obidos/redirect-home/musical">\012\011    <img src="http://www.musi-cal.com/icons/amzn-assoc.gif" border="0" alt="In Association with Amazon.com"></a> \012\011</td>\012\011')
                append('\012    ')
            append('\012\012    ')
        append('\012\012    </TABLE>\012\012    ')
        if __d['next']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['next'])
            append('">[Next Page]</a>\012    </font>\012    ')
        append('\012    ')
        if __d['prev']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['prev'])
            append('">[Previous Page]</a><br>\012    </font>\012    ')
        else:
            append('\012      ')
            if __d['next']:
                append('<br>')
            append('\012    ')
        append('\012\012    <P>Check with venues before making plans to attend listed events.\012\012    <P>If you notice any errors, <A\012    href="mailto:concertmaster@musi-cal.com">please let us know</A> so we can\012    correct them.\012\012')
    else:
        append('\012\012    ')
        if __d['searchbyperformer']:
            append('\012      <p>We were not able to find any matches to your search.  It\'s possible\012      the artist you were searching for is not on tour or that we don\'t\012      currently have their dates in our database. You might also try <a\012      href="http://')
            append("""%s""" % __d['servername'])
            append('/cgi-bin/list-perf">browsing by performer</a>\012      in case you\'ve misspelled their name.\012      If you know of a possible source for their concert schedule,\012      <a href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\012      ')
            if __d['stperformers']:
                append('\012\011<table width="100%" cellpadding=2>\012\011<tr><th><a name="stperf">Performers</a></th></tr>\012\011<tr><td textcolor="black" bgcolor="white">\012\011  <font size="-1">\012\011  ')
                append("""%s""" % __d['stperformers'])
                append('\012\011  </font>\012\011  </td></tr>\012\011</table>\012     ')
            append('\012\012   ')
        else:
            append('\012      ')
            if __d['searchbyvenue']:
                append('\012\011<p>We were not able to find any matches to your search.  Venue\012\011names can often spelled several different ways.  You might try\012\011searching for just a single word in the venue\'s name, such as\012\011<strong>Passim</strong> instead of <strong>Club Passim</strong>.\012\011Also, some venues, such as church-sponsored coffeehouses, may\012\011be listed either under the name of the coffeehouse or the name\012\011of the hosting venue.\012\011We may also not have their schedule in our database.\012\011If you know of a possible source for their concert schedule,\012\011<a href="mailto:concertmaster@musi-cal.com">let us know</a>.\012      ')
            else:
                append('\012\011')
                if __d['searchbyevent']:
                    append('\012\011  <p>We were not able to find any matches to your search.\012\011  If you know of a possible source for event schedules,\012\011  <a href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\011')
                else:
                    append('\012\011  ')
                    if __d['searchbylocation']:
                        append('\012      <p>We were not able to find any matches to your search.\012      Please check that the city, state and country names are\012      spelled or abbreviated properly.  You might also try <a\012      href="http://')
                        append("""%s""" % __d['servername'])
                        append('/index-geog.shtml">browsing by location</a>\012      in case you misspelled the name. If you know of a\012      possible source of concert schedules for this region, <a\012      href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\011  ')
                    else:
                        append('\012      <p>We were not able to find any matches to your search.\012      If you know of a possible source of concert schedules\012      that would fill a hole in our database, <a\012      href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\011  ')
                    append('\012\011')
                append('\012      ')
            append('\012    ')
        append('\012\012')
    append('\012\012<P ALIGN="center"><CENTER>\012<p>\012<FORM METHOD="GET" ACTION="http://')
    append("""%s""" % __d['servername'])
    append('/cgi-bin/simple-search">\012<input type=radio name="key" value="performer">performer\012<input type=radio checked name="key" value="city">city\012<input type=radio name="key" value="venue">venue\012<input type=radio name="key" value="event">event<br>\012Search for: <INPUT TYPE="text" NAME="value">\012<input type="submit" value="OK">\012<br>')
    append("""%s""" % __d['survey'])
    append('\012</FORM></CENTER>\012\012\012<p align=center>\012<strong><font size="-1"><a href="/index-contribute.shtml"\012onMouseOver="window.status=\'Add events or Notes Index entries to the database\'; return true">Contribute</a> | <a href="/index-search.shtml"\012onMouseOver="window.status=\'Search the database in several ways\'; return true">Search</a> | <a href="/index-sponsor.shtml"\012onMouseOver="window.status=\'Advertise in Musi-Cal!\'; return true">Advertise</a> | <a href="/index-contents.shtml"\012onMouseOver="window.status=\'Let your mousey to the walking...\';return true">Contents</a> | <a href="/index-learn.shtml"\012onMouseOver="window.status=\'Stuck? Get help here...\'; return true">Help</a> | <a href="/Faq.shtml"\012onMouseOver="window.status=\'You got questions? We got answers...\'; return true">FAQ</a></font></strong>\012\012\012<p align=center>\012<A HREF="http://www.musi-cal.com/"><IMG border=0 WIDTH=23 HEIGHT=33 SRC="http://www.musi-cal.com/icons/not!
e.gif" ALT="[Musi-Cal Home Page]"></A>\012\012<font size="-1"><a href="mailto:concertmaster@musi-cal.com">Contact Us!</a><br><em>Copyright &#169; 1994-1999, Automatrix, Inc.</em>\012</font>\012\012\012\012</BODY>\012</HTML>\012')
    return string.join(output, '')


Follow-Ups:

Date: 2000-Oct-05 07:54
By: gvanrossum

Comment:
After 2.0 final is released.
-------------------------------------------------------

Date: 2000-Oct-05 15:26
By: tim_one

Comment:
Changed Category to Library, Summary to get "reindent" out of it, Group to Platform-specific, assigned to /F, and raised the Priority.

Skip, tell us which platform you're using.  It doesn't fail on Windows.  Also confirm that this is purely a problem with tokenize.py (e.g., does your test program also fail when run thru tabnanny.py, and/or checkappend.py?).

Since it doesn't fail for me, I can't whittle it down.  Strongly *suspect* it's due to your long string literals.  tokenize.py uses naive regexps for matching string literals, with bad performance characteristics.  If I were on a platform that failed, I'd

a) First whittle this down to a one-liner (pick on the line with the longest string literal).

b) Replace tokenize.py's string-literal regexps with the ones IDLE uses (which worked fine even on multimegabyte string literals, & much faster, in pre).

That wouldn't solve the underlying recursion limit problem, but would make it much harder to provoke.
-------------------------------------------------------

Date: 2000-Oct-05 18:45
By: montanaro

Comment:
Platform: Mandrake Linux 7.1
Python: latest CVS sources
One liner that fails is at

    http://www.musi-cal.com/~skip/srelimit.py

That fails when run through tabnanny or reindent

I can't see how to replace the tokenize string re's with IDLE's.  reindent and tabnanny both barf on

    pseudomatch = pseudoprog.match(line, pos)

As far as I can tell, PseudoToken (which is the re compiled into pseudoprog) doesn't appear to have much to do with matching strings other than recognizing the start of a triple-quoted string, which the problematic source file doesn't contain.



-------------------------------------------------------

Date: 2000-Oct-05 22:40
By: tim_one

Comment:
Thanks, Skip!  That confirms everything I suspected.

As to the connection to strings, pseudoprog *does* try to match "the first line" of single-quoted strings (via ContStr), which in your case is your entire 1200+ character single-quoted string literal.  That's where, e.g., the

([rR]?'(\\.|[^\n'\\])*('|\\\r?\n)

alternative in your pseudoprog dump comes from, and that's a terrible (for pragmatic reasons) regexp for matching long strings.  The IDLE-like alternative would be (re.VERBOSE)

(
[rR]?
'
[^\n'\\]*
(?: \\. [^\n'\\]*)*
(?: ' | \\ \r? \n)
)

This is just a vanilla instance of Friedl's

normal* (special normal*)*

"regexp unrolling", and saves your bacon for reasons spelled out in detail in his book.

-------------------------------------------------------

Date: 2000-Oct-06 22:13
By: tim_one

Comment:
Skip, please update and try this again.  I replaced tokenize.py's string regexps, and with a bit of luck that will sidestep your problem and we can get this bug off /F's back.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116136&group_id=5470


From noreply@sourceforge.net  Sat Oct  7 06:27:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 6 Oct 2000 22:27:54 -0700
Subject: [Python-bugs-list] [Bug #112786] Build under Cygwin fails
Message-ID: <200010070527.WAA12419@delerium.i.sourceforge.net>

Bug #112786, was updated on 2000-Aug-26 01:39
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 3
Summary: Build under Cygwin fails

Details: Py1.6b1
========
1) socketmodule.c -- looks for netinet/tcp.h, which does not exist on cygwin.

2) gcc   python.o \
          ../libpython1.6.a    -lm  -o python
python.o: In function `main':
/usr/local/bin/Python-1.6b1/Modules/python.c:12: undefined reference to `Py_Main


Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-13 04:13
By: gvanrossum

Comment:
I don't have cygwin. Does anyone here have cygwin? I know Tim said the cygwin installer failed for him, so he doesn't have it. Is there someone outside the PythonLabs to whom we could assign this?
-------------------------------------------------------

Date: 2000-Sep-16 01:56
By: tim_one

Comment:
A fellow named Norman mailto:nhv@yahoo.com posted to c.l.py with some evidence of real Cygwin knowledge, so I emailed him a link to this bug and asked whether he'd help out.
-------------------------------------------------------

Date: 2000-Sep-16 20:29
By: nhv

Comment:
Hi I am that fellow Norman

FYI I have been doing bi-weekly builds of the Python CVS source with the 'current' Cygwin distribution for about a year.

I sent Tim my small set of diffs

Basically threading with Cygwin Python is still broken
and dll building with Cygwin has some problems but other then that everything including tkinter works for me with very minor changes.

FWIW We are succesfully embedding Python in PrettyPoly
http://prettypoly.sourceforge.net and I am using Cygwin
as my development enviroment for this

If helpful I can mail someone my diffs and the results of make test after each of my CVS sessions or apon request

Also FWIW I build Cygwin from source and have access to the Cygwin development team

I will help in anyway I can to make Python compile with Cygwin 'out of the box'  


Norman Vine nhv@yahoo.com

-------------------------------------------------------

Date: 2000-Sep-17 05:41
By: tim_one

Comment:
Here's the body of email from Norman:

I will certainly help in anyway that I can :-)

Below is a diff of my PY_SRC and the Python CVS at SourceForge

specifically

1) socketmodule.c -- looks for netinet/tcp.h, which does not exist on cygwin.

Cygwin does not have netinet / tcp.h
There has been some discussion about including a dummy tcp.h
into the distribution but I am noy sure that this is a standard header ?
see
http://sources.redhat.com/ml/cygwin/2000-09/msg00011.html

2) gcc python.o \
../libpython1.6.a -lm -o python
python.o: In function `main':
/usr/local/bin/Python-1.6b1/Modules/python.c:12: undefined reference to
`Py_Main

Before rerunning make after a failed build it is occasionally necessary to from top_level python_src directory it is necessary to do
% rm *.a *.o *.exe
I believe that this will solve this problem

I am working with the 2.0 srource tree though and I notice that this is reported against the 1.6 tree


IMHO the two main 'issues'  with Python and Cygwin remaining
are threads and dll support.

I am working on the dll stuff and am aware of Distutils

The thread stuff is beyond me and I could use some help.

I will gladly be a Cygwin 'tester' for Python.

and can forward Cygwin specific Python questions that
I can not answer directly to the appropriate Cygwin list(s)

Cheers

Norman


Index: _tkinter.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/_tkinter.c,v
retrieving revision 1.111
diff -r1.111 _tkinter.c
0a1
>
60,62c61,63
< #if !defined(MS_WINDOWS)
< #define HAVE_CREATEFILEHANDLER
< #endif
---
> //#if !(defined(MS_WINDOWS) || defined(__CYGWIN__))
> //#define HAVE_CREATEFILEHANDLER
> //#endif
64a66
> #undef HAVE_CREATEFILEHANDLER
71c73
< #ifdef MS_WINDOWS
---
> #if defined(MS_WINDOWS) || defined(__CYGWIN__)
Index: main.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/main.c,v
retrieving revision 1.44
diff -r1.44 main.c
11c11
< #ifdef MS_WINDOWS
---
> #if defined(MS_WINDOWS) || defined(__CYGWIN__)
187c187
< #ifdef MS_WINDOWS
---
> #if defined(MS_WINDOWS) || defined(__CYGWIN__)
209c209
< #ifdef MS_WINDOWS
---
> #if defined(MS_WINDOWS) || defined(__CYGWIN__)
Index: socketmodule.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v
retrieving revision 1.127
diff -r1.127 socketmodule.c
125c125
< #ifndef __BEOS__
---
> #if !defined(__BEOS__) && !defined(__CYGWIN__)

-------------------------------------------------------

Date: 2000-Oct-05 13:29
By: jhylton

Comment:
Can we close this bug now?

-------------------------------------------------------

Date: 2000-Oct-05 14:58
By: tim_one

Comment:
I doubt it.  These changes don't match the ones Norman posted in his other "bug" report.  Until he submits a proper context-diff patch or says "nevermind", I expect all Cygwin bugs should remain open.
-------------------------------------------------------

Date: 2000-Oct-05 21:47
By: nhv

Comment:
See patch: 101802 
Titled: Cygwin Fix -- missing tcp.h 
Filed: 2000-Oct-06 03:56 

After applying above patch
Cygwin V1.1.4 on w2k with
./configure --without-threads --with-suffix='exe --with-libm=
against CVS checkout as of 2200 EST 05 Oct

compiled and ran make test
minor problems still in 
test_poll
test_strftime
test_time

Win9X has a problem with
test_select

I believe the problems in test_poll will be fixed in the
next Cygwin release

Would you like me to submit Cygwin specific patches for
these problematical patches ??

Other then these minor points I believe that this 
Bug can be considered closed.

Norman



-------------------------------------------------------

Date: 2000-Oct-06 07:37
By: jlt63

Comment:
The current Cygwin CVS source has an empty netinet/tcp.h which solves this problem.  See
the following for more details:

    http://sources.redhat.com/ml/cygwin/2000-10/msg00157.html

Unfortunately, Cygwin 1.1.4 does not include an empty netinet/tcp.h but 1.1.5 will.  My
suggestion is to close this item anyway.
-------------------------------------------------------

Date: 2000-Oct-06 22:27
By: tim_one

Comment:
Marked Fixed and Closed, because whether or not this has been fixed, this bug report has gotten too confusing to understand <0.5 wink>!

Norman, you bet:  if there's anything you need to make Cygwin build and run out of the box, submit a patch for it.  You *are* the Cygwin Python developer at this point!  We're not going to make any Cygwin progress without you.

Note that we don't really need a bug report for each patch -- just uploading the patches would save time and confusion all around.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112786&group_id=5470


From noreply@sourceforge.net  Sat Oct  7 08:37:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 7 Oct 2000 00:37:54 -0700
Subject: [Python-bugs-list] [Bug #116289] Programs using Tkinter sometimes can't shut down
Message-ID: <200010070737.AAA24973@bush.i.sourceforge.net>

Bug #116289, was updated on 2000-Oct-06 19:25
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: Programs using Tkinter sometimes can't shut down

Details: The following msg from the Tutor list is about 1.6, but I noticed the same thing several times today using 2.0b2+CVS.  In my case, I was running IDLE via

python ../tool/idle/idle.pyw

from a DOS box in my PCbuild directory.  Win98SE.  *Most* of the time, shutting down IDLE via Ctrl+Q left the DOS box hanging.  As with the poster, the only way to regain control was to use the Task Manager to kill off Winoldap.

-----Original Message-----
From: Joseph Stubenrauch <nothingisgoingtochangemyworld@yahoo.com>
Sent: Friday, October 06, 2000 9:23 PM
To: tutor@python.org
Subject: Re: [Tutor] Python 1.6 BUG


Strange, I have been experiencing the same bug myself.
Here's the low down for me:

Python 1.6 with win95
I am running a little Tkinter program
The command line I use is simply: "python foo.py"
About 25-35% of the time, when I close the Tkinter
window, DOS seems to "freeze" and never returns to the
c:\ command prompt.  I have to ctrl-alt-delete
repeatedly and shut down "winoldapp" to get rid of the
window and then shell back into DOS and keep working.
It's a bit of a pain, since I have the habit of
testing EVERYTHING in tiny little stages, so I change
one little thing, test it ... freeze ... ARGH!  Change
one more tiny thing, test it ... freeze ... ARGH! 
However, sometimes it seems to behave and doesn't
bother me for an entire several hour session of python
work.

That's my report on the problem.

Cheers,

Joe


Follow-Ups:

Date: 2000-Oct-07 00:37
By: tim_one

Comment:
More info (none good, but some worse so boosted priority):

+ Happens under release and debug builds.

+ Have not been able to provoke when starting in the debugger.

+ Ctrl+Alt+Del and killing Winoldap is not enough to clean everything up.  There's still a Python (or Python_d) process hanging around that Ctrl+Alt+Del doesn't show.

+ This process makes it impossible to delete the associated Python .dll, and in particular makes it impossible to rebuild Python successfully without a reboot.

+ These processes cannot be killed!  Wintop and Process Viewer both fail to get the job done.  PrcView (a freeware process viewer) itself locks up if I try to kill them using it.  Process Viewer freezes for several seconds before giving up.

+ Attempting to attach to the process with the MSVC debugger (in order to find out what the heck it's doing) finds the process OK, but then yields the cryptic and undocumented error msg "Cannot execute program".

+ The processes are not accumulating cycles.

+ Smells like deadlock.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116289&group_id=5470


From noreply@sourceforge.net  Sat Oct  7 09:54:22 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 7 Oct 2000 01:54:22 -0700
Subject: [Python-bugs-list] [Bug #116174] using %% in cstrings sometimes fails with unicode params
Message-ID: <200010070854.BAA27290@bush.i.sourceforge.net>

Bug #116174, was updated on 2000-Oct-05 12:50
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 9
Summary: using %% in cstrings sometimes fails with unicode params

Details: There are various ways to show this but here's an example:

>>> "%s %%" % u"test"
u'test %'
>>> "%% %s %%" % u"test"
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: not all arguments converted

This is still present in a recent CVS version of Python2.0

Follow-Ups:

Date: 2000-Oct-05 12:57
By: gvanrossum

Comment:
Marc-Andre, this is clearly a bug in the unicode specific % formatting code... Can you fix it before Sunday?
-------------------------------------------------------

Date: 2000-Oct-05 13:37
By: lemburg

Comment:
Ok, here's what I think is going wrong:

When the string %-formatting code sees a Unicode object as
argument, it tries to pass the already formatted part of the string
together with the not yet formatted part to the Unicode %-formatting
code which then takes care of formatting the remaining arguments.

The reason for this was to avoid duplicate evaluations of %-arguments.

Now if there happens to be a "%%" *before* the first Unicode
argument, the Unicode %-formatting function will see this
as "%" (it was already formatted by the string %-formatting
code) and this produces the error message you see.

I will look into this, but can't promise anything w/r to the deadline.
The patch will surely be a little complicated due to the way
the string/Unicode interaction works here.

-------------------------------------------------------

Date: 2000-Oct-07 01:54
By: lemburg

Comment:
Checked in a patch which should fix the problem.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116174&group_id=5470


From noreply@sourceforge.net  Sat Oct  7 10:01:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 7 Oct 2000 02:01:25 -0700
Subject: [Python-bugs-list] [Bug #115308] codecs base classes need documentation
Message-ID: <200010070901.CAA27593@bush.i.sourceforge.net>

Bug #115308, was updated on 2000-Sep-25 12:00
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: codecs base classes need documentation

Details: The documentation for the codecs module includes a note that base classes need to be implemented; this needs to happen for the 2.0 final release.

There should be some note at the top of the section about what the module is for -- Unicode is not mentioned, but that's the primary (expected) use.  Let's say something about that, and perhaps give examples at the end (especially for handling encoded files).

For the open() function, the docs refer to a "buffering" parameter, and say that it matches the meaning of the the same thing for the open() built-in.  It should be called "bufsize" to match the built-in documentation.

Follow-Ups:

Date: 2000-Sep-25 14:03
By: lemburg

Comment:
I'll try to write something up, but can't promise anything this
week. I that's a problem, you'll have to assign the bug
to someone else.

Note that the codecs.py module has extensive doc-string
documentation which can be used as basis.

-------------------------------------------------------

Date: 2000-Oct-07 02:01
By: lemburg

Comment:
I'll try to get around and put something together next week.

When is the 2.0 docs deadline, BTW ?

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115308&group_id=5470


From noreply@sourceforge.net  Sat Oct  7 10:55:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 7 Oct 2000 02:55:44 -0700
Subject: [Python-bugs-list] [Bug #116251] SRE miscompiles character class containing -
Message-ID: <200010070955.CAA20735@delerium.i.sourceforge.net>

Bug #116251, was updated on 2000-Oct-06 09:12
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: SRE miscompiles character class containing -

Details: (Found by Neil Schemenauer)  Consider this test program:

import re

p = re.compile('[\w]+')
m = p.match('laser_beam')
print m and m.span()

p = re.compile('[\w-]+')
m = p.match('laser_beam')
print m and m.span()

This prints (0,10) and None, but the second pattern just adds a - inside the character class, so it should still match.  Printing the code generated by the two patterns 
shows that they're compiled differently.

(Is there a disassembler for SRE byte code hiding somewhere? 
I'd have dug further if there was...)

Follow-Ups:

Date: 2000-Oct-06 09:22
By: akuchling

Comment:
Found the .dump() method; it seems to me that the pattern is
being tokenized and compiled to a sequence all right.  

Incidentally, [\w+]+ matches correctly, even though
[\w-]+ doesn't.  
-------------------------------------------------------

Date: 2000-Oct-06 10:56
By: akuchling

Comment:
The bug is in sre_parse._parse(); it produces a bad 
parse tree when a category such as \w is followed by -.
Something like \w0- works fine.  Not sure what the fix is...

-------------------------------------------------------

Date: 2000-Oct-06 11:25
By: akuchling

Comment:
Proposed 2-line patch submitted as patch #101807.
-------------------------------------------------------

Date: 2000-Oct-07 02:55
By: effbot

Comment:
the patch looks fine.  I'll check it in later today.

thanks /F
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116251&group_id=5470


From noreply@sourceforge.net  Sat Oct  7 11:28:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 7 Oct 2000 03:28:54 -0700
Subject: [Python-bugs-list] [Bug #116251] SRE miscompiles character class containing -
Message-ID: <200010071028.DAA30405@bush.i.sourceforge.net>

Bug #116251, was updated on 2000-Oct-06 09:12
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 6
Summary: SRE miscompiles character class containing -

Details: (Found by Neil Schemenauer)  Consider this test program:

import re

p = re.compile('[\w]+')
m = p.match('laser_beam')
print m and m.span()

p = re.compile('[\w-]+')
m = p.match('laser_beam')
print m and m.span()

This prints (0,10) and None, but the second pattern just adds a - inside the character class, so it should still match.  Printing the code generated by the two patterns 
shows that they're compiled differently.

(Is there a disassembler for SRE byte code hiding somewhere? 
I'd have dug further if there was...)

Follow-Ups:

Date: 2000-Oct-06 09:22
By: akuchling

Comment:
Found the .dump() method; it seems to me that the pattern is
being tokenized and compiled to a sequence all right.  

Incidentally, [\w+]+ matches correctly, even though
[\w-]+ doesn't.  
-------------------------------------------------------

Date: 2000-Oct-06 10:56
By: akuchling

Comment:
The bug is in sre_parse._parse(); it produces a bad 
parse tree when a category such as \w is followed by -.
Something like \w0- works fine.  Not sure what the fix is...

-------------------------------------------------------

Date: 2000-Oct-06 11:25
By: akuchling

Comment:
Proposed 2-line patch submitted as patch #101807.
-------------------------------------------------------

Date: 2000-Oct-07 02:55
By: effbot

Comment:
the patch looks fine.  I'll check it in later today.

thanks /F
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116251&group_id=5470


From noreply@sourceforge.net  Sat Oct  7 13:51:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 7 Oct 2000 05:51:04 -0700
Subject: [Python-bugs-list] [Bug #116285] Unicode encoders don't report errors properly
Message-ID: <200010071251.FAA01904@bush.i.sourceforge.net>

Bug #116285, was updated on 2000-Oct-06 17:32
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: Unicode encoders don't report errors properly

Details: In current CVS, u"\366".encode("koi8-r") gives '\366'. This is incorrect -
koi8-r does not support LATIN SMALL LETTER O WITH DIAERESIS, so it should raise a UnicodeError instead.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116285&group_id=5470


From noreply@sourceforge.net  Sat Oct  7 16:25:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 7 Oct 2000 08:25:31 -0700
Subject: [Python-bugs-list] [Bug #116280] writing to closed cStringIO inst does not raise ValueError
Message-ID: <200010071525.IAA07064@bush.i.sourceforge.net>

Bug #116280, was updated on 2000-Oct-06 15:55
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: writing to closed cStringIO inst does not raise ValueError

Details: See Lib/test/test_StringIO.py.  It's final test is to see if ValueError is raised if write is called after the object is closed.  This test fails after your most recent checkin.


Follow-Ups:

Date: 2000-Oct-07 08:25
By: twouters

Comment:
This bug seems fixed, so it should be closed... Jim ?

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116280&group_id=5470


From nobody@sourceforge.net  Sat Oct  7 16:34:27 2000
From: nobody@sourceforge.net (Nobody)
Date: Sat, 7 Oct 2000 08:34:27 -0700
Subject: [Python-bugs-list] [Bug #116325] RedHat 5.2: ./configure: test: too many arguments
Message-ID: <200010071534.IAA07376@bush.i.sourceforge.net>

From: noreply@sourceforge.net

Bug #116325, was updated on 2000-Oct-07 08:34
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: RedHat 5.2: ./configure: test: too many arguments


Details: When running configure in the current CVS tree on RedHat 5.2, I get the following warning/error. (configure does not stop, though.)

[...]
checking for --with-threads... yes
./configure: test: too many arguments
checking for mach/cthreads.h... no
[...]

This is probably related to Barry's checkin 1.167, which changed a couple of tests in that area.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116325&group_id=5470


From noreply@sourceforge.net  Sat Oct  7 16:41:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 7 Oct 2000 08:41:09 -0700
Subject: [Python-bugs-list] [Bug #116326] Syntax error in Modules/config.c
Message-ID: <200010071541.IAA32164@delerium.i.sourceforge.net>

Bug #116326, was updated on 2000-Oct-07 08:41
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Syntax error in Modules/config.c

Details: After ./configure has terminated, file Modules/config.c
contains the following two erroneous lines:

[config.c]
   ...
   extern void initlocal/lib(void);
   ...
   {"local/lib", initlocal/lib},   
   ...

This happened on a Sun Ultra 1 with SunOS 5.6.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116326&group_id=5470


From noreply@sourceforge.net  Sat Oct  7 16:43:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 7 Oct 2000 08:43:53 -0700
Subject: [Python-bugs-list] [Bug #115221] test_poll hangs on Debian Linux 2.2
Message-ID: <200010071543.IAA07737@bush.i.sourceforge.net>

Bug #115221, was updated on 2000-Sep-24 07:38
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: test_poll hangs on Debian Linux 2.2

Details: When run from the command-line test_poll.py prints
"This is a test." 12 times and then hangs, without ever printing "Poll test 1 complete".

All other tests seem to work just fine.

Follow-Ups:

Date: 2000-Sep-27 10:58
By: nascheme

Comment:
I can't reproduce this on my Debian 2.2 system running Linux
 2.2.16.  Can you give the output from "uname -a" and "dpkg 
-l libc6"?  I am using libc6 2.1.3-13.
-------------------------------------------------------

Date: 2000-Oct-05 07:17
By: jhylton

Comment:
Andrew -- Is this still a problem for you?  
-------------------------------------------------------

Date: 2000-Oct-05 07:52
By: akuchling

Comment:
I don't have a Debian system to reproduce this on.

-------------------------------------------------------

Date: 2000-Oct-05 08:43
By: larsga

Comment:
I did a "cvs update", recompiled and ran the regtest again. Problem still persists.

Traceback is
Traceback (most recent call last):
  File "test_poll.py", line 171, in ?
    test_poll1()
  File "test_poll.py", line 65, in test_poll1
    poll_unit_tests()
  File "test_poll.py", line 77, in poll_unit_tests
    r = p.poll()
KeyboardInterrupt

[larsga@pc-larsga test]$ uname -a
Linux pc-larsga 2.0.36 #2 Sun Jan 17 19:38:45 EST 1999 i686 unknown
[larsga@pc-larsga test]$ dpkg -l libc6
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  libc6          2.1.3-10       GNU C Library: Shared libraries and Timezone

-------------------------------------------------------

Date: 2000-Oct-05 08:48
By: akuchling

Comment:
Interesting; Neil has libc6-2.1.3-13, while Lars has 2.1.3-10.  Presumably that last tag is a release level?

On the other hand, Neil is running a 2.2 Linux while Lars is running 2.0.36, and Neil also reported problems with
poll on a 2.0 machine.  So the finger of suspicion is pointing at the kernel...
-------------------------------------------------------

Date: 2000-Oct-07 08:43
By: twouters

Comment:
When running test_poll on the current CVS tree on RedHat 5.2 with a 2.0.36 kernel, I also get a test_poll error, though not the same one:

 This is a test.
 This is a test.
[...]
test test_poll crashed -- select.error: (9, 'Bad file descriptor')
Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 235, in runtest
    __import__(test, globals(), locals(), [])
  File "./Lib/test/test_poll.py", line 171, in ?
    test_poll1()
  File "./Lib/test/test_poll.py", line 65, in test_poll1
    poll_unit_tests()
  File "./Lib/test/test_poll.py", line 77, in poll_unit_tests
    r = p.poll()
error: (9, 'Bad file descriptor')
1 test failed: test_poll

RedHat 5.2 with a 2.2 kernel works fine. Let me know if you want me to submit a separate bugreport for the rh52-kernel2.0-poll error.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115221&group_id=5470


From noreply@sourceforge.net  Sat Oct  7 16:54:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 7 Oct 2000 08:54:43 -0700
Subject: [Python-bugs-list] [Bug #116326] Syntax error in Modules/config.c
Message-ID: <200010071554.IAA08096@bush.i.sourceforge.net>

Bug #116326, was updated on 2000-Oct-07 08:41
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: Syntax error in Modules/config.c

Details: After ./configure has terminated, file Modules/config.c
contains the following two erroneous lines:

[config.c]
   ...
   extern void initlocal/lib(void);
   ...
   {"local/lib", initlocal/lib},   
   ...

This happened on a Sun Ultra 1 with SunOS 5.6.


Follow-Ups:

Date: 2000-Oct-07 08:54
By: twouters

Comment:
Hm,  how did you run configure ? Any special options you passed to it ? Also, did you edit Modules/Setup or Modules/Setup.local ? And what are the contents of Modules/Setup.config ? That local/lib looks like a line was wrapped incorrectly, in one of those files, which makes 'makesetup' think it needs to define a module called 'local/lib'.

When in doubt, do a 'make distclean' and start from scratch, making a fresh copy of Modules/Setup.in and making sure to edit it with an editor that does not wrap lines ('joe' is my personal favorite, but YMMV ;)

(Priority lowered because the cause is highly likely to be a typo/linewrap in one of the Setup files. I added a request in PEP 42 for makesetup to grow syntax checking. Not closed yet, until it's clear that this is indeed the cause.)

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116326&group_id=5470


From noreply@sourceforge.net  Sat Oct  7 17:02:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 7 Oct 2000 09:02:38 -0700
Subject: [Python-bugs-list] [Bug #116325] RedHat 5.2: ./configure: test: too many arguments
Message-ID: <200010071602.JAA08376@bush.i.sourceforge.net>

Bug #116325, was updated on 2000-Oct-07 08:34
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: RedHat 5.2: ./configure: test: too many arguments

Details: When running configure in the current CVS tree on RedHat 5.2, I get the following warning/error. (configure does not stop, though.)

[...]
checking for --with-threads... yes
./configure: test: too many arguments
checking for mach/cthreads.h... no
[...]

This is probably related to Barry's checkin 1.167, which changed a couple of tests in that area.


Follow-Ups:

Date: 2000-Oct-07 09:02
By: twouters

Comment:
Assigned to Barry, because he broke it ;) Barry, please read my message to python-dev of last friday, commenting on your checkin. I may have been more righter than I thought ;) but I'm not confident enough to fix it without a more experienced /bin/sh person agreeing. Here's a little demo on how 'test' works on the RedHat 5.2 system in question:

~/src > set with_threads=foobar
~/src > test ! -z $with_threads -a -d $with_threads
~/src > set with_threads=
~/src > test ! -z $with_threads -a -d $with_threads
test: too many arguments
~/src > 

In other words, the test doesn't work right if 'with_threads' is empty.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116325&group_id=5470


From noreply@sourceforge.net  Sat Oct  7 17:20:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 7 Oct 2000 09:20:21 -0700
Subject: [Python-bugs-list] [Bug #116325] RedHat 5.2: ./configure: test: too many arguments
Message-ID: <200010071620.JAA09022@bush.i.sourceforge.net>

Bug #116325, was updated on 2000-Oct-07 08:34
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: RedHat 5.2: ./configure: test: too many arguments

Details: When running configure in the current CVS tree on RedHat 5.2, I get the following warning/error. (configure does not stop, though.)

[...]
checking for --with-threads... yes
./configure: test: too many arguments
checking for mach/cthreads.h... no
[...]

This is probably related to Barry's checkin 1.167, which changed a couple of tests in that area.


Follow-Ups:

Date: 2000-Oct-07 09:02
By: twouters

Comment:
Assigned to Barry, because he broke it ;) Barry, please read my message to python-dev of last friday, commenting on your checkin. I may have been more righter than I thought ;) but I'm not confident enough to fix it without a more experienced /bin/sh person agreeing. Here's a little demo on how 'test' works on the RedHat 5.2 system in question:

~/src > set with_threads=foobar
~/src > test ! -z $with_threads -a -d $with_threads
~/src > set with_threads=
~/src > test ! -z $with_threads -a -d $with_threads
test: too many arguments
~/src > 

In other words, the test doesn't work right if 'with_threads' is empty.

-------------------------------------------------------

Date: 2000-Oct-07 09:20
By: gvanrossum

Comment:
Barry is gone for the weekend (Jewish holiday).
I know exactly what's going on: the argument to test -z must be in double quotes. I'll check in a fix momentarily.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116325&group_id=5470


From noreply@sourceforge.net  Sat Oct  7 17:21:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 7 Oct 2000 09:21:47 -0700
Subject: [Python-bugs-list] [Bug #116325] RedHat 5.2: ./configure: test: too many arguments
Message-ID: <200010071621.JAA09047@bush.i.sourceforge.net>

Bug #116325, was updated on 2000-Oct-07 08:34
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: RedHat 5.2: ./configure: test: too many arguments

Details: When running configure in the current CVS tree on RedHat 5.2, I get the following warning/error. (configure does not stop, though.)

[...]
checking for --with-threads... yes
./configure: test: too many arguments
checking for mach/cthreads.h... no
[...]

This is probably related to Barry's checkin 1.167, which changed a couple of tests in that area.


Follow-Ups:

Date: 2000-Oct-07 09:02
By: twouters

Comment:
Assigned to Barry, because he broke it ;) Barry, please read my message to python-dev of last friday, commenting on your checkin. I may have been more righter than I thought ;) but I'm not confident enough to fix it without a more experienced /bin/sh person agreeing. Here's a little demo on how 'test' works on the RedHat 5.2 system in question:

~/src > set with_threads=foobar
~/src > test ! -z $with_threads -a -d $with_threads
~/src > set with_threads=
~/src > test ! -z $with_threads -a -d $with_threads
test: too many arguments
~/src > 

In other words, the test doesn't work right if 'with_threads' is empty.

-------------------------------------------------------

Date: 2000-Oct-07 09:20
By: gvanrossum

Comment:
Barry is gone for the weekend (Jewish holiday).
I know exactly what's going on: the argument to test -z must be in double quotes. I'll check in a fix momentarily.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116325&group_id=5470


From noreply@sourceforge.net  Sat Oct  7 17:26:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 7 Oct 2000 09:26:13 -0700
Subject: [Python-bugs-list] [Bug #116326] Syntax error in Modules/config.c
Message-ID: <200010071626.JAA09243@bush.i.sourceforge.net>

Bug #116326, was updated on 2000-Oct-07 08:41
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: None
Bug Group: None
Priority: 3
Summary: Syntax error in Modules/config.c

Details: After ./configure has terminated, file Modules/config.c
contains the following two erroneous lines:

[config.c]
   ...
   extern void initlocal/lib(void);
   ...
   {"local/lib", initlocal/lib},   
   ...

This happened on a Sun Ultra 1 with SunOS 5.6.


Follow-Ups:

Date: 2000-Oct-07 08:54
By: twouters

Comment:
Hm,  how did you run configure ? Any special options you passed to it ? Also, did you edit Modules/Setup or Modules/Setup.local ? And what are the contents of Modules/Setup.config ? That local/lib looks like a line was wrapped incorrectly, in one of those files, which makes 'makesetup' think it needs to define a module called 'local/lib'.

When in doubt, do a 'make distclean' and start from scratch, making a fresh copy of Modules/Setup.in and making sure to edit it with an editor that does not wrap lines ('joe' is my personal favorite, but YMMV ;)

(Priority lowered because the cause is highly likely to be a typo/linewrap in one of the Setup files. I added a request in PEP 42 for makesetup to grow syntax checking. Not closed yet, until it's clear that this is indeed the cause.)

-------------------------------------------------------

Date: 2000-Oct-07 09:26
By: gvanrossum

Comment:
This undoubtedly caused by a typo in Modules/Setup. Closed.

You probably have accidentally split a line so that the next line starts with the string "local/lib". This string occurs in several places in the Setup file as distributed. If you want to split a line, add a backslash.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116326&group_id=5470


From noreply@sourceforge.net  Sat Oct  7 17:59:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 7 Oct 2000 09:59:43 -0700
Subject: [Python-bugs-list] [Bug #116280] writing to closed cStringIO inst does not raise ValueError
Message-ID: <200010071659.JAA02597@delerium.i.sourceforge.net>

Bug #116280, was updated on 2000-Oct-06 15:55
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Summary: writing to closed cStringIO inst does not raise ValueError

Details: See Lib/test/test_StringIO.py.  It's final test is to see if ValueError is raised if write is called after the object is closed.  This test fails after your most recent checkin.


Follow-Ups:

Date: 2000-Oct-07 08:25
By: twouters

Comment:
This bug seems fixed, so it should be closed... Jim ?

-------------------------------------------------------

Date: 2000-Oct-07 09:59
By: fdrake

Comment:
Jim forgot to close, so I'm closing it.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116280&group_id=5470


From noreply@sourceforge.net  Sat Oct  7 19:16:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 7 Oct 2000 11:16:06 -0700
Subject: [Python-bugs-list] [Bug #115641] Dynamic Loading Fails on Mac OS X
Message-ID: <200010071816.LAA13329@bush.i.sourceforge.net>

Bug #115641, was updated on 2000-Sep-29 00:20
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Dynamic Loading Fails on Mac OS X

Details: Martin v. Loewis asked me to report that dynamic loading fails on Mac OS X.  I was able to successfully build the CVS version of Python following the directions posted by Dan Wolfe to Python-Dev:

http://www.python.org/pipermail/python-dev/2000-September/016289.html

However, I had some problems compiling the CVS version of Python/XML and reported them as a bug to Source Forge:

https://sourceforge.net/bugs/?func=detailbug&group_id=6473&bug_id=115544

Martin pointed out "how distutils comes up with the linker line: They read the configure-generated Makefile and scan for LDSHARED. So anything that was in the Python Makefile will be used when linking a distutils module."  He aksed me to try to build Python a few different ways, but they all failed.

When configured with:

./configure -with-threads -with-dyld --with-next-framework -with-suffix=.exe

Building Python produced the following:

cd Modules ; make OPT="-g -O2 -fno-common" VERSION="2.0" \
                prefix="/usr/local" exec_prefix="/usr/local" all
make[2]: Nothing to be done for `all'.
libtool -o libpython2.0.dylib -dynamic  libpython2.0.a -framework System  
ld: for architecture ppc
ld: Undefined symbols:
restFP
saveFP
___eprintf
_environ
libtool: internal link edit command failed
make[1]: *** [libpython2.0.dylib] Error 1
make: *** [python.exe] Error 2

When line 579 in "configure" is modified to the following:

then LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress'

building Python results in the following:

for i in Parser Grammar Objects Python Modules; do \
                (cd $i; make VERSION="2.0" add2lib); done
make[2]: `add2lib' is up to date.
make[2]: Nothing to be done for `add2lib'.
make[2]: `add2lib' is up to date.
make[2]: `add2lib' is up to date.
make[2]: `add2lib' is up to date.
libtool -o libpython2.0.dylib -dynamic  libpython2.0.a -framework System  
ld: for architecture ppc
ld: Undefined symbols:
___eprintf
_environ
libtool: internal link edit command failed
make[1]: *** [libpython2.0.dylib] Error 1
make: *** [python.exe] Error 2

I have only been using Mac OS X for a few days (and the development tools even less), so this could definitely be due to user error, but I will help out however I can.



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115641&group_id=5470


From noreply@sourceforge.net  Sun Oct  8 02:18:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 7 Oct 2000 18:18:18 -0700
Subject: [Python-bugs-list] [Bug #114756] test_linuxaudiodev uses wrong format
Message-ID: <200010080118.SAA20538@delerium.i.sourceforge.net>

Bug #114756, was updated on 2000-Sep-18 16:50
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: test_linuxaudiodev uses wrong format

Details: test_linuxaudiodev sounds *horrible*.  This has come up several times on python-dev, but nobody seems to have a fix that works -- or at least nothing has been checked in, so I'm contributing this bug report to the collective memory.

Here's how the bug manifests on my machine (a Dell Dimension with built-in sound hardware [Yamaha YMF-724F], using ALSA 0.5.8a drivers in a 2.2.14 kernel):

$ ./python Lib/test/test_linuxaudiodev.py
plays the entire sample without complaint, but it sounds *horrible* -- apparently because it's treating an .au file incorrectly.

See also my python-dev post of 29 June 2000: http://www.python.org/pipermail/python-dev/2000-June/011808.html

Ping suggested setting AUDIODEV=/dev/audio before running the script, and Michael Hudson contributed an alternate version of the test script which writes to /dev/audio (same idea, no environment variable needed).  Either of these fixes has the same result:

$ ./python Lib/test/test_linuxaudiodev-hudson.py
Traceback (most recent call last):
  File "Lib/test/test_linuxaudiodev-hudson.py", line 62, in ?
    test()
  File "Lib/test/test_linuxaudiodev-hudson.py", line 60, in test
    play_au_file(findfile('audiotest.au'))
  File "Lib/test/test_linuxaudiodev-hudson.py", line 55, in play_au_file
    dsp.write(data)
linuxaudiodev.error: (11, 'Resource temporarily unavailable')

The traceback appears immediately, but the script keeps running while the sample plays -- well, about half of it.  The sample is cut off midway through, and my shell prompt returns.

Finally, Ping posted another variation on the test script (http://www.python.org/pipermail/python-dev/2000-June/011834.html) which does not work at all for me:
$ ./python Lib/test/test_linuxaudiodev-ping.py
Traceback (most recent call last):
  File "Lib/test/test_linuxaudiodev-ping.py", line 37, in ?
    test()
  File "Lib/test/test_linuxaudiodev-ping.py", line 35, in test
    play_au_file(findfile('audiotest.au'))
  File "Lib/test/test_linuxaudiodev-ping.py", line 26, in play_au_file
    raise "audio format not supported by linuxaudiodev"
audio format not supported by linuxaudiodev

No sound at all from this one.

Charles Waldman <cgw@fnal.gov> also took a look at linuxaudiodev.c and didn't like what he found: http://www.python.org/pipermail/python-dev/2000-August/015746.html; Charles has said he's working on a rewrite of this module.



Follow-Ups:

Date: 2000-Sep-18 21:13
By: gvanrossum

Comment:
You do have a sound card, don't you, Jeremy?
-------------------------------------------------------

Date: 2000-Oct-06 12:00
By: jhylton

Comment:
I just read the Open Sound System Programmer's Guide from www.opensound.com.  It gives me the impression that the sample sounds horrible because Linux doesn't support the 8-bit mu-law format natively.  Instead it is emulating that format in software.

Regardless of whether it sounds horrible, I don't hear it at all when I run the test suite because the test script calls close() immediately -- before the kernel has a chance to dump any data from the audio buffer to the device.

On top of all that, the code had many other problems, including lots of calls to PyErr_SetFromErrno when errno was not set!

I have a fix that will be checked in soon, but it will need to be tested by other Linux users.

-------------------------------------------------------

Date: 2000-Oct-07 18:18
By: gvanrossum

Comment:
The test should be fixed now. It now requires the audioop module. See my post to python-dev. Closing this bug report.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114756&group_id=5470


From noreply@sourceforge.net  Sun Oct  8 08:11:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 8 Oct 2000 00:11:57 -0700
Subject: [Python-bugs-list] [Bug #114033] re incompatibility in sre
Message-ID: <200010080711.AAA07066@bush.i.sourceforge.net>

Bug #114033, was updated on 2000-Sep-11 01:24
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: re incompatibility in sre

Details: [submitted by Adam Sampson]

Under Python 1.5.2, I had a script containing the following line:

m = re.match(r"[a-z0-9]*://[^/]+/.*\.([^.#\?/]*)([#\?]?.*)?", url)

Under 1.6, this fails with:

[...]
  File "/usr/local/lib/python1.6/sre.py", line 44, in match                                              
    return _compile(pattern, flags).match(string)                                                        
  File "/usr/local/lib/python1.6/sre.py", line 102, in _compile                                          
    raise error, v # invalid expression                                                                  
sre_constants.error: nothing to repeat

I can narrow it down to:

>>> m = re.match(r"(x?)?", url)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python1.6/sre.py", line 44, in match
    return _compile(pattern, flags).match(string)
  File "/usr/local/lib/python1.6/sre.py", line 102, in _compile
    raise error, v # invalid expression
sre_constants.error: nothing to repeat

whereas:

>>> m = re.match(r"(x?.)?", url)

works fine. Is this correct behaviour for SRE, or am I just being stupid?
"(x?)?" looks like a perfectly reasonable Perl-style regexp to me (and Perl
too)...


Follow-Ups:

Date: 2000-Sep-30 21:33
By: gvanrossum

Comment:
Martin, is this still broken in 2.0? Fredrik, any idea?
-------------------------------------------------------

Date: 2000-Oct-01 11:13
By: loewis

Comment:
Yes, it is still broken in 2.0b2.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114033&group_id=5470


From noreply@sourceforge.net  Sun Oct  8 11:03:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 8 Oct 2000 03:03:44 -0700
Subject: [Python-bugs-list] [Bug #110866] re group self-reference weird behavior (PR#2)
Message-ID: <200010081003.DAA11903@bush.i.sourceforge.net>

Bug #110866, was updated on 2000-Aug-01 14:41
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: re group self-reference weird behavior (PR#2)

Details: Jitterbug-Id: 2
Submitted-By: guido@python.org
Date: Mon, 12 Jul 1999 15:03:24 -0400 (EDT)
Version: 1.5.2
OS: Unix, Windows


Try the following:

import re
re.search("((.)\\1+)","a")

This isn't proper syntax (you shouldn't reference a group
inside itself), but it seems to hang -- in fact it takes
several minutes to execute.

Possibly it runs out of some resource on its path to infinite
recursion and then backtracks?


====================================================================
Audit trail:
Mon Jul 12 15:33:07 1999	guido	moved from incoming to open
Mon Jul 12 19:02:35 1999	guido	changed notes
Thu Jul 13 20:28:48 2000	fdrake	changed notes
Thu Jul 13 20:28:48 2000	fdrake	changed notification
Thu Jul 13 20:28:48 2000	fdrake	moved from open to 3rdpartybug

Follow-Ups:

Date: 2000-Aug-01 14:41
By: none

Comment:
AMK: pcre bug that's been fixed in more recent releases, but that's no longer
relevant with SRE in the picture.
-------------------------------------------------------

Date: 2000-Aug-09 02:27
By: effbot

Comment:
on the other hand, SRE says "nothing to repeat" -- which isn't really what it should do.  Looks like the width calculation messes up on GROUPREF's...

I've reassigned it to myself!
-------------------------------------------------------

Date: 2000-Sep-30 21:31
By: gvanrossum

Comment:
Fredrik, this is almost 2 months old now. Did you ever fix this?
-------------------------------------------------------

Date: 2000-Oct-08 03:03
By: effbot

Comment:
PRE still hangs, SRE always fails (an undefined group
simply cannot match anything...)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110866&group_id=5470


From noreply@sourceforge.net  Sun Oct  8 12:02:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 8 Oct 2000 04:02:59 -0700
Subject: [Python-bugs-list] [Bug #114598] Blue Screen crash, popen, Win98, Norton Antivirus 2000
Message-ID: <200010081102.EAA06760@delerium.i.sourceforge.net>

Bug #114598, was updated on 2000-Sep-16 13:24
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 3
Summary: Blue Screen crash, popen, Win98, Norton Antivirus 2000

Details: On Windows 98, all of the os.popen*() functions cause a hard "blue screen" crash requiring a reboot, when Nortin Antivirus 2000 is installed and enabled. (Not with Norton Antivirus version 5, not on Windows 2000.)

While this is probably a bug in Norton Antivirus 2000, and we're already warning for this on the download page, that's not enough (we've seen at least one report in the newsgroup), and it would be good if we could somehow prevent it. Even a call to Py_FatalError is better than the blue screen, and raising os.error would be a *lot* better.

Follow-Ups:

Date: 2000-Sep-16 14:26
By: tim_one

Comment:
I don't know how to stop this.  Pissed away an hour trying to get help on the Symantec site, and eventually found a support board to which I posted this msg:

Product: Norton AntiVirus 2000 6.0 for Windows 95/98/NT
Supported operating system: Windows 98
Action: Run Another Program
Error Message: 
Summary: Blue screen crash

I develop the Windows version of the core Python language. Several reports of blue-screen death on Win98 have been traced to NAV2000.  Here's the exact msg from one such:

An exception 0E has occurred at 0028:C02AD9D0 in VxD IFSMGR(04) + 000050E4. This was called from 0028:C000B511 in VxD VMM(01) + 0000A511. It may be possible to continue normally.

This occurs whenever a user executes a member of the popen family of functions from within Python; for example, this Python program:

import os
p = os.popen("dir")

popen is a std C library function, poorly implemented by Microsoft, but not *that* poorly <wink>.

You can get our latest installer here:

http://www.pythonlabs.com/tech/python2.0/download.html

As the warning there says:

-----------------
Incompatibility warning: Norton Antivirus 2000 can cause blue screen crashes on Windows 98 when a function in the os.popen*() family is invoked. To prevent this problem, disable Norton Antivirus when using Python. (Confirmed on Windows 98 Second Edition with Norton Antivirus version 6.10.20. The same Norton Antivirus version doesn't have this
problem on Windows 2000. Norton Antivirus version 5 on Windows 98SE doesn't have this problem either.) 
-----------------

ActiveState is seeing the same problem with their derivative work ActivePython, as is PythonWare with their derivative work PythonWorks. So this affects a lot of people. A recent change to the implementation of a popular library module has made it acutely visible recently (didn't use to use popen, but does now).

A workaround would be nice. More importantly, how can I *detect* whether an affected version of NAV is in use, so that we can shut down Python gracefully with an appropriate message before executing any of the popen functions that throw NAV into blue-screen territory? We try to be a very user-friendly language, and we'll do anything to prevent a crash. Alas, right now I don't know how to stop it.

-------------------------------------------------------

Date: 2000-Sep-19 02:21
By: tim_one

Comment:
1. Sent Guido a small self-contained C program in the hope that it's enough to provoke the problem by itself.  Reassigned this bug to Guido since he has to tell me what happens with that next (then assign back to me).

2. That's because Symantec is being no help at all.  They suggest upgrading to NAV 2001(!).  If I can post a tiny C program, maybe it will embarrass then into doing something.  You can follow this soap opera at:

http://servicenews.symantec.com/cgi-bin/displayArticle.cgi?group=symantec.support.win9x.nortonantivirus2000.general&article=57765

-------------------------------------------------------

Date: 2000-Sep-19 09:06
By: gvanrossum

Comment:
Tim's little C program crashes in the same way as Python when NAV2000 is enabled. back to Tim...
-------------------------------------------------------

Date: 2000-Sep-21 11:32
By: tim_one

Comment:
I cranked up my obnoxiousness level on the Symantec board (URL two comments down), and they may be on the edge of taking this seriously now.
-------------------------------------------------------

Date: 2000-Sep-22 20:46
By: tim_one

Comment:
Reduced the priority a notch.  The biggest trigger here was IDLE's use of os.popen (indirectly via webbrowser.py) to launch the Python HTML docs.  I put in a new Windows function (os.startfile) that uses Win32 ShellExecute instead, and changed webbrowser.py to use that.  IDLE now lives peacefully with NAV 6.10.20.

This was all Guido's idea, and he suggested that the priority of this bug should be dropped now.
-------------------------------------------------------

Date: 2000-Oct-06 12:23
By: gvanrossum

Comment:
Reduced priority even more. There's not much else we can do about this, it seems, except yell at Norton. :-(
-------------------------------------------------------

Date: 2000-Oct-06 16:23
By: tim_one

Comment:
Indeed, I can detect whether AutoProtect is loaded at system startup, but not whether it's currently running.  Just left another nag on the Symantec board but don't expect a useful response.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114598&group_id=5470


From noreply@sourceforge.net  Sun Oct  8 18:49:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 8 Oct 2000 10:49:13 -0700
Subject: [Python-bugs-list] [Bug #110866] re group self-reference weird behavior (PR#2)
Message-ID: <200010081749.KAA23187@delerium.i.sourceforge.net>

Bug #110866, was updated on 2000-Aug-01 14:41
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: re group self-reference weird behavior (PR#2)

Details: Jitterbug-Id: 2
Submitted-By: guido@python.org
Date: Mon, 12 Jul 1999 15:03:24 -0400 (EDT)
Version: 1.5.2
OS: Unix, Windows


Try the following:

import re
re.search("((.)\\1+)","a")

This isn't proper syntax (you shouldn't reference a group
inside itself), but it seems to hang -- in fact it takes
several minutes to execute.

Possibly it runs out of some resource on its path to infinite
recursion and then backtracks?


====================================================================
Audit trail:
Mon Jul 12 15:33:07 1999	guido	moved from incoming to open
Mon Jul 12 19:02:35 1999	guido	changed notes
Thu Jul 13 20:28:48 2000	fdrake	changed notes
Thu Jul 13 20:28:48 2000	fdrake	changed notification
Thu Jul 13 20:28:48 2000	fdrake	moved from open to 3rdpartybug

Follow-Ups:

Date: 2000-Aug-01 14:41
By: none

Comment:
AMK: pcre bug that's been fixed in more recent releases, but that's no longer
relevant with SRE in the picture.
-------------------------------------------------------

Date: 2000-Aug-09 02:27
By: effbot

Comment:
on the other hand, SRE says "nothing to repeat" -- which isn't really what it should do.  Looks like the width calculation messes up on GROUPREF's...

I've reassigned it to myself!
-------------------------------------------------------

Date: 2000-Sep-30 21:31
By: gvanrossum

Comment:
Fredrik, this is almost 2 months old now. Did you ever fix this?
-------------------------------------------------------

Date: 2000-Oct-08 03:03
By: effbot

Comment:
PRE still hangs, SRE always fails (an undefined group
simply cannot match anything...)
-------------------------------------------------------

Date: 2000-Oct-08 10:49
By: tim_one

Comment:
Sorry, I opened this again:  that, e.g., r"(a\1)" can never match is better than the earlier behavior, but it *should* be treated as Guido originally characterized it:  as an ill-formed regexp.  That is, it should raise an exception at regexp compile time, same as r"[a" or r"(a" etc.  A reference to group N before group N has been closed simply doesn't make sense, and is certainly a user error.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110866&group_id=5470


From noreply@sourceforge.net  Sun Oct  8 21:46:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 8 Oct 2000 13:46:26 -0700
Subject: [Python-bugs-list] [Bug #110866] re group self-reference weird behavior (PR#2)
Message-ID: <200010082046.NAA04421@bush.i.sourceforge.net>

Bug #110866, was updated on 2000-Aug-01 14:41
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: re group self-reference weird behavior (PR#2)

Details: Jitterbug-Id: 2
Submitted-By: guido@python.org
Date: Mon, 12 Jul 1999 15:03:24 -0400 (EDT)
Version: 1.5.2
OS: Unix, Windows


Try the following:

import re
re.search("((.)\\1+)","a")

This isn't proper syntax (you shouldn't reference a group
inside itself), but it seems to hang -- in fact it takes
several minutes to execute.

Possibly it runs out of some resource on its path to infinite
recursion and then backtracks?


====================================================================
Audit trail:
Mon Jul 12 15:33:07 1999	guido	moved from incoming to open
Mon Jul 12 19:02:35 1999	guido	changed notes
Thu Jul 13 20:28:48 2000	fdrake	changed notes
Thu Jul 13 20:28:48 2000	fdrake	changed notification
Thu Jul 13 20:28:48 2000	fdrake	moved from open to 3rdpartybug

Follow-Ups:

Date: 2000-Aug-01 14:41
By: none

Comment:
AMK: pcre bug that's been fixed in more recent releases, but that's no longer
relevant with SRE in the picture.
-------------------------------------------------------

Date: 2000-Aug-09 02:27
By: effbot

Comment:
on the other hand, SRE says "nothing to repeat" -- which isn't really what it should do.  Looks like the width calculation messes up on GROUPREF's...

I've reassigned it to myself!
-------------------------------------------------------

Date: 2000-Sep-30 21:31
By: gvanrossum

Comment:
Fredrik, this is almost 2 months old now. Did you ever fix this?
-------------------------------------------------------

Date: 2000-Oct-08 03:03
By: effbot

Comment:
PRE still hangs, SRE always fails (an undefined group
simply cannot match anything...)
-------------------------------------------------------

Date: 2000-Oct-08 10:49
By: tim_one

Comment:
Sorry, I opened this again:  that, e.g., r"(a\1)" can never match is better than the earlier behavior, but it *should* be treated as Guido originally characterized it:  as an ill-formed regexp.  That is, it should raise an exception at regexp compile time, same as r"[a" or r"(a" etc.  A reference to group N before group N has been closed simply doesn't make sense, and is certainly a user error.
-------------------------------------------------------

Date: 2000-Oct-08 13:46
By: none

Comment:
Fair enough.  I can fix this.  But not in time for 2.0 final...

</F>
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110866&group_id=5470


From noreply@sourceforge.net  Mon Oct  9 01:42:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 8 Oct 2000 17:42:04 -0700
Subject: [Python-bugs-list] [Bug #116388] cStringIO rejects Unicode strings
Message-ID: <200010090042.RAA12963@bush.i.sourceforge.net>

Bug #116388, was updated on 2000-Oct-08 17:42
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: cStringIO rejects Unicode strings

Details: >>> import cStringIO
>>> s=cStringIO.StringIO(u"abcdefgh")
Traceback (innermost last):
  File "<pyshell#8>", line 1, in ?
    s=cStringIO.StringIO(u"abcdefgh")
TypeError: expected string, unicode found


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116388&group_id=5470


From noreply@sourceforge.net  Mon Oct  9 08:31:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 9 Oct 2000 00:31:12 -0700
Subject: [Python-bugs-list] [Bug #116397] Python takes cmd line options after module name for itself
Message-ID: <200010090731.AAA20439@delerium.i.sourceforge.net>

Bug #116397, was updated on 2000-Oct-09 00:31
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Python takes cmd line options after module name for itself

Details: Let the file foo.py be:

import sys
print sys.argv

Here is the behavior for version 1.6:

$ python1.6 foo.py 
['foo.py']
$ python1.6 foo.py john doe
['foo.py', 'john', 'doe']
$ python1.6 foo.py john doe -o /dev/null 
[... long insult message to say that Python does not recognize the "-o" option ...]
$ python1.6 foo.py -- john doe -o /dev/null 
['foo.py', 'john', 'doe', '-o', '/dev/null']
           ^-- NOTE: an argument WAS stripped

And that was the behavior for version 1.5.2:

$ python1.5 foo.py 
['foo.py']
$ python1.5 foo.py john doe
['foo.py', 'john', 'doe']
$ python1.5 foo.py john doe -o /dev/null 
['foo.py', 'john', 'doe', '-o', '/dev/null']
$ python1.5 foo.py -- john doe -o /dev/null 
['foo.py', '--', 'john', 'doe', '-o', '/dev/null']
           ^-- NOTE: argument NOT stripped


The manual page says:
    python [options] script [script args]

so strictly speaking this is a bug since arguments starting with '-' are located AFTER the script argument, as specified in the manual page.

Is the bug in Python or the manual page ? (in the latter case this means a change in the command line syntax, and we will have to make scripts that distinguish Python versions when we want to make commands that accept options)


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116397&group_id=5470


From noreply@sourceforge.net  Mon Oct  9 09:14:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 9 Oct 2000 01:14:51 -0700
Subject: [Python-bugs-list] [Bug #116285] Unicode encoders don't report errors properly
Message-ID: <200010090814.BAA22081@delerium.i.sourceforge.net>

Bug #116285, was updated on 2000-Oct-06 17:32
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 6
Summary: Unicode encoders don't report errors properly

Details: In current CVS, u"\366".encode("koi8-r") gives '\366'. This is incorrect -
koi8-r does not support LATIN SMALL LETTER O WITH DIAERESIS, so it should raise a UnicodeError instead.

Follow-Ups:

Date: 2000-Oct-09 01:14
By: lemburg

Comment:
Note that this is due to the way the character mapping codec
works: if the dictionary doesn't include a mapping for a certain
character it simply copies that character without raising an
error.

All standard codecs in Python 2.0 which use the generic character
codec only contain explicit mappings from the encoding to Unicode
(for the decoding part). When encoding from Unicode to the encoding,
the decoding map is simply reversed.

To produce correct error
output in all possible cases, the reverse mapping would have to
include all Unicode characters which cannot be mapped to a encoding
character (and map these to None). This is not feasable, so the
"bug" is hard to fix... certainly not for Python 2.0.

I'm setting the bug report to "Feature Request" meaning that it should be
reopened for the 2.1 cycle.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116285&group_id=5470


From noreply@sourceforge.net  Mon Oct  9 09:34:19 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 9 Oct 2000 01:34:19 -0700
Subject: [Python-bugs-list] [Bug #116388] cStringIO rejects Unicode strings
Message-ID: <200010090834.BAA22881@delerium.i.sourceforge.net>

Bug #116388, was updated on 2000-Oct-08 17:42
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: cStringIO rejects Unicode strings

Details: >>> import cStringIO
>>> s=cStringIO.StringIO(u"abcdefgh")
Traceback (innermost last):
  File "<pyshell#8>", line 1, in ?
    s=cStringIO.StringIO(u"abcdefgh")
TypeError: expected string, unicode found


Follow-Ups:

Date: 2000-Oct-09 01:34
By: lemburg

Comment:
I've marked this as feature request since making the standard
lib Unicode compatible is a post-2.0 project (probably a good
one for 2.1).

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116388&group_id=5470


From noreply@sourceforge.net  Mon Oct  9 10:25:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 9 Oct 2000 02:25:57 -0700
Subject: [Python-bugs-list] [Bug #116405] Bug in buffer interface
Message-ID: <200010090925.CAA31209@bush.i.sourceforge.net>

Bug #116405, was updated on 2000-Oct-09 02:25
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Bug in buffer interface

Details: Consider the following code:

PyObject *base = PyBuffer_New(100);
PyObject *buffer = PyBuffer_FromObject(base);
Py_DECREF(base);

After this code is executed,
buffer points to deallocated memory (because
buffer does not hold a reference to base anymore).


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116405&group_id=5470


From noreply@sourceforge.net  Mon Oct  9 13:37:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 9 Oct 2000 05:37:06 -0700
Subject: [Python-bugs-list] [Bug #116397] Python takes cmd line options after module name for itself
Message-ID: <200010091237.FAA06447@bush.i.sourceforge.net>

Bug #116397, was updated on 2000-Oct-09 00:31
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: Python takes cmd line options after module name for itself

Details: Let the file foo.py be:

import sys
print sys.argv

Here is the behavior for version 1.6:

$ python1.6 foo.py 
['foo.py']
$ python1.6 foo.py john doe
['foo.py', 'john', 'doe']
$ python1.6 foo.py john doe -o /dev/null 
[... long insult message to say that Python does not recognize the "-o" option ...]
$ python1.6 foo.py -- john doe -o /dev/null 
['foo.py', 'john', 'doe', '-o', '/dev/null']
           ^-- NOTE: an argument WAS stripped

And that was the behavior for version 1.5.2:

$ python1.5 foo.py 
['foo.py']
$ python1.5 foo.py john doe
['foo.py', 'john', 'doe']
$ python1.5 foo.py john doe -o /dev/null 
['foo.py', 'john', 'doe', '-o', '/dev/null']
$ python1.5 foo.py -- john doe -o /dev/null 
['foo.py', '--', 'john', 'doe', '-o', '/dev/null']
           ^-- NOTE: argument NOT stripped


The manual page says:
    python [options] script [script args]

so strictly speaking this is a bug since arguments starting with '-' are located AFTER the script argument, as specified in the manual page.

Is the bug in Python or the manual page ? (in the latter case this means a change in the command line syntax, and we will have to make scripts that distinguish Python versions when we want to make commands that accept options)


Follow-Ups:

Date: 2000-Oct-09 05:37
By: gvanrossum

Comment:
You must accidentally have linked Python with the GNU version of getopt.  GNU getopt is evil! Try using getopt.c that's in the Python distribution.

(The configure script tests for this, but it's possible that the link library order used eventually is different from what is used in the configure test.)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116397&group_id=5470


From noreply@sourceforge.net  Mon Oct  9 13:48:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 9 Oct 2000 05:48:37 -0700
Subject: [Python-bugs-list] [Bug #116405] Bug in buffer interface
Message-ID: <200010091248.FAA06825@bush.i.sourceforge.net>

Bug #116405, was updated on 2000-Oct-09 02:25
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: Bug in buffer interface

Details: Consider the following code:

PyObject *base = PyBuffer_New(100);
PyObject *buffer = PyBuffer_FromObject(base);
Py_DECREF(base);

After this code is executed,
buffer points to deallocated memory (because
buffer does not hold a reference to base anymore).


Follow-Ups:

Date: 2000-Oct-09 05:48
By: gvanrossum

Comment:
Do you know the old joke that begins with "Doctor, it hurts if I do this..." ?

That code is broken.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116405&group_id=5470


From noreply@sourceforge.net  Mon Oct  9 13:57:02 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 9 Oct 2000 05:57:02 -0700
Subject: [Python-bugs-list] [Bug #116405] Bug in buffer interface
Message-ID: <200010091257.FAA07177@bush.i.sourceforge.net>

Bug #116405, was updated on 2000-Oct-09 02:25
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: Bug in buffer interface

Details: Consider the following code:

PyObject *base = PyBuffer_New(100);
PyObject *buffer = PyBuffer_FromObject(base);
Py_DECREF(base);

After this code is executed,
buffer points to deallocated memory (because
buffer does not hold a reference to base anymore).


Follow-Ups:

Date: 2000-Oct-09 05:48
By: gvanrossum

Comment:
Do you know the old joke that begins with "Doctor, it hurts if I do this..." ?

That code is broken.
-------------------------------------------------------

Date: 2000-Oct-09 05:57
By: theller

Comment:
I know this joke, but it really won't help me.
Are we NOT going to fix this?
How can I use the buffer interface?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116405&group_id=5470


From noreply@sourceforge.net  Mon Oct  9 13:59:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 9 Oct 2000 05:59:10 -0700
Subject: [Python-bugs-list] [Bug #116295] pickle fails to reduce class instances as documented
Message-ID: <200010091259.FAA00506@delerium.i.sourceforge.net>

Bug #116295, was updated on 2000-Oct-06 21:21
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: pickle fails to reduce class instances as documented

Details: According to the documentation of module copy_reg, copy_reg.pickle registers reduction functions for types and classes, which are then used by module pickle to reduce objects to a function and a tuple of arguments.  However, module pickle (and probably also cPickle) does not use registered reduction functions to reduce class instances.  Therefore, either the documentation of module copy_reg or the implementation of module pickle (and cPickle) is wrong.

Follow-Ups:

Date: 2000-Oct-09 05:59
By: gvanrossum

Comment:
The copy_reg module is only for extension types. So this seems a documentation error. Fred?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116295&group_id=5470


From noreply@sourceforge.net  Mon Oct  9 14:23:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 9 Oct 2000 06:23:28 -0700
Subject: [Python-bugs-list] [Bug #116405] Bug in buffer interface
Message-ID: <200010091323.GAA01343@delerium.i.sourceforge.net>

Bug #116405, was updated on 2000-Oct-09 02:25
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Wont Fix
Bug Group: Not a Bug
Priority: 5
Summary: Bug in buffer interface

Details: Consider the following code:

PyObject *base = PyBuffer_New(100);
PyObject *buffer = PyBuffer_FromObject(base);
Py_DECREF(base);

After this code is executed,
buffer points to deallocated memory (because
buffer does not hold a reference to base anymore).


Follow-Ups:

Date: 2000-Oct-09 05:48
By: gvanrossum

Comment:
Do you know the old joke that begins with "Doctor, it hurts if I do this..." ?

That code is broken.
-------------------------------------------------------

Date: 2000-Oct-09 05:57
By: theller

Comment:
I know this joke, but it really won't help me.
Are we NOT going to fix this?
How can I use the buffer interface?
-------------------------------------------------------

Date: 2000-Oct-09 06:23
By: gvanrossum

Comment:
Make sure the base stays alive as long as the buffer. The buffer is for advanced uses -- I have a feeling you don't know what it is for and are trying to use it to solve something it isn't intended to solve.

In any case this is not a topic for a bug report.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116405&group_id=5470


From noreply@sourceforge.net  Mon Oct  9 15:13:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 9 Oct 2000 07:13:25 -0700
Subject: [Python-bugs-list] [Bug #116405] Bug in buffer interface
Message-ID: <200010091413.HAA10254@bush.i.sourceforge.net>

Bug #116405, was updated on 2000-Oct-09 02:25
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Bug in buffer interface

Details: Consider the following code:

PyObject *base = PyBuffer_New(100);
PyObject *buffer = PyBuffer_FromObject(base);
Py_DECREF(base);

After this code is executed,
buffer points to deallocated memory (because
buffer does not hold a reference to base anymore).


Follow-Ups:

Date: 2000-Oct-09 05:48
By: gvanrossum

Comment:
Do you know the old joke that begins with "Doctor, it hurts if I do this..." ?

That code is broken.
-------------------------------------------------------

Date: 2000-Oct-09 05:57
By: theller

Comment:
I know this joke, but it really won't help me.
Are we NOT going to fix this?
How can I use the buffer interface?
-------------------------------------------------------

Date: 2000-Oct-09 06:23
By: gvanrossum

Comment:
Make sure the base stays alive as long as the buffer. The buffer is for advanced uses -- I have a feeling you don't know what it is for and are trying to use it to solve something it isn't intended to solve.

In any case this is not a topic for a bug report.
-------------------------------------------------------

Date: 2000-Oct-09 07:13
By: gvanrossum

Comment:
Reopened.

In private mail, Thomas explained things better. The missing arguments to PyBuffer_FromObject() were a typo in the bug report. The real problem is that the base is already a buffer object!  Thomas writes:

The problem is the following piece of code in bufferobject.c:,
function _PyBuffer_FromObject:

 /* if the base object is another buffer, then "deref" it */
 if ( PyBuffer_Check(base) )
  base = ((PyBufferObject *)base)->b_base;

 return _PyBuffer_FromMemory(base, (char *)p + offset, size, readonly);
}

which should be changed to (IMO)

 /* if the base object is another buffer, then "deref" it */
 if ( PyBuffer_Check(base) && ((PyBufferObject *)base->b_base)
  base = ((PyBufferObject *)base)->b_base;

 return _PyBuffer_FromMemory(base, (char *)p + offset, size, readonly);
}

If base is an object which had been created by PyBuffer_New(),
then its b_base is NULL, and in this case the newly created object
MUST keep the reference to base itself, and not base->b_base.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116405&group_id=5470


From noreply@sourceforge.net  Mon Oct  9 15:21:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 9 Oct 2000 07:21:52 -0700
Subject: [Python-bugs-list] [Bug #116405] Bug in buffer interface
Message-ID: <200010091421.HAA10607@bush.i.sourceforge.net>

Bug #116405, was updated on 2000-Oct-09 02:25
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Bug in buffer interface

Details: Consider the following code:

PyObject *base = PyBuffer_New(100);
PyObject *buffer = PyBuffer_FromObject(base);
Py_DECREF(base);

After this code is executed,
buffer points to deallocated memory (because
buffer does not hold a reference to base anymore).


Follow-Ups:

Date: 2000-Oct-09 05:48
By: gvanrossum

Comment:
Do you know the old joke that begins with "Doctor, it hurts if I do this..." ?

That code is broken.
-------------------------------------------------------

Date: 2000-Oct-09 05:57
By: theller

Comment:
I know this joke, but it really won't help me.
Are we NOT going to fix this?
How can I use the buffer interface?
-------------------------------------------------------

Date: 2000-Oct-09 06:23
By: gvanrossum

Comment:
Make sure the base stays alive as long as the buffer. The buffer is for advanced uses -- I have a feeling you don't know what it is for and are trying to use it to solve something it isn't intended to solve.

In any case this is not a topic for a bug report.
-------------------------------------------------------

Date: 2000-Oct-09 07:13
By: gvanrossum

Comment:
Reopened.

In private mail, Thomas explained things better. The missing arguments to PyBuffer_FromObject() were a typo in the bug report. The real problem is that the base is already a buffer object!  Thomas writes:

The problem is the following piece of code in bufferobject.c:,
function _PyBuffer_FromObject:

 /* if the base object is another buffer, then "deref" it */
 if ( PyBuffer_Check(base) )
  base = ((PyBufferObject *)base)->b_base;

 return _PyBuffer_FromMemory(base, (char *)p + offset, size, readonly);
}

which should be changed to (IMO)

 /* if the base object is another buffer, then "deref" it */
 if ( PyBuffer_Check(base) && ((PyBufferObject *)base->b_base)
  base = ((PyBufferObject *)base)->b_base;

 return _PyBuffer_FromMemory(base, (char *)p + offset, size, readonly);
}

If base is an object which had been created by PyBuffer_New(),
then its b_base is NULL, and in this case the newly created object
MUST keep the reference to base itself, and not base->b_base.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116405&group_id=5470


From noreply@sourceforge.net  Mon Oct  9 15:24:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 9 Oct 2000 07:24:54 -0700
Subject: [Python-bugs-list] [Bug #116388] cStringIO rejects Unicode strings
Message-ID: <200010091424.HAA10663@bush.i.sourceforge.net>

Bug #116388, was updated on 2000-Oct-08 17:42
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: cStringIO rejects Unicode strings

Details: >>> import cStringIO
>>> s=cStringIO.StringIO(u"abcdefgh")
Traceback (innermost last):
  File "<pyshell#8>", line 1, in ?
    s=cStringIO.StringIO(u"abcdefgh")
TypeError: expected string, unicode found


Follow-Ups:

Date: 2000-Oct-09 01:34
By: lemburg

Comment:
I've marked this as feature request since making the standard
lib Unicode compatible is a post-2.0 project (probably a good
one for 2.1).

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116388&group_id=5470


From noreply@sourceforge.net  Mon Oct  9 15:25:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 9 Oct 2000 07:25:34 -0700
Subject: [Python-bugs-list] [Bug #116267] zlib.decompress memory allocation "infinite" loop
Message-ID: <200010091425.HAA03860@delerium.i.sourceforge.net>

Bug #116267, was updated on 2000-Oct-06 11:37
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 6
Summary: zlib.decompress memory allocation "infinite" loop

Details: Either of the following will cause Python to enter into a loop in which it progressively allocates more and more memory until it eventually generaes an out of memory error (or, under Win9X, the machine becomes unusable):

import zlib

s = zlib.decompress('')
s = zlib.decompress('\010')

There are probably many other strings which, when passed to decompress, will cause Python to enter this loop.  The problem appears to be that the inflate function (in the zlib library) will return Z_BUF_ERROR both for an invalid input buffer and if there is not enough space in the output buffer.  However, zlibmodule.c assumes Z_BUF_ERROR always means the output buffer is too small, so it keeps allocating a larger one.  I reported this error on the python-list mailing list and received a reply with the following patch (which I have updated so that it applies to the zlibmodule.c which comes with Python 2.0b2).  I have not actually applied or tested this patch (that's why I'm not submitting it as a patch), but it looks like it should solve the problem:

*** zlibmodule.c.orig	Wed Aug 02 19:04:04 2000
--- zlibmodule.c	Fri Oct 06 10:58:22 2000
***************
*** 213,219 ****
          {
          case(Z_STREAM_END):
  	    break;
! 	case(Z_BUF_ERROR):
          case(Z_OK):
  	    /* need more memory */
  	    if (_PyString_Resize(&result_str, r_strlen << 1) == -1)
--- 213,232 ----
          {
          case(Z_STREAM_END):
  	    break;
!         case(Z_BUF_ERROR):
! 	    /*
! 	     * If there is at least 1 byte of room in zst.next_out
! 	     * and get this error, I assume that it means zlib cannot
! 	     * process inflate.
! 	     */
! 	    if (0 < zst.avail_out)
! 	    {
! 	      PyErr_Format(ZlibError, "Error %i while decompressing data",
! 	                   err);
! 	      inflateEnd(&zst);
! 	      Py_DECREF(result_str);
! 	      return NULL;
! 	    }
          case(Z_OK):
  	    /* need more memory */
  	    if (_PyString_Resize(&result_str, r_strlen << 1) == -1)


Follow-Ups:

Date: 2000-Oct-06 12:07
By: jhylton

Comment:
Andrew, do you have time to look at this today?  If not, bounce it back to me.

-------------------------------------------------------

Date: 2000-Oct-06 12:52
By: akuchling

Comment:
The patch looks OK as-is; I'll submit a patch that rewrites the comments a bit.
See DejaNews at http://x73.deja.com/getdoc.xp?AN=632287656
for the original c.l.p post.

The patch number is #101810.

(At some point we should reformat the zlibmodule to match the 
Python standard for C code; maybe after 2.0...)

-------------------------------------------------------

Date: 2000-Oct-09 07:25
By: akuchling

Comment:
Fixed by the check-in of patch #101810, which uses the suggested patch with some cosmetic modifications.


-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116267&group_id=5470


From noreply@sourceforge.net  Mon Oct  9 17:04:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 9 Oct 2000 09:04:05 -0700
Subject: [Python-bugs-list] [Bug #116136] sre recursion limit hit in tokenize.py
Message-ID: <200010091604.JAA07981@delerium.i.sourceforge.net>

Bug #116136, was updated on 2000-Oct-05 07:21
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: sre recursion limit hit in tokenize.py

Details: While running Tim Peters' new reindent script over my code,
I received the following traceback:

checking ./dtcout.py ...
Traceback (most recent call last):
  File "/usr/local/bin/reindent", line 258, in ?
    main()
  File "/usr/local/bin/reindent", line 65, in main
    check(arg)
  File "/usr/local/bin/reindent", line 77, in check
    check(fullname)
  File "/usr/local/bin/reindent", line 90, in check
    if r.run():
  File "/usr/local/bin/reindent", line 135, in run
    tokenize.tokenize(self.getline, self.tokeneater)
  File "/usr/local/lib/python2.0/tokenize.py", line 152, in tokenize
    pseudomatch = pseudoprog.match(line, pos)
RuntimeError: maximum recursion limit exceeded

The pattern compiled into pseudoprog is

[ \f\t]*((\\\r?\n|#[^\r\n]*|([rR]?'''|[rR]?"""))|((0[jJ]|[1-9]\d*[jJ]|((\d+\.\d*|\.\d+)([eE][-+]?\d+)?|[1-9]\d*[eE][-+]?\d+)[jJ])|((\d+\.\d*|\.\d+)([eE][-+]?\d+)?|[1-9]\d*[eE][-+]?\d+)|(0[xX][\da-fA-F]*[lL]?|0[0-7]*[lL]?|[1-9]\d*[lL]?))|((\+=|\-=|\*=|%=|/=|\*\*=|&=|\|=|\^=|>>=|<<=|\+|\-|\*\*|\*|\^|~|/|%|&|\||<<|>>|==|<=|<>|!=|>=|=|<|>)|[][(){}]|(\r?\n|[:;.,`]))|([rR]?'(\\.|[^\n'\\])*('|\\\r?\n)|[rR]?"(\\.|[^\n"\\])*("|\\\r?\n))|[a-zA-Z_]\w*)

I am not even going to try to figure out what part of the re triggers the excessive recursion.  Here is the source file reindent was munching on when the exception was raised.  Hopefully the bug submission process won't destroy it.  If so, let me know (skip@mojam.com) and I'll send it to you.

def dtmlfunc(**__d):
    import sys, urllib, string
    output = []
    append = output.append
    append('<!-- Generated: Wed Mar 10 12:13:08 1999 -->')
    append('\012<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> <!-- -*-html-helper -*- -->\012<HTML>\012<HEAD>\012<TITLE>Musi-Cal Search: ')
    append("""%s""" % __d['search_key'])
    append('</TITLE>\012<LINK REV="made" HREF="mailto:concertmaster@musi-cal.com">\012</HEAD>\012<BODY bgcolor="#ffffff" text="#000000" link="#CC0000" alink="#FF3300" vlink="#330099"\012>\012\012')
    append("""%s""" % __d['banner'])
    append('\012\012<H2 align="center">Musi-Cal Search Response</H2>\012\012')
    if __d['repeat_msg']:
        append('\012  ')
        append("""%s""" % __d['repeat_msg'])
        append('\012  <hr>\012')
    append('\012\012')
    if __d['entries']:
        append('\012\012    ')
        if __d['indirect']:
            append('\012      <P>\012      You can invoke this search using the following URL.\012      Why not save it for future reference?\012      <p align=center><code>http://')
            append("""%s""" % __d['servername'])
            append('/cgi-bin/event-search?')
            append("""%s""" % __d['query_string'])
            append('</code></p>\012    ')
        append('\012    \012    <p>\012    Click <img src="http://www.musi-cal.com/icons/vdb10.gif" alt="[VDB]"> to look up venue information.<br>\012    ')
        if __d['next']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['next'])
            append('">[Next Page]</a>\012    </font>\012    ')
        append('\012    ')
        if __d['prev']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['prev'])
            append('">[Previous Page]</a><br>\012    </font>\012    ')
        else:
            append('\012      ')
            if __d['next']:
                append('<br>')
            append('\012    ')
        append('\012\012    <TABLE border=0 cellspacing="5" cellpadding="0" width="100%">\012\012    ')
        __i_entries = -1
        for __elt_entries in __d['entries']:
            __i_entries = __i_entries + 1
            append('\012\012\011<tr valign=middle>\012\012\011')
            if __d['editor']:
                append('\012\011  <TD><A href="http://')
                append("""%s""" % __d['servername'])
                append('/cgi-bin/edit-entry?editor=')
                try: append(urllib.quote(__d['editor']))
                except: append(__d['editor'].urllib.quote())
                append('&key=')
                append("""%s""" % __elt_entries['key'])
                append('">[Edit]</A><BR><A href="http://')
                append("""%s""" % __d['servername'])
                append('/cgi-bin/edit-entry?editor=')
                try: append(urllib.quote(__d['editor']))
                except: append(__d['editor'].urllib.quote())
                append('&key=')
                append("""%s""" % __elt_entries['key'])
                append('&zap=1">[Delete]</A>\012\011  <br><font size="-1">Submitter: ')
                try: append(get_email(__elt_entries))
                except: append(__elt_entries.get_email())
                append('</font>\012\011')
            else:
                append('\012\011  ')
                if __d['show_vcal']:
                    append('<TD><A href="http://')
                    append("""%s""" % __d['servername'])
                    append('/cgi-bin/gencal?type=vCalendar&key=')
                    append("""%s""" % __elt_entries['key'])
                    append('"><IMG SRC="/images/vcal.gif" ALIGN="top" ALT="vCal" width="16" height="16" border="0"></A>')
                append('\012\011')
            append('\012\012    ')
            try: append(html(__elt_entries))
            except: append(__elt_entries.html())
            append('\012\012    ')
            if (__i_entries == 0):
                append('\012\011')
                if __d['display_static']:
                    append('\012\011<td width="25%" valign=top rowspan=')
                    append("""%s""" % len(__d['entries']))
                    append('>\012\011    ')
                    if __d['static_info']:
                        append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><font size="+1"><a name="staticinfo">Notes Index</a></font></th></tr>\012\011\011  </table>\012\012\011\011')
                        if __d['stperformers']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stperf">Performers</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stperformers'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stcontributors']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th>Contributors</th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stcontributors'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stvenues']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stven">Venues</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stvenues'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stevents']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stev">Events</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stevents'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stcities']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stcity">Cities</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stcities'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011<font size="-1">You can <strong><a\012\011\011href="http://www.musi-cal.com/addstatic.shtml">add</a></strong> or\012\011\011<strong><a href="http://www.musi-cal.com/editstatic.shtml">edit</a></strong>\012\011\011Notes Index items too!</font>\012\012\011    ')
                    append('\012\011    <p>\012\011    <a href="http://www.musi-cal.com/cgi-bin/redirect/http%3a//www.amazon.com/exec/obidos/redirect-home/musical">\012\011    <img src="http://www.musi-cal.com/icons/amzn-assoc.gif" border="0" alt="In Association with Amazon.com"></a> \012\011</td>\012\011')
                append('\012    ')
            append('\012\012    ')
        append('\012\012    </TABLE>\012\012    ')
        if __d['next']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['next'])
            append('">[Next Page]</a>\012    </font>\012    ')
        append('\012    ')
        if __d['prev']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['prev'])
            append('">[Previous Page]</a><br>\012    </font>\012    ')
        else:
            append('\012      ')
            if __d['next']:
                append('<br>')
            append('\012    ')
        append('\012\012    <P>Check with venues before making plans to attend listed events.\012\012    <P>If you notice any errors, <A\012    href="mailto:concertmaster@musi-cal.com">please let us know</A> so we can\012    correct them.\012\012')
    else:
        append('\012\012    ')
        if __d['searchbyperformer']:
            append('\012      <p>We were not able to find any matches to your search.  It\'s possible\012      the artist you were searching for is not on tour or that we don\'t\012      currently have their dates in our database. You might also try <a\012      href="http://')
            append("""%s""" % __d['servername'])
            append('/cgi-bin/list-perf">browsing by performer</a>\012      in case you\'ve misspelled their name.\012      If you know of a possible source for their concert schedule,\012      <a href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\012      ')
            if __d['stperformers']:
                append('\012\011<table width="100%" cellpadding=2>\012\011<tr><th><a name="stperf">Performers</a></th></tr>\012\011<tr><td textcolor="black" bgcolor="white">\012\011  <font size="-1">\012\011  ')
                append("""%s""" % __d['stperformers'])
                append('\012\011  </font>\012\011  </td></tr>\012\011</table>\012     ')
            append('\012\012   ')
        else:
            append('\012      ')
            if __d['searchbyvenue']:
                append('\012\011<p>We were not able to find any matches to your search.  Venue\012\011names can often spelled several different ways.  You might try\012\011searching for just a single word in the venue\'s name, such as\012\011<strong>Passim</strong> instead of <strong>Club Passim</strong>.\012\011Also, some venues, such as church-sponsored coffeehouses, may\012\011be listed either under the name of the coffeehouse or the name\012\011of the hosting venue.\012\011We may also not have their schedule in our database.\012\011If you know of a possible source for their concert schedule,\012\011<a href="mailto:concertmaster@musi-cal.com">let us know</a>.\012      ')
            else:
                append('\012\011')
                if __d['searchbyevent']:
                    append('\012\011  <p>We were not able to find any matches to your search.\012\011  If you know of a possible source for event schedules,\012\011  <a href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\011')
                else:
                    append('\012\011  ')
                    if __d['searchbylocation']:
                        append('\012      <p>We were not able to find any matches to your search.\012      Please check that the city, state and country names are\012      spelled or abbreviated properly.  You might also try <a\012      href="http://')
                        append("""%s""" % __d['servername'])
                        append('/index-geog.shtml">browsing by location</a>\012      in case you misspelled the name. If you know of a\012      possible source of concert schedules for this region, <a\012      href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\011  ')
                    else:
                        append('\012      <p>We were not able to find any matches to your search.\012      If you know of a possible source of concert schedules\012      that would fill a hole in our database, <a\012      href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\011  ')
                    append('\012\011')
                append('\012      ')
            append('\012    ')
        append('\012\012')
    append('\012\012<P ALIGN="center"><CENTER>\012<p>\012<FORM METHOD="GET" ACTION="http://')
    append("""%s""" % __d['servername'])
    append('/cgi-bin/simple-search">\012<input type=radio name="key" value="performer">performer\012<input type=radio checked name="key" value="city">city\012<input type=radio name="key" value="venue">venue\012<input type=radio name="key" value="event">event<br>\012Search for: <INPUT TYPE="text" NAME="value">\012<input type="submit" value="OK">\012<br>')
    append("""%s""" % __d['survey'])
    append('\012</FORM></CENTER>\012\012\012<p align=center>\012<strong><font size="-1"><a href="/index-contribute.shtml"\012onMouseOver="window.status=\'Add events or Notes Index entries to the database\'; return true">Contribute</a> | <a href="/index-search.shtml"\012onMouseOver="window.status=\'Search the database in several ways\'; return true">Search</a> | <a href="/index-sponsor.shtml"\012onMouseOver="window.status=\'Advertise in Musi-Cal!\'; return true">Advertise</a> | <a href="/index-contents.shtml"\012onMouseOver="window.status=\'Let your mousey to the walking...\';return true">Contents</a> | <a href="/index-learn.shtml"\012onMouseOver="window.status=\'Stuck? Get help here...\'; return true">Help</a> | <a href="/Faq.shtml"\012onMouseOver="window.status=\'You got questions? We got answers...\'; return true">FAQ</a></font></strong>\012\012\012<p align=center>\012<A HREF="http://www.musi-cal.com/"><IMG border=0 WIDTH=23 HEIGHT=33 SRC="http://www.musi-cal.com/icons/not!
e.gif" ALT="[Musi-Cal Home Page]"></A>\012\012<font size="-1"><a href="mailto:concertmaster@musi-cal.com">Contact Us!</a><br><em>Copyright &#169; 1994-1999, Automatrix, Inc.</em>\012</font>\012\012\012\012</BODY>\012</HTML>\012')
    return string.join(output, '')


Follow-Ups:

Date: 2000-Oct-05 07:54
By: gvanrossum

Comment:
After 2.0 final is released.
-------------------------------------------------------

Date: 2000-Oct-05 15:26
By: tim_one

Comment:
Changed Category to Library, Summary to get "reindent" out of it, Group to Platform-specific, assigned to /F, and raised the Priority.

Skip, tell us which platform you're using.  It doesn't fail on Windows.  Also confirm that this is purely a problem with tokenize.py (e.g., does your test program also fail when run thru tabnanny.py, and/or checkappend.py?).

Since it doesn't fail for me, I can't whittle it down.  Strongly *suspect* it's due to your long string literals.  tokenize.py uses naive regexps for matching string literals, with bad performance characteristics.  If I were on a platform that failed, I'd

a) First whittle this down to a one-liner (pick on the line with the longest string literal).

b) Replace tokenize.py's string-literal regexps with the ones IDLE uses (which worked fine even on multimegabyte string literals, & much faster, in pre).

That wouldn't solve the underlying recursion limit problem, but would make it much harder to provoke.
-------------------------------------------------------

Date: 2000-Oct-05 18:45
By: montanaro

Comment:
Platform: Mandrake Linux 7.1
Python: latest CVS sources
One liner that fails is at

    http://www.musi-cal.com/~skip/srelimit.py

That fails when run through tabnanny or reindent

I can't see how to replace the tokenize string re's with IDLE's.  reindent and tabnanny both barf on

    pseudomatch = pseudoprog.match(line, pos)

As far as I can tell, PseudoToken (which is the re compiled into pseudoprog) doesn't appear to have much to do with matching strings other than recognizing the start of a triple-quoted string, which the problematic source file doesn't contain.



-------------------------------------------------------

Date: 2000-Oct-05 22:40
By: tim_one

Comment:
Thanks, Skip!  That confirms everything I suspected.

As to the connection to strings, pseudoprog *does* try to match "the first line" of single-quoted strings (via ContStr), which in your case is your entire 1200+ character single-quoted string literal.  That's where, e.g., the

([rR]?'(\\.|[^\n'\\])*('|\\\r?\n)

alternative in your pseudoprog dump comes from, and that's a terrible (for pragmatic reasons) regexp for matching long strings.  The IDLE-like alternative would be (re.VERBOSE)

(
[rR]?
'
[^\n'\\]*
(?: \\. [^\n'\\]*)*
(?: ' | \\ \r? \n)
)

This is just a vanilla instance of Friedl's

normal* (special normal*)*

"regexp unrolling", and saves your bacon for reasons spelled out in detail in his book.

-------------------------------------------------------

Date: 2000-Oct-06 22:13
By: tim_one

Comment:
Skip, please update and try this again.  I replaced tokenize.py's string regexps, and with a bit of luck that will sidestep your problem and we can get this bug off /F's back.
-------------------------------------------------------

Date: 2000-Oct-09 09:04
By: montanaro

Comment:
Works fine for me.  Thanks...

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116136&group_id=5470


From noreply@sourceforge.net  Mon Oct  9 19:10:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 9 Oct 2000 11:10:12 -0700
Subject: [Python-bugs-list] [Bug #116136] sre recursion limit hit in tokenize.py
Message-ID: <200010091810.LAA13434@delerium.i.sourceforge.net>

Bug #116136, was updated on 2000-Oct-05 07:21
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 6
Summary: sre recursion limit hit in tokenize.py

Details: While running Tim Peters' new reindent script over my code,
I received the following traceback:

checking ./dtcout.py ...
Traceback (most recent call last):
  File "/usr/local/bin/reindent", line 258, in ?
    main()
  File "/usr/local/bin/reindent", line 65, in main
    check(arg)
  File "/usr/local/bin/reindent", line 77, in check
    check(fullname)
  File "/usr/local/bin/reindent", line 90, in check
    if r.run():
  File "/usr/local/bin/reindent", line 135, in run
    tokenize.tokenize(self.getline, self.tokeneater)
  File "/usr/local/lib/python2.0/tokenize.py", line 152, in tokenize
    pseudomatch = pseudoprog.match(line, pos)
RuntimeError: maximum recursion limit exceeded

The pattern compiled into pseudoprog is

[ \f\t]*((\\\r?\n|#[^\r\n]*|([rR]?'''|[rR]?"""))|((0[jJ]|[1-9]\d*[jJ]|((\d+\.\d*|\.\d+)([eE][-+]?\d+)?|[1-9]\d*[eE][-+]?\d+)[jJ])|((\d+\.\d*|\.\d+)([eE][-+]?\d+)?|[1-9]\d*[eE][-+]?\d+)|(0[xX][\da-fA-F]*[lL]?|0[0-7]*[lL]?|[1-9]\d*[lL]?))|((\+=|\-=|\*=|%=|/=|\*\*=|&=|\|=|\^=|>>=|<<=|\+|\-|\*\*|\*|\^|~|/|%|&|\||<<|>>|==|<=|<>|!=|>=|=|<|>)|[][(){}]|(\r?\n|[:;.,`]))|([rR]?'(\\.|[^\n'\\])*('|\\\r?\n)|[rR]?"(\\.|[^\n"\\])*("|\\\r?\n))|[a-zA-Z_]\w*)

I am not even going to try to figure out what part of the re triggers the excessive recursion.  Here is the source file reindent was munching on when the exception was raised.  Hopefully the bug submission process won't destroy it.  If so, let me know (skip@mojam.com) and I'll send it to you.

def dtmlfunc(**__d):
    import sys, urllib, string
    output = []
    append = output.append
    append('<!-- Generated: Wed Mar 10 12:13:08 1999 -->')
    append('\012<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> <!-- -*-html-helper -*- -->\012<HTML>\012<HEAD>\012<TITLE>Musi-Cal Search: ')
    append("""%s""" % __d['search_key'])
    append('</TITLE>\012<LINK REV="made" HREF="mailto:concertmaster@musi-cal.com">\012</HEAD>\012<BODY bgcolor="#ffffff" text="#000000" link="#CC0000" alink="#FF3300" vlink="#330099"\012>\012\012')
    append("""%s""" % __d['banner'])
    append('\012\012<H2 align="center">Musi-Cal Search Response</H2>\012\012')
    if __d['repeat_msg']:
        append('\012  ')
        append("""%s""" % __d['repeat_msg'])
        append('\012  <hr>\012')
    append('\012\012')
    if __d['entries']:
        append('\012\012    ')
        if __d['indirect']:
            append('\012      <P>\012      You can invoke this search using the following URL.\012      Why not save it for future reference?\012      <p align=center><code>http://')
            append("""%s""" % __d['servername'])
            append('/cgi-bin/event-search?')
            append("""%s""" % __d['query_string'])
            append('</code></p>\012    ')
        append('\012    \012    <p>\012    Click <img src="http://www.musi-cal.com/icons/vdb10.gif" alt="[VDB]"> to look up venue information.<br>\012    ')
        if __d['next']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['next'])
            append('">[Next Page]</a>\012    </font>\012    ')
        append('\012    ')
        if __d['prev']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['prev'])
            append('">[Previous Page]</a><br>\012    </font>\012    ')
        else:
            append('\012      ')
            if __d['next']:
                append('<br>')
            append('\012    ')
        append('\012\012    <TABLE border=0 cellspacing="5" cellpadding="0" width="100%">\012\012    ')
        __i_entries = -1
        for __elt_entries in __d['entries']:
            __i_entries = __i_entries + 1
            append('\012\012\011<tr valign=middle>\012\012\011')
            if __d['editor']:
                append('\012\011  <TD><A href="http://')
                append("""%s""" % __d['servername'])
                append('/cgi-bin/edit-entry?editor=')
                try: append(urllib.quote(__d['editor']))
                except: append(__d['editor'].urllib.quote())
                append('&key=')
                append("""%s""" % __elt_entries['key'])
                append('">[Edit]</A><BR><A href="http://')
                append("""%s""" % __d['servername'])
                append('/cgi-bin/edit-entry?editor=')
                try: append(urllib.quote(__d['editor']))
                except: append(__d['editor'].urllib.quote())
                append('&key=')
                append("""%s""" % __elt_entries['key'])
                append('&zap=1">[Delete]</A>\012\011  <br><font size="-1">Submitter: ')
                try: append(get_email(__elt_entries))
                except: append(__elt_entries.get_email())
                append('</font>\012\011')
            else:
                append('\012\011  ')
                if __d['show_vcal']:
                    append('<TD><A href="http://')
                    append("""%s""" % __d['servername'])
                    append('/cgi-bin/gencal?type=vCalendar&key=')
                    append("""%s""" % __elt_entries['key'])
                    append('"><IMG SRC="/images/vcal.gif" ALIGN="top" ALT="vCal" width="16" height="16" border="0"></A>')
                append('\012\011')
            append('\012\012    ')
            try: append(html(__elt_entries))
            except: append(__elt_entries.html())
            append('\012\012    ')
            if (__i_entries == 0):
                append('\012\011')
                if __d['display_static']:
                    append('\012\011<td width="25%" valign=top rowspan=')
                    append("""%s""" % len(__d['entries']))
                    append('>\012\011    ')
                    if __d['static_info']:
                        append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><font size="+1"><a name="staticinfo">Notes Index</a></font></th></tr>\012\011\011  </table>\012\012\011\011')
                        if __d['stperformers']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stperf">Performers</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stperformers'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stcontributors']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th>Contributors</th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stcontributors'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stvenues']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stven">Venues</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stvenues'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stevents']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stev">Events</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stevents'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011')
                        if __d['stcities']:
                            append('\012\011\011  <table width="100%" cellpadding=2>\012\011\011  <tr><th><a name="stcity">Cities</a></th></tr>\012\011\011  <tr><td textcolor="black" bgcolor="white">\012\011\011    <font size="-1">\012\011\011    ')
                            append("""%s""" % __d['stcities'])
                            append('\012\011\011    </font>\012\011\011    </td></tr>\012\011\011  </table>\012\011\011')
                        append('\012\012\011\011<font size="-1">You can <strong><a\012\011\011href="http://www.musi-cal.com/addstatic.shtml">add</a></strong> or\012\011\011<strong><a href="http://www.musi-cal.com/editstatic.shtml">edit</a></strong>\012\011\011Notes Index items too!</font>\012\012\011    ')
                    append('\012\011    <p>\012\011    <a href="http://www.musi-cal.com/cgi-bin/redirect/http%3a//www.amazon.com/exec/obidos/redirect-home/musical">\012\011    <img src="http://www.musi-cal.com/icons/amzn-assoc.gif" border="0" alt="In Association with Amazon.com"></a> \012\011</td>\012\011')
                append('\012    ')
            append('\012\012    ')
        append('\012\012    </TABLE>\012\012    ')
        if __d['next']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['next'])
            append('">[Next Page]</a>\012    </font>\012    ')
        append('\012    ')
        if __d['prev']:
            append('\012    <font size="-1">\012      <a href="')
            append("""%s""" % __d['prev'])
            append('">[Previous Page]</a><br>\012    </font>\012    ')
        else:
            append('\012      ')
            if __d['next']:
                append('<br>')
            append('\012    ')
        append('\012\012    <P>Check with venues before making plans to attend listed events.\012\012    <P>If you notice any errors, <A\012    href="mailto:concertmaster@musi-cal.com">please let us know</A> so we can\012    correct them.\012\012')
    else:
        append('\012\012    ')
        if __d['searchbyperformer']:
            append('\012      <p>We were not able to find any matches to your search.  It\'s possible\012      the artist you were searching for is not on tour or that we don\'t\012      currently have their dates in our database. You might also try <a\012      href="http://')
            append("""%s""" % __d['servername'])
            append('/cgi-bin/list-perf">browsing by performer</a>\012      in case you\'ve misspelled their name.\012      If you know of a possible source for their concert schedule,\012      <a href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\012      ')
            if __d['stperformers']:
                append('\012\011<table width="100%" cellpadding=2>\012\011<tr><th><a name="stperf">Performers</a></th></tr>\012\011<tr><td textcolor="black" bgcolor="white">\012\011  <font size="-1">\012\011  ')
                append("""%s""" % __d['stperformers'])
                append('\012\011  </font>\012\011  </td></tr>\012\011</table>\012     ')
            append('\012\012   ')
        else:
            append('\012      ')
            if __d['searchbyvenue']:
                append('\012\011<p>We were not able to find any matches to your search.  Venue\012\011names can often spelled several different ways.  You might try\012\011searching for just a single word in the venue\'s name, such as\012\011<strong>Passim</strong> instead of <strong>Club Passim</strong>.\012\011Also, some venues, such as church-sponsored coffeehouses, may\012\011be listed either under the name of the coffeehouse or the name\012\011of the hosting venue.\012\011We may also not have their schedule in our database.\012\011If you know of a possible source for their concert schedule,\012\011<a href="mailto:concertmaster@musi-cal.com">let us know</a>.\012      ')
            else:
                append('\012\011')
                if __d['searchbyevent']:
                    append('\012\011  <p>We were not able to find any matches to your search.\012\011  If you know of a possible source for event schedules,\012\011  <a href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\011')
                else:
                    append('\012\011  ')
                    if __d['searchbylocation']:
                        append('\012      <p>We were not able to find any matches to your search.\012      Please check that the city, state and country names are\012      spelled or abbreviated properly.  You might also try <a\012      href="http://')
                        append("""%s""" % __d['servername'])
                        append('/index-geog.shtml">browsing by location</a>\012      in case you misspelled the name. If you know of a\012      possible source of concert schedules for this region, <a\012      href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\011  ')
                    else:
                        append('\012      <p>We were not able to find any matches to your search.\012      If you know of a possible source of concert schedules\012      that would fill a hole in our database, <a\012      href="mailto:concertmaster@musi-cal.com">let us know</a>.\012\011  ')
                    append('\012\011')
                append('\012      ')
            append('\012    ')
        append('\012\012')
    append('\012\012<P ALIGN="center"><CENTER>\012<p>\012<FORM METHOD="GET" ACTION="http://')
    append("""%s""" % __d['servername'])
    append('/cgi-bin/simple-search">\012<input type=radio name="key" value="performer">performer\012<input type=radio checked name="key" value="city">city\012<input type=radio name="key" value="venue">venue\012<input type=radio name="key" value="event">event<br>\012Search for: <INPUT TYPE="text" NAME="value">\012<input type="submit" value="OK">\012<br>')
    append("""%s""" % __d['survey'])
    append('\012</FORM></CENTER>\012\012\012<p align=center>\012<strong><font size="-1"><a href="/index-contribute.shtml"\012onMouseOver="window.status=\'Add events or Notes Index entries to the database\'; return true">Contribute</a> | <a href="/index-search.shtml"\012onMouseOver="window.status=\'Search the database in several ways\'; return true">Search</a> | <a href="/index-sponsor.shtml"\012onMouseOver="window.status=\'Advertise in Musi-Cal!\'; return true">Advertise</a> | <a href="/index-contents.shtml"\012onMouseOver="window.status=\'Let your mousey to the walking...\';return true">Contents</a> | <a href="/index-learn.shtml"\012onMouseOver="window.status=\'Stuck? Get help here...\'; return true">Help</a> | <a href="/Faq.shtml"\012onMouseOver="window.status=\'You got questions? We got answers...\'; return true">FAQ</a></font></strong>\012\012\012<p align=center>\012<A HREF="http://www.musi-cal.com/"><IMG border=0 WIDTH=23 HEIGHT=33 SRC="http://www.musi-cal.com/icons/not!
e.gif" ALT="[Musi-Cal Home Page]"></A>\012\012<font size="-1"><a href="mailto:concertmaster@musi-cal.com">Contact Us!</a><br><em>Copyright &#169; 1994-1999, Automatrix, Inc.</em>\012</font>\012\012\012\012</BODY>\012</HTML>\012')
    return string.join(output, '')


Follow-Ups:

Date: 2000-Oct-05 07:54
By: gvanrossum

Comment:
After 2.0 final is released.
-------------------------------------------------------

Date: 2000-Oct-05 15:26
By: tim_one

Comment:
Changed Category to Library, Summary to get "reindent" out of it, Group to Platform-specific, assigned to /F, and raised the Priority.

Skip, tell us which platform you're using.  It doesn't fail on Windows.  Also confirm that this is purely a problem with tokenize.py (e.g., does your test program also fail when run thru tabnanny.py, and/or checkappend.py?).

Since it doesn't fail for me, I can't whittle it down.  Strongly *suspect* it's due to your long string literals.  tokenize.py uses naive regexps for matching string literals, with bad performance characteristics.  If I were on a platform that failed, I'd

a) First whittle this down to a one-liner (pick on the line with the longest string literal).

b) Replace tokenize.py's string-literal regexps with the ones IDLE uses (which worked fine even on multimegabyte string literals, & much faster, in pre).

That wouldn't solve the underlying recursion limit problem, but would make it much harder to provoke.
-------------------------------------------------------

Date: 2000-Oct-05 18:45
By: montanaro

Comment:
Platform: Mandrake Linux 7.1
Python: latest CVS sources
One liner that fails is at

    http://www.musi-cal.com/~skip/srelimit.py

That fails when run through tabnanny or reindent

I can't see how to replace the tokenize string re's with IDLE's.  reindent and tabnanny both barf on

    pseudomatch = pseudoprog.match(line, pos)

As far as I can tell, PseudoToken (which is the re compiled into pseudoprog) doesn't appear to have much to do with matching strings other than recognizing the start of a triple-quoted string, which the problematic source file doesn't contain.



-------------------------------------------------------

Date: 2000-Oct-05 22:40
By: tim_one

Comment:
Thanks, Skip!  That confirms everything I suspected.

As to the connection to strings, pseudoprog *does* try to match "the first line" of single-quoted strings (via ContStr), which in your case is your entire 1200+ character single-quoted string literal.  That's where, e.g., the

([rR]?'(\\.|[^\n'\\])*('|\\\r?\n)

alternative in your pseudoprog dump comes from, and that's a terrible (for pragmatic reasons) regexp for matching long strings.  The IDLE-like alternative would be (re.VERBOSE)

(
[rR]?
'
[^\n'\\]*
(?: \\. [^\n'\\]*)*
(?: ' | \\ \r? \n)
)

This is just a vanilla instance of Friedl's

normal* (special normal*)*

"regexp unrolling", and saves your bacon for reasons spelled out in detail in his book.

-------------------------------------------------------

Date: 2000-Oct-06 22:13
By: tim_one

Comment:
Skip, please update and try this again.  I replaced tokenize.py's string regexps, and with a bit of luck that will sidestep your problem and we can get this bug off /F's back.
-------------------------------------------------------

Date: 2000-Oct-09 09:04
By: montanaro

Comment:
Works fine for me.  Thanks...

-------------------------------------------------------

Date: 2000-Oct-09 11:10
By: tim_one

Comment:
Closed and Fixed, since it works for Skip now.  BTW, Windows bumped into the same limit, but needed string literals about 8x longer than Skip's (~8Kb).  Verified that there's no problem now even for a 10Mb string literal, so that should cover most practical cases <wink>.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116136&group_id=5470


From noreply@sourceforge.net  Mon Oct  9 22:08:22 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 9 Oct 2000 14:08:22 -0700
Subject: [Python-bugs-list] [Bug #113811] Python 2.0 beta 1 -- urllib.urlopen() fails
Message-ID: <200010092108.OAA20881@delerium.i.sourceforge.net>

Bug #113811, was updated on 2000-Sep-07 09:45
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Works For Me
Bug Group: Irreproducible
Priority: 3
Summary: Python 2.0 beta 1 -- urllib.urlopen() fails

Details: In performing a urllib.urlopen(url) with "url" containing a valid URL, I got the following error message:

Traceback (most recent call last):
  File "IGNRatings.py", line 249, in ?
    main(sys.argv[1:])
  File "IGNRatings.py", line 132, in main
    inStream = urllib.urlopen(url)
  File "E:\Python20\lib\urllib.py", line 61, in urlopen
    return _urlopener.open(url)
  File "E:\Python20\lib\urllib.py", line 163, in open
    return getattr(self, name)(url)
  File "E:\Python20\lib\urllib.py", line 259, in open_http
    h = httplib.HTTP(host)
  File "E:\Python20\lib\httplib.py", line 626, in __init__
    self._conn = self._connection_class(host, port)
  File "E:\Python20\lib\httplib.py", line 325, in __init__
    self._set_hostport(host, port)
  File "E:\Python20\lib\httplib.py", line 332, in _set_hostport
    port = int(host[i+1:])
ValueError: invalid literal for int():


I looked into this a tiny bit and found that HTTPConnection.__init__() is called with host="http:" -- probably not the right thing. Python 1.6 works correctly.

Thanks,
Bob Alexander
bobalex@home.com

Follow-Ups:

Date: 2000-Sep-07 15:02
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-11 15:04
By: gvanrossum

Comment:
My suspicion is that this is caused by an invalid URL.
The stacktrace doesn't show what URL is being used, but I bet that on close inspection there's a tiny problem with it.

We'll have to close this for lack of information unless the original submittor can help us to debug this by printing the value of url in urlopen().
-------------------------------------------------------

Date: 2000-Oct-06 09:11
By: jhylton

Comment:
Have not heard back from original submittor.  I do not believe this is a bug and do not intend to fix it for 2.0.  Waiting a little longer to hear from Bob before closing this report.

-------------------------------------------------------

Date: 2000-Oct-09 14:08
By: jhylton

Comment:
Still no response.  Closing.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113811&group_id=5470


From noreply@sourceforge.net  Tue Oct 10 01:00:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 9 Oct 2000 17:00:06 -0700
Subject: [Python-bugs-list] [Bug #116453] Tkinter does not produce error messages
Message-ID: <200010100000.RAA27651@delerium.i.sourceforge.net>

Bug #116453, was updated on 2000-Oct-09 17:00
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Tkinter does not produce error messages

Details: In 1.5.2, doing l=Tkinter.Label(text1="bla") gives a traceback that ends with
TclError: unknown option "-text1"
In 2.0c1 (and any other recent version), with Tcl 8.3, it gives
TclError
It would be good if the error message would be provided as well.

According to tcl.h, direct access to interp->result is discouraged since 8.0; applications should use Tcl_GetObjResult (probably, GetStringResult is as good). I have not verified whether that solves the problem.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116453&group_id=5470


From noreply@sourceforge.net  Tue Oct 10 01:39:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 9 Oct 2000 17:39:13 -0700
Subject: [Python-bugs-list] [Bug #116453] Tkinter does not produce error messages
Message-ID: <200010100039.RAA29018@delerium.i.sourceforge.net>

Bug #116453, was updated on 2000-Oct-09 17:00
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Tkinter does not produce error messages

Details: In 1.5.2, doing l=Tkinter.Label(text1="bla") gives a traceback that ends with
TclError: unknown option "-text1"
In 2.0c1 (and any other recent version), with Tcl 8.3, it gives
TclError
It would be good if the error message would be provided as well.

According to tcl.h, direct access to interp->result is discouraged since 8.0; applications should use Tcl_GetObjResult (probably, GetStringResult is as good). I have not verified whether that solves the problem.

Follow-Ups:

Date: 2000-Oct-09 17:39
By: gvanrossum

Comment:
I cannot reproduce this with 2.0rc1 on Red Hat Linux 6.2, but I get the same phenomenon on Windows.

I 'll experiment with the suggestion after 2.0rc1 is released.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116453&group_id=5470


From noreply@sourceforge.net  Tue Oct 10 01:48:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 9 Oct 2000 17:48:13 -0700
Subject: [Python-bugs-list] [Bug #116271] corrupted wave file header
Message-ID: <200010100048.RAA29397@delerium.i.sourceforge.net>

Bug #116271, was updated on 2000-Oct-06 13:05
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: corrupted wave file header

Details: In module wave.py at line 442 (python2.0b2)
in method _write_header of Wave_write class
the format argument of struct.pack is incorrect:

it should be '<l4s4slhhllhh4s'
(sizes for strings were missing)

by the way, there is no test_wave.py.

here is a simple one:

import os, tempfile
import wave

nchannels = 2
sampwidth = 2
framerate = 8000
nframes = 100

testfile = tempfile.mktemp()

f = wave.open(testfile, 'w')
f.setnchannels(nchannels)
f.setsampwidth(sampwidth)
f.setframerate(framerate)
f.setnframes(nframes)
output = '\0' * nframes * nchannels * sampwidth
f.writeframes(output)
f.close()

f = wave.open(testfile, 'r')
assert nchannels == f.getnchannels()
assert sampwidth == f.getsampwidth()
assert framerate == f.getframerate()
assert nframes == f.getnframes()
input = f.readframes(nframes)
assert input == output
f.close()

os.remove(testfile)

Follow-Ups:

Date: 2000-Oct-09 17:48
By: gvanrossum

Comment:
Checked in (bug and test script) and closed. Thanks!

Your test script caused  a little last-minute scare: it broke on Windows. We discovered that the wave module never closes files even when it opened them. Serves us right for never testing it! Fixed now.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116271&group_id=5470


From noreply@sourceforge.net  Tue Oct 10 12:55:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Oct 2000 04:55:48 -0700
Subject: [Python-bugs-list] [Bug #110665] Compiling python on hpux 11.00 with threads (PR#360)
Message-ID: <200010101155.EAA22314@delerium.i.sourceforge.net>

Bug #110665, was updated on 2000-Jul-31 14:12
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: Compiling python on hpux 11.00 with threads (PR#360)

Details: Jitterbug-Id: 360
Submitted-By: philipp.jocham@salomon.at
Date: Fri, 16 Jun 2000 08:47:06 -0400 (EDT)
Version: 1.5.2
OS: HP-UX 11.00


There are two missing details in the configure process to make this work
out of the box.

First: The function 
	pthread_create
isn't found in library libpthread.a but in libcma.a, because
pthread_create is just a macro in sys/pthread.h pointing to 
	__pthread_create_system

After patching ./configure directly and running 
	./configure --with-thread
(now detecting the correct library /usr/lib/libpthread.a) I also
added -lcl to Modules/Makefile at
	LIBS=           -lnet -lnsl -ldld  -lpthread -lcl

otherwise importing of modules with threads didn't work 
(in this case oci_.sl from DCOracle). 

I'm not sure about the correct syntax or wether it's the correct
place and method, but I would suggest a solution like the following
code snippet.

[...]
AC_MSG_CHECKING(for --with-thread)
[...]
AC_DEFINE(_POSIX_THREADS)
LIBS="$LIBS -lpthread -lcl"
LIBOBJS="$LIBOBJS thread.o"], [
AC_CHECK_LIB(pthread, __pthread_create_system, [AC_DEFINE(WITH_THREAD)
[...]

I hope this helps to make installation process smoother.
Fell free to contact me, if there are further questions.
Philipp
-- 
I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.



====================================================================
Audit trail:
Tue Jul 11 08:26:01 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-22 02:56
By: gvanrossum

Comment:
Taking this because I'm considering to redesign the thread configuration section in configure.in anyway -- there's a similar bug report for Alpha OSF1.
-------------------------------------------------------

Date: 2000-Sep-25 06:10
By: gvanrossum

Comment:
I'm hoping that this was fixed by recent changes. Sent an email to the original submittor to verify.
-------------------------------------------------------

Date: 2000-Oct-06 10:40
By: gvanrossum

Comment:
I have two reports from people for whom configure, build and run  with threads now works on HP-UX 10 and 11. I'm not sure what to do about this report... What's different on Philipp's system???
-------------------------------------------------------

Date: 2000-Oct-10 04:55
By: edg

Comment:
I can confirm that the bug still exists in 2.0c1.
It works fine on HP-UX 10.20 (which only has libcma),
but not on HP-UX 11 (which both has libcma and libpthread).
The pthread_create function is not defined as a macro though,
but as a static function:

static int pthread_create(pthread_t *tid, const pthread_attr_t *attr, void *(*start_routine)(void *), void *arg)
   { return(__pthread_create_system(tid, attr, start_routine, arg)); }

I don't see an easy way to work around this.
I'm not a configure expert, but perhaps the script should
first check whether this code compiles and links:

#include <pthread.h>
int main()
{
   pthread_create(0,0,0,0);
   return 0;
}

and if not, fall back on the other tests ?

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110665&group_id=5470


From noreply@sourceforge.net  Tue Oct 10 17:51:02 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Oct 2000 09:51:02 -0700
Subject: [Python-bugs-list] [Bug #116516] test_sre.py fails on Win64 because PyOS_CheckStack *never* f
Message-ID: <200010101651.JAA02411@delerium.i.sourceforge.net>

Bug #116516, was updated on 2000-Oct-10 09:51
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: test_sre.py fails on Win64 because PyOS_CheckStack *never* f

Details: There is a small thread on python-dev discussing this:

   http://www.python.org/pipermail/python-dev/2000-October/016455.html

Basically I found that PyOS_CheckStack does not fire as expected on Win64. Looking into this more I got frustrated with PyOS_CheckStack's behaviour on *Win32*. There is a simple workaround (the existing RECURSION_LIMIT framework) that could simply be turned on to ensure that test_[s]re.py run for Python 2.0. The PyOS_CheckStack behavious on Win64 can be figured out when it become more mainstream.

The proposed fix is:

*** Include\pythonrun.h~     Wed Oct 04 14:18:00 2000
--- Include\pythonrun.h      Wed Oct 04 13:17:17 2000
***************
*** 88,94 ****
     to a 8k margin. */
  #define PYOS_STACK_MARGIN 2048

! #if defined(WIN32) && defined(_MSC_VER)
  /* Enable stack checking under Microsoft C */
  #define USE_STACKCHECK
  #endif
--- 88,94 ----
     to a 8k margin. */
  #define PYOS_STACK_MARGIN 2048

! #if defined(WIN32) && !defined(MS_WIN64) && defined(_MSC_VER)
  /* Enable stack checking under Microsoft C */
  #define USE_STACKCHECK
  #endif




For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116516&group_id=5470


From noreply@sourceforge.net  Tue Oct 10 17:51:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Oct 2000 09:51:52 -0700
Subject: [Python-bugs-list] [Bug #116516] test_sre.py fails on Win64 because PyOS_CheckStack *never* f
Message-ID: <200010101651.JAA02434@delerium.i.sourceforge.net>

Bug #116516, was updated on 2000-Oct-10 09:51
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: test_sre.py fails on Win64 because PyOS_CheckStack *never* f

Details: There is a small thread on python-dev discussing this:

   http://www.python.org/pipermail/python-dev/2000-October/016455.html

Basically I found that PyOS_CheckStack does not fire as expected on Win64. Looking into this more I got frustrated with PyOS_CheckStack's behaviour on *Win32*. There is a simple workaround (the existing RECURSION_LIMIT framework) that could simply be turned on to ensure that test_[s]re.py run for Python 2.0. The PyOS_CheckStack behavious on Win64 can be figured out when it become more mainstream.

The proposed fix is:

*** Include\pythonrun.h~     Wed Oct 04 14:18:00 2000
--- Include\pythonrun.h      Wed Oct 04 13:17:17 2000
***************
*** 88,94 ****
     to a 8k margin. */
  #define PYOS_STACK_MARGIN 2048

! #if defined(WIN32) && defined(_MSC_VER)
  /* Enable stack checking under Microsoft C */
  #define USE_STACKCHECK
  #endif
--- 88,94 ----
     to a 8k margin. */
  #define PYOS_STACK_MARGIN 2048

! #if defined(WIN32) && !defined(MS_WIN64) && defined(_MSC_VER)
  /* Enable stack checking under Microsoft C */
  #define USE_STACKCHECK
  #endif




For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116516&group_id=5470


From noreply@sourceforge.net  Tue Oct 10 19:45:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Oct 2000 11:45:48 -0700
Subject: [Python-bugs-list] [Bug #116295] pickle fails to reduce class instances as documented
Message-ID: <200010101845.LAA12689@bush.i.sourceforge.net>

Bug #116295, was updated on 2000-Oct-06 21:21
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: pickle fails to reduce class instances as documented

Details: According to the documentation of module copy_reg, copy_reg.pickle registers reduction functions for types and classes, which are then used by module pickle to reduce objects to a function and a tuple of arguments.  However, module pickle (and probably also cPickle) does not use registered reduction functions to reduce class instances.  Therefore, either the documentation of module copy_reg or the implementation of module pickle (and cPickle) is wrong.

Follow-Ups:

Date: 2000-Oct-09 05:59
By: gvanrossum

Comment:
The copy_reg module is only for extension types. So this seems a documentation error. Fred?
-------------------------------------------------------

Date: 2000-Oct-10 11:45
By: fdrake

Comment:
Revised documentation Doc/lib/libcopyreg.tex revision 1.8.  Closing this report since this should be sufficient.

I've also posted a patch (#101859) that changes the implementation to raise a TypeError when a class is passed in for the type in the first place, which would have avoided the whole problem.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116295&group_id=5470


From noreply@sourceforge.net  Tue Oct 10 22:59:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Oct 2000 14:59:21 -0700
Subject: [Python-bugs-list] [Bug #116546] test_longexp.py causes apparently endless page thrashing
Message-ID: <200010102159.OAA20683@bush.i.sourceforge.net>

Bug #116546, was updated on 2000-Oct-10 14:59
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: test_longexp.py causes apparently endless page thrashing

Details: 2.0 release candidate 1, built from source on a SPARCstation LX w/64 MB,
fails to run the test_longexp.py test.  The disk became very active (page
thrashing?), the window system became non-responsive to mouse button
clicks, and the cursor followed mouse movement only sluggishly.

The system also became non-responsive to network requests, attempts to
ping and to telnet both failing.

At present values of up to 10000 for REPS have been validated as OK.

I will leave an overnight test running with the original value to see if it
completes (having terminated the original test after 30 min).

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116546&group_id=5470


From noreply@sourceforge.net  Tue Oct 10 23:02:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Oct 2000 15:02:28 -0700
Subject: [Python-bugs-list] [Bug #116547] test_poll.py fails on SPARCstation LX under Red Hat 5.2
Message-ID: <200010102202.PAA20911@bush.i.sourceforge.net>

Bug #116547, was updated on 2000-Oct-10 15:02
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: test_poll.py fails on SPARCstation LX under Red Hat 5.2

Details: Attached is a traceback from running the test manually.

Running poll test 1
 This is a test.
 This is a test.
 This is a test.
 This is a test.
 This is a test.
 This is a test.
 This is a test.
 This is a test.
 This is a test.
 This is a test.
 This is a test.
 This is a test.
Traceback (most recent call last):
  File "./Lib/test/test_poll.py", line 171, in ?
    test_poll1()
  File "./Lib/test/test_poll.py", line 65, in test_poll1
    poll_unit_tests()
  File "./Lib/test/test_poll.py", line 77, in poll_unit_tests
    r = p.poll()
select.error: (9, 'Bad file descriptor')

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116547&group_id=5470


From noreply@sourceforge.net  Wed Oct 11 04:18:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 10 Oct 2000 20:18:11 -0700
Subject: [Python-bugs-list] [Bug #116547] test_poll.py fails on SPARCstation LX under Red Hat 5.2
Message-ID: <200010110318.UAA26596@delerium.i.sourceforge.net>

Bug #116547, was updated on 2000-Oct-10 15:02
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: test_poll.py fails on SPARCstation LX under Red Hat 5.2

Details: Attached is a traceback from running the test manually.

Running poll test 1
 This is a test.
 This is a test.
 This is a test.
 This is a test.
 This is a test.
 This is a test.
 This is a test.
 This is a test.
 This is a test.
 This is a test.
 This is a test.
 This is a test.
Traceback (most recent call last):
  File "./Lib/test/test_poll.py", line 171, in ?
    test_poll1()
  File "./Lib/test/test_poll.py", line 65, in test_poll1
    poll_unit_tests()
  File "./Lib/test/test_poll.py", line 77, in poll_unit_tests
    r = p.poll()
select.error: (9, 'Bad file descriptor')

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116547&group_id=5470


From noreply@sourceforge.net  Wed Oct 11 11:56:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Oct 2000 03:56:10 -0700
Subject: [Python-bugs-list] [Bug #116516] test_sre.py fails on Win64 because PyOS_CheckStack *never* f
Message-ID: <200010111056.DAA16596@bush.i.sourceforge.net>

Bug #116516, was updated on 2000-Oct-10 09:51
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: test_sre.py fails on Win64 because PyOS_CheckStack *never* f

Details: There is a small thread on python-dev discussing this:

   http://www.python.org/pipermail/python-dev/2000-October/016455.html

Basically I found that PyOS_CheckStack does not fire as expected on Win64. Looking into this more I got frustrated with PyOS_CheckStack's behaviour on *Win32*. There is a simple workaround (the existing RECURSION_LIMIT framework) that could simply be turned on to ensure that test_[s]re.py run for Python 2.0. The PyOS_CheckStack behavious on Win64 can be figured out when it become more mainstream.

The proposed fix is:

*** Include\pythonrun.h~     Wed Oct 04 14:18:00 2000
--- Include\pythonrun.h      Wed Oct 04 13:17:17 2000
***************
*** 88,94 ****
     to a 8k margin. */
  #define PYOS_STACK_MARGIN 2048

! #if defined(WIN32) && defined(_MSC_VER)
  /* Enable stack checking under Microsoft C */
  #define USE_STACKCHECK
  #endif
--- 88,94 ----
     to a 8k margin. */
  #define PYOS_STACK_MARGIN 2048

! #if defined(WIN32) && !defined(MS_WIN64) && defined(_MSC_VER)
  /* Enable stack checking under Microsoft C */
  #define USE_STACKCHECK
  #endif




Follow-Ups:

Date: 2000-Oct-11 03:56
By: effbot

Comment:
Looks like this is the only reasonable thing to do
before 2.0 final.  Can you check it in?

</F>
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116516&group_id=5470


From noreply@sourceforge.net  Wed Oct 11 14:18:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Oct 2000 06:18:57 -0700
Subject: [Python-bugs-list] [Bug #116546] test_longexp.py causes apparently endless page thrashing
Message-ID: <200010111318.GAA22264@bush.i.sourceforge.net>

Bug #116546, was updated on 2000-Oct-10 14:59
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: test_longexp.py causes apparently endless page thrashing

Details: 2.0 release candidate 1, built from source on a SPARCstation LX w/64 MB,
fails to run the test_longexp.py test.  The disk became very active (page
thrashing?), the window system became non-responsive to mouse button
clicks, and the cursor followed mouse movement only sluggishly.

The system also became non-responsive to network requests, attempts to
ping and to telnet both failing.

At present values of up to 10000 for REPS have been validated as OK.

I will leave an overnight test running with the original value to see if it
completes (having terminated the original test after 30 min).

Follow-Ups:

Date: 2000-Oct-11 06:18
By: holdenweb

Comment:
The overnight output tends to suggest the test is causing severe problems for
the operating system.  I believe the termination was due to over-consumption
of resources, but if it can't complete in 2:41 then I have a suspicion it never will.

[sholden@holden Python-2.0c1]$ time ./python ./Lib/test/test_longexp.py
Command terminated by signal 9
7.37user 492.86system 2:41:00elapsed 5%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (54713major+3735minor)pagefaults 6965swaps

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116546&group_id=5470


From noreply@sourceforge.net  Wed Oct 11 14:22:49 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Oct 2000 06:22:49 -0700
Subject: [Python-bugs-list] [Bug #116603] Files missing in Demo/p2c
Message-ID: <200010111322.GAA22440@bush.i.sourceforge.net>

Bug #116603, was updated on 2000-Oct-11 06:22
Here is a current snapshot of the bug.

Project: Python
Category: demos and tools
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Files missing in Demo/p2c

Details: This directory contains no files :-(

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116603&group_id=5470


From noreply@sourceforge.net  Wed Oct 11 14:24:33 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Oct 2000 06:24:33 -0700
Subject: [Python-bugs-list] [Bug #116604] Files missing in Tools/perfecthash
Message-ID: <200010111324.GAA22506@bush.i.sourceforge.net>

Bug #116604, was updated on 2000-Oct-11 06:24
Here is a current snapshot of the bug.

Project: Python
Category: demos and tools
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Files missing in Tools/perfecthash

Details: This directory contains no files :-(

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116604&group_id=5470


From noreply@sourceforge.net  Wed Oct 11 14:48:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Oct 2000 06:48:32 -0700
Subject: [Python-bugs-list] [Bug #116546] test_longexp.py causes apparently endless page thrashing
Message-ID: <200010111348.GAA23461@bush.i.sourceforge.net>

Bug #116546, was updated on 2000-Oct-10 14:59
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: test_longexp.py causes apparently endless page thrashing

Details: 2.0 release candidate 1, built from source on a SPARCstation LX w/64 MB,
fails to run the test_longexp.py test.  The disk became very active (page
thrashing?), the window system became non-responsive to mouse button
clicks, and the cursor followed mouse movement only sluggishly.

The system also became non-responsive to network requests, attempts to
ping and to telnet both failing.

At present values of up to 10000 for REPS have been validated as OK.

I will leave an overnight test running with the original value to see if it
completes (having terminated the original test after 30 min).

Follow-Ups:

Date: 2000-Oct-11 06:18
By: holdenweb

Comment:
The overnight output tends to suggest the test is causing severe problems for
the operating system.  I believe the termination was due to over-consumption
of resources, but if it can't complete in 2:41 then I have a suspicion it never will.

[sholden@holden Python-2.0c1]$ time ./python ./Lib/test/test_longexp.py
Command terminated by signal 9
7.37user 492.86system 2:41:00elapsed 5%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (54713major+3735minor)pagefaults 6965swaps

-------------------------------------------------------

Date: 2000-Oct-11 06:48
By: gvanrossum

Comment:
It seems the test clearly uses more memory than the machine has.

So is this a Python bug or should the user just give up?

Is it worth that the test uses that much memory?

Could the test be changed to use less memory when invoked as part of the regression test?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116546&group_id=5470


From noreply@sourceforge.net  Wed Oct 11 14:50:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Oct 2000 06:50:03 -0700
Subject: [Python-bugs-list] [Bug #116603] Files missing in Demo/p2c
Message-ID: <200010111350.GAA23515@bush.i.sourceforge.net>

Bug #116603, was updated on 2000-Oct-11 06:22
Here is a current snapshot of the bug.

Project: Python
Category: demos and tools
Status: Closed
Resolution: Wont Fix
Bug Group: Not a Bug
Priority: 5
Summary: Files missing in Demo/p2c

Details: This directory contains no files :-(

Follow-Ups:

Date: 2000-Oct-11 06:50
By: gvanrossum

Comment:
This is a directlry that once existed but is no longer needed.

CVS doesn't let you delete this from the repository.

However you can get rid of it by using "cvs update -P" in the Demo directory.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116603&group_id=5470


From noreply@sourceforge.net  Wed Oct 11 15:43:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Oct 2000 07:43:29 -0700
Subject: [Python-bugs-list] [Bug #116604] Files missing in Tools/perfecthash
Message-ID: <200010111443.HAA25676@bush.i.sourceforge.net>

Bug #116604, was updated on 2000-Oct-11 06:24
Here is a current snapshot of the bug.

Project: Python
Category: demos and tools
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Files missing in Tools/perfecthash

Details: This directory contains no files :-(

Follow-Ups:

Date: 2000-Oct-11 07:43
By: none

Comment:
Untaring the 2.0 release candidate archive creates this directory
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116604&group_id=5470


From noreply@sourceforge.net  Wed Oct 11 18:31:33 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Oct 2000 10:31:33 -0700
Subject: [Python-bugs-list] [Bug #116516] test_sre.py fails on Win64 because PyOS_CheckStack *never* f
Message-ID: <200010111731.KAA32619@bush.i.sourceforge.net>

Bug #116516, was updated on 2000-Oct-10 09:51
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Summary: test_sre.py fails on Win64 because PyOS_CheckStack *never* f

Details: There is a small thread on python-dev discussing this:

   http://www.python.org/pipermail/python-dev/2000-October/016455.html

Basically I found that PyOS_CheckStack does not fire as expected on Win64. Looking into this more I got frustrated with PyOS_CheckStack's behaviour on *Win32*. There is a simple workaround (the existing RECURSION_LIMIT framework) that could simply be turned on to ensure that test_[s]re.py run for Python 2.0. The PyOS_CheckStack behavious on Win64 can be figured out when it become more mainstream.

The proposed fix is:

*** Include\pythonrun.h~     Wed Oct 04 14:18:00 2000
--- Include\pythonrun.h      Wed Oct 04 13:17:17 2000
***************
*** 88,94 ****
     to a 8k margin. */
  #define PYOS_STACK_MARGIN 2048

! #if defined(WIN32) && defined(_MSC_VER)
  /* Enable stack checking under Microsoft C */
  #define USE_STACKCHECK
  #endif
--- 88,94 ----
     to a 8k margin. */
  #define PYOS_STACK_MARGIN 2048

! #if defined(WIN32) && !defined(MS_WIN64) && defined(_MSC_VER)
  /* Enable stack checking under Microsoft C */
  #define USE_STACKCHECK
  #endif




Follow-Ups:

Date: 2000-Oct-11 03:56
By: effbot

Comment:
Looks like this is the only reasonable thing to do
before 2.0 final.  Can you check it in?

</F>
-------------------------------------------------------

Date: 2000-Oct-11 10:31
By: tmick

Comment:
Okay, I checked in the suggested patch
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116516&group_id=5470


From noreply@sourceforge.net  Wed Oct 11 18:53:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Oct 2000 10:53:30 -0700
Subject: [Python-bugs-list] [Bug #116636] Bug in StringIO.write()
Message-ID: <200010111753.KAA27089@delerium.i.sourceforge.net>

Bug #116636, was updated on 2000-Oct-11 10:53
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Bug in StringIO.write()

Details: If the file position is less than the end of the "file", and a write is performed extending past then end of the file, the data string is corrupted. 100% reliable failure on all platforms!

This is apparently an old bug (since 1.5.2 at least), but still exists in 2.0c1.

To reproduce:

	s = StringIO("abcdef")
	s.seek(3)
	s.write("uvwxyz")	# write data that starts before the end
				# of the buffer and extends beyond the end
				# (self.len is not properly updated in this case)
	s.write("m")		# this incorrectly pads the buffer with '\0'
	print `s.getvalue()`

The result is:

	'abcuvwxyz\000\000\000m'

I fixed my copy by adding the following lines to the StingIO.write method:

	def write(self, s):
		if self.closed:
			raise ValueError, "I/O operation on closed file"
		if not s: return
		if self.pos > self.len:
			self.buflist.append('\0'*(self.pos - self.len))
			self.len = self.pos
		newpos = self.pos + len(s)
		if self.pos < self.len:
			if self.buflist:
				self.buf = self.buf + string.joinfields(self.buflist, '')
				self.buflist = []
			self.buflist = [self.buf[:self.pos], s, self.buf[newpos:]]
			self.buf = ''
			if self.len < newpos:		# ADDED LINE
				self.len = newpos	# ADDED LINE
		else:
			self.buflist.append(s)
			self.len = newpos
		self.pos = newpos

Bob
bobalex@rsv.ricoh.com


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116636&group_id=5470


From noreply@sourceforge.net  Wed Oct 11 20:04:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Oct 2000 12:04:06 -0700
Subject: [Python-bugs-list] [Bug #116649] urllib2.urlopen fails on redirects?
Message-ID: <200010111904.MAA30049@delerium.i.sourceforge.net>

Bug #116649, was updated on 2000-Oct-11 12:04
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: urllib2.urlopen fails on redirects?

Details: The following code produces an AttributeError exception un urllib2.  The equivalent code run from urllib works ok.  This was tested on Windows 2000, Python 2.0 Release Candidate 1.

### TEST CODE ########################
def testUrlRedirect(url):
	print "urllib.urlopen - ",
	u = urllib.urlopen(url)
	print "SUCCESS"

	print "urllib2.urlopen - ",
	u = urllib2.urlopen(url)
	print "SUCCESS"
testUrlRedirect('http://www.realestatemarketing.com')


### OUTPUT ##########################
urllib.urlopen -  SUCCESS
urllib2.urlopen -
Traceback (most recent call last):
  File "C:\dev_share\ffs\bin\brokers.py", line 38, in ?
    testUrlRedirect('http://www.realestatemarketing.com')
  File "C:\dev_share\ffs\bin\brokers.py", line 34, in testUrlRedirect
    u = urllib2.urlopen(url)
  File "c:\python20\lib\urllib2.py", line 137, in urlopen
    return _opener.open(url, data)
  File "c:\python20\lib\urllib2.py", line 321, in open
    '_open', req)
  File "c:\python20\lib\urllib2.py", line 300, in _call_chain
    result = apply(func, args)
  File "c:\python20\lib\urllib2.py", line 757, in http_open
    if h.sock:
AttributeError: 'HTTP' instance has no attribute 'sock'

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116649&group_id=5470


From noreply@sourceforge.net  Wed Oct 11 20:37:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Oct 2000 12:37:35 -0700
Subject: [Python-bugs-list] [Bug #116453] [Windows] TclError does not always produce error messages
Message-ID: <200010111937.MAA05430@bush.i.sourceforge.net>

Bug #116453, was updated on 2000-Oct-09 17:00
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: [Windows] TclError does not always produce error messages

Details: In 1.5.2, doing l=Tkinter.Label(text1="bla") gives a traceback that ends with
TclError: unknown option "-text1"
In 2.0c1 (and any other recent version), with Tcl 8.3, it gives
TclError
It would be good if the error message would be provided as well.

According to tcl.h, direct access to interp->result is discouraged since 8.0; applications should use Tcl_GetObjResult (probably, GetStringResult is as good). I have not verified whether that solves the problem.

Follow-Ups:

Date: 2000-Oct-09 17:39
By: gvanrossum

Comment:
I cannot reproduce this with 2.0rc1 on Red Hat Linux 6.2, but I get the same phenomenon on Windows.

I 'll experiment with the suggestion after 2.0rc1 is released.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116453&group_id=5470


From noreply@sourceforge.net  Wed Oct 11 20:39:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Oct 2000 12:39:04 -0700
Subject: [Python-bugs-list] [Bug #116546] test_longexp.py causes apparently endless page thrashing
Message-ID: <200010111939.MAA05550@bush.i.sourceforge.net>

Bug #116546, was updated on 2000-Oct-10 14:59
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: test_longexp.py causes apparently endless page thrashing

Details: 2.0 release candidate 1, built from source on a SPARCstation LX w/64 MB,
fails to run the test_longexp.py test.  The disk became very active (page
thrashing?), the window system became non-responsive to mouse button
clicks, and the cursor followed mouse movement only sluggishly.

The system also became non-responsive to network requests, attempts to
ping and to telnet both failing.

At present values of up to 10000 for REPS have been validated as OK.

I will leave an overnight test running with the original value to see if it
completes (having terminated the original test after 30 min).

Follow-Ups:

Date: 2000-Oct-11 06:18
By: holdenweb

Comment:
The overnight output tends to suggest the test is causing severe problems for
the operating system.  I believe the termination was due to over-consumption
of resources, but if it can't complete in 2:41 then I have a suspicion it never will.

[sholden@holden Python-2.0c1]$ time ./python ./Lib/test/test_longexp.py
Command terminated by signal 9
7.37user 492.86system 2:41:00elapsed 5%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (54713major+3735minor)pagefaults 6965swaps

-------------------------------------------------------

Date: 2000-Oct-11 06:48
By: gvanrossum

Comment:
It seems the test clearly uses more memory than the machine has.

So is this a Python bug or should the user just give up?

Is it worth that the test uses that much memory?

Could the test be changed to use less memory when invoked as part of the regression test?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116546&group_id=5470


From noreply@sourceforge.net  Wed Oct 11 20:40:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Oct 2000 12:40:13 -0700
Subject: [Python-bugs-list] [Bug #116546] test_longexp.py causes apparently endless page thrashing
Message-ID: <200010111940.MAA05566@bush.i.sourceforge.net>

Bug #116546, was updated on 2000-Oct-10 14:59
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: Wont Fix
Bug Group: Platform-specific
Priority: 5
Summary: test_longexp.py causes apparently endless page thrashing

Details: 2.0 release candidate 1, built from source on a SPARCstation LX w/64 MB,
fails to run the test_longexp.py test.  The disk became very active (page
thrashing?), the window system became non-responsive to mouse button
clicks, and the cursor followed mouse movement only sluggishly.

The system also became non-responsive to network requests, attempts to
ping and to telnet both failing.

At present values of up to 10000 for REPS have been validated as OK.

I will leave an overnight test running with the original value to see if it
completes (having terminated the original test after 30 min).

Follow-Ups:

Date: 2000-Oct-11 06:18
By: holdenweb

Comment:
The overnight output tends to suggest the test is causing severe problems for
the operating system.  I believe the termination was due to over-consumption
of resources, but if it can't complete in 2:41 then I have a suspicion it never will.

[sholden@holden Python-2.0c1]$ time ./python ./Lib/test/test_longexp.py
Command terminated by signal 9
7.37user 492.86system 2:41:00elapsed 5%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (54713major+3735minor)pagefaults 6965swaps

-------------------------------------------------------

Date: 2000-Oct-11 06:48
By: gvanrossum

Comment:
It seems the test clearly uses more memory than the machine has.

So is this a Python bug or should the user just give up?

Is it worth that the test uses that much memory?

Could the test be changed to use less memory when invoked as part of the regression test?
-------------------------------------------------------

Date: 2000-Oct-11 12:40
By: fdrake

Comment:
This is simply due to memory starvation -- not a Python problem.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116546&group_id=5470


From noreply@sourceforge.net  Wed Oct 11 20:43:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Oct 2000 12:43:11 -0700
Subject: [Python-bugs-list] [Bug #116604] Files missing in Tools/perfecthash
Message-ID: <200010111943.MAA05753@bush.i.sourceforge.net>

Bug #116604, was updated on 2000-Oct-11 06:24
Here is a current snapshot of the bug.

Project: Python
Category: demos and tools
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: Files missing in Tools/perfecthash

Details: This directory contains no files :-(

Follow-Ups:

Date: 2000-Oct-11 07:43
By: none

Comment:
Untaring the 2.0 release candidate archive creates this directory
-------------------------------------------------------

Date: 2000-Oct-11 12:43
By: fdrake

Comment:
Not a bug.  Use "cvs up -P" to remove this directory; the files were removed since they are no longer needed.  They were only checked in to this location by mistake.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116604&group_id=5470


From noreply@sourceforge.net  Wed Oct 11 20:44:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Oct 2000 12:44:30 -0700
Subject: [Python-bugs-list] [Bug #116636] Bug in StringIO.write()
Message-ID: <200010111944.MAA05758@bush.i.sourceforge.net>

Bug #116636, was updated on 2000-Oct-11 10:53
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Bug in StringIO.write()

Details: If the file position is less than the end of the "file", and a write is performed extending past then end of the file, the data string is corrupted. 100% reliable failure on all platforms!

This is apparently an old bug (since 1.5.2 at least), but still exists in 2.0c1.

To reproduce:

	s = StringIO("abcdef")
	s.seek(3)
	s.write("uvwxyz")	# write data that starts before the end
				# of the buffer and extends beyond the end
				# (self.len is not properly updated in this case)
	s.write("m")		# this incorrectly pads the buffer with '\0'
	print `s.getvalue()`

The result is:

	'abcuvwxyz\000\000\000m'

I fixed my copy by adding the following lines to the StingIO.write method:

	def write(self, s):
		if self.closed:
			raise ValueError, "I/O operation on closed file"
		if not s: return
		if self.pos > self.len:
			self.buflist.append('\0'*(self.pos - self.len))
			self.len = self.pos
		newpos = self.pos + len(s)
		if self.pos < self.len:
			if self.buflist:
				self.buf = self.buf + string.joinfields(self.buflist, '')
				self.buflist = []
			self.buflist = [self.buf[:self.pos], s, self.buf[newpos:]]
			self.buf = ''
			if self.len < newpos:		# ADDED LINE
				self.len = newpos	# ADDED LINE
		else:
			self.buflist.append(s)
			self.len = newpos
		self.pos = newpos

Bob
bobalex@rsv.ricoh.com


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116636&group_id=5470


From noreply@sourceforge.net  Wed Oct 11 20:45:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Oct 2000 12:45:27 -0700
Subject: [Python-bugs-list] [Bug #116649] urllib2.urlopen fails on redirects?
Message-ID: <200010111945.MAA05774@bush.i.sourceforge.net>

Bug #116649, was updated on 2000-Oct-11 12:04
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: urllib2.urlopen fails on redirects?

Details: The following code produces an AttributeError exception un urllib2.  The equivalent code run from urllib works ok.  This was tested on Windows 2000, Python 2.0 Release Candidate 1.

### TEST CODE ########################
def testUrlRedirect(url):
	print "urllib.urlopen - ",
	u = urllib.urlopen(url)
	print "SUCCESS"

	print "urllib2.urlopen - ",
	u = urllib2.urlopen(url)
	print "SUCCESS"
testUrlRedirect('http://www.realestatemarketing.com')


### OUTPUT ##########################
urllib.urlopen -  SUCCESS
urllib2.urlopen -
Traceback (most recent call last):
  File "C:\dev_share\ffs\bin\brokers.py", line 38, in ?
    testUrlRedirect('http://www.realestatemarketing.com')
  File "C:\dev_share\ffs\bin\brokers.py", line 34, in testUrlRedirect
    u = urllib2.urlopen(url)
  File "c:\python20\lib\urllib2.py", line 137, in urlopen
    return _opener.open(url, data)
  File "c:\python20\lib\urllib2.py", line 321, in open
    '_open', req)
  File "c:\python20\lib\urllib2.py", line 300, in _call_chain
    result = apply(func, args)
  File "c:\python20\lib\urllib2.py", line 757, in http_open
    if h.sock:
AttributeError: 'HTTP' instance has no attribute 'sock'

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116649&group_id=5470


From noreply@sourceforge.net  Wed Oct 11 23:10:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Oct 2000 15:10:46 -0700
Subject: [Python-bugs-list] [Bug #116664] Crash starting "idle" (2.0c1)
Message-ID: <200010112210.PAA05057@delerium.i.sourceforge.net>

Bug #116664, was updated on 2000-Oct-11 15:10
Here is a current snapshot of the bug.

Project: Python
Category: demos and tools
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Crash starting "idle" (2.0c1)

Details: Starting idle (under Mandrake Linux 7.1), I get the following traceback(s):


[bobalex@bobalex bobalex]$ '/home/bobalex/python20/Tools/idle/idle.py'
Failed to load extension 'AutoIndent'
Traceback (innermost last):
  File "/home/bobalex/python20/Tools/idle/EditorWindow.py", line 536, in load_standard_extensions
    self.load_extension(name)
  File "/home/bobalex/python20/Tools/idle/EditorWindow.py", line 546, in load_extension
    mod = __import__(name, globals(), locals(), [])
  File "/home/bobalex/python20/Tools/idle/AutoIndent.py", line 38, in ?
    import PyParse
  File "/home/bobalex/python20/Tools/idle/PyParse.py", line 116
     if type(str) == type(u""):
                            ^
 SyntaxError: invalid syntax
Traceback (innermost last):
  File "/home/bobalex/python20/Tools/idle/idle.py", line 12, in ?
    PyShell.main()
  File "/home/bobalex/python20/Tools/idle/PyShell.py", line 747, in main
    shell = PyShell(flist)
  File "/home/bobalex/python20/Tools/idle/PyShell.py", line 312, in __init__
    self.auto = self.extensions["AutoIndent"] # Required extension
KeyError: AutoIndent                                   


Bob Alexander
balexander@rsv.ricoh.com                         

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116664&group_id=5470


From noreply@sourceforge.net  Wed Oct 11 23:31:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Oct 2000 15:31:43 -0700
Subject: [Python-bugs-list] [Bug #116664] Crash starting "idle" (2.0c1)
Message-ID: <200010112231.PAA05870@delerium.i.sourceforge.net>

Bug #116664, was updated on 2000-Oct-11 15:10
Here is a current snapshot of the bug.

Project: Python
Category: demos and tools
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: Crash starting "idle" (2.0c1)

Details: Starting idle (under Mandrake Linux 7.1), I get the following traceback(s):


[bobalex@bobalex bobalex]$ '/home/bobalex/python20/Tools/idle/idle.py'
Failed to load extension 'AutoIndent'
Traceback (innermost last):
  File "/home/bobalex/python20/Tools/idle/EditorWindow.py", line 536, in load_standard_extensions
    self.load_extension(name)
  File "/home/bobalex/python20/Tools/idle/EditorWindow.py", line 546, in load_extension
    mod = __import__(name, globals(), locals(), [])
  File "/home/bobalex/python20/Tools/idle/AutoIndent.py", line 38, in ?
    import PyParse
  File "/home/bobalex/python20/Tools/idle/PyParse.py", line 116
     if type(str) == type(u""):
                            ^
 SyntaxError: invalid syntax
Traceback (innermost last):
  File "/home/bobalex/python20/Tools/idle/idle.py", line 12, in ?
    PyShell.main()
  File "/home/bobalex/python20/Tools/idle/PyShell.py", line 747, in main
    shell = PyShell(flist)
  File "/home/bobalex/python20/Tools/idle/PyShell.py", line 312, in __init__
    self.auto = self.extensions["AutoIndent"] # Required extension
KeyError: AutoIndent                                   


Bob Alexander
balexander@rsv.ricoh.com                         

Follow-Ups:

Date: 2000-Oct-11 15:31
By: gvanrossum

Comment:
Check out the first line of idle.py. It points to a previous version of Python (probably 1.5.2 installed in /usr/bin), that doesn't support Unicode string literals yet.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116664&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 00:44:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Oct 2000 16:44:52 -0700
Subject: [Python-bugs-list] [Bug #115221] test_poll hangs on Debian Linux 2.2
Message-ID: <200010112344.QAA08711@delerium.i.sourceforge.net>

Bug #115221, was updated on 2000-Sep-24 07:38
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: test_poll hangs on Debian Linux 2.2

Details: When run from the command-line test_poll.py prints
"This is a test." 12 times and then hangs, without ever printing "Poll test 1 complete".

All other tests seem to work just fine.

Follow-Ups:

Date: 2000-Sep-27 10:58
By: nascheme

Comment:
I can't reproduce this on my Debian 2.2 system running Linux
 2.2.16.  Can you give the output from "uname -a" and "dpkg 
-l libc6"?  I am using libc6 2.1.3-13.
-------------------------------------------------------

Date: 2000-Oct-05 07:17
By: jhylton

Comment:
Andrew -- Is this still a problem for you?  
-------------------------------------------------------

Date: 2000-Oct-05 07:52
By: akuchling

Comment:
I don't have a Debian system to reproduce this on.

-------------------------------------------------------

Date: 2000-Oct-05 08:43
By: larsga

Comment:
I did a "cvs update", recompiled and ran the regtest again. Problem still persists.

Traceback is
Traceback (most recent call last):
  File "test_poll.py", line 171, in ?
    test_poll1()
  File "test_poll.py", line 65, in test_poll1
    poll_unit_tests()
  File "test_poll.py", line 77, in poll_unit_tests
    r = p.poll()
KeyboardInterrupt

[larsga@pc-larsga test]$ uname -a
Linux pc-larsga 2.0.36 #2 Sun Jan 17 19:38:45 EST 1999 i686 unknown
[larsga@pc-larsga test]$ dpkg -l libc6
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  libc6          2.1.3-10       GNU C Library: Shared libraries and Timezone

-------------------------------------------------------

Date: 2000-Oct-05 08:48
By: akuchling

Comment:
Interesting; Neil has libc6-2.1.3-13, while Lars has 2.1.3-10.  Presumably that last tag is a release level?

On the other hand, Neil is running a 2.2 Linux while Lars is running 2.0.36, and Neil also reported problems with
poll on a 2.0 machine.  So the finger of suspicion is pointing at the kernel...
-------------------------------------------------------

Date: 2000-Oct-07 08:43
By: twouters

Comment:
When running test_poll on the current CVS tree on RedHat 5.2 with a 2.0.36 kernel, I also get a test_poll error, though not the same one:

 This is a test.
 This is a test.
[...]
test test_poll crashed -- select.error: (9, 'Bad file descriptor')
Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 235, in runtest
    __import__(test, globals(), locals(), [])
  File "./Lib/test/test_poll.py", line 171, in ?
    test_poll1()
  File "./Lib/test/test_poll.py", line 65, in test_poll1
    poll_unit_tests()
  File "./Lib/test/test_poll.py", line 77, in poll_unit_tests
    r = p.poll()
error: (9, 'Bad file descriptor')
1 test failed: test_poll

RedHat 5.2 with a 2.2 kernel works fine. Let me know if you want me to submit a separate bugreport for the rh52-kernel2.0-poll error.

-------------------------------------------------------

Date: 2000-Oct-11 16:44
By: jhylton

Comment:
Would this patch fix the most recently reported problem?

Index: Lib/test/test_poll.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_poll.py,v
retrieving revision 1.3
diff -c -r1.3 test_poll.py
*** Lib/test/test_poll.py       2000/08/29 16:53:34     1.3
--- Lib/test/test_poll.py       2000/10/11 23:44:31
***************
*** 74,81 ****
          pass
      p = select.poll()
      p.register(FD)
!     r = p.poll()
!     assert r[0] == (FD, select.POLLNVAL)
  
      f = open(TESTFN, 'w')
      fd = f.fileno()
--- 74,87 ----
          pass
      p = select.poll()
      p.register(FD)
!     try:
!         r = p.poll()
!     except select.error, msg:
!         # old versions of Linux seem to raise an exception instead of
!         # returning POLLNVAL 
!         pass
!     else:
!         assert r[0] == (FD, select.POLLNVAL)
  
      f = open(TESTFN, 'w')
      fd = f.fileno()

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115221&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 03:24:22 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Oct 2000 19:24:22 -0700
Subject: [Python-bugs-list] [Bug #116677] minidom:Node.appendChild() has wrong semantics
Message-ID: <200010120224.TAA20741@bush.i.sourceforge.net>

Bug #116677, was updated on 2000-Oct-11 19:24
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: minidom:Node.appendChild() has wrong semantics

Details: Consider this test program:

from xml.dom import minidom
doc = minidom.Document()
root = doc.createElement('root') ; doc.appendChild( root )

elem = doc.createElement('leaf')
root.appendChild( elem )
root.appendChild( elem )

print doc.toxml()
print root.childNodes

It prints:
<root><leaf/><leaf/></root>
[<DOM Element: leaf at 135586476>, <DOM Element: leaf at 135586476>]

'elem' is now linked into the DOM tree in two places, which is wrong; according to the DOM Level 1 spec, 
"If the newChild is already in the tree, it is first removed."



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116677&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 03:26:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Oct 2000 19:26:13 -0700
Subject: [Python-bugs-list] [Bug #116677] minidom:Node.appendChild() has wrong semantics
Message-ID: <200010120226.TAA20779@bush.i.sourceforge.net>

Bug #116677, was updated on 2000-Oct-11 19:24
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: minidom:Node.appendChild() has wrong semantics

Details: Consider this test program:

from xml.dom import minidom
doc = minidom.Document()
root = doc.createElement('root') ; doc.appendChild( root )

elem = doc.createElement('leaf')
root.appendChild( elem )
root.appendChild( elem )

print doc.toxml()
print root.childNodes

It prints:
<root><leaf/><leaf/></root>
[<DOM Element: leaf at 135586476>, <DOM Element: leaf at 135586476>]

'elem' is now linked into the DOM tree in two places, which is wrong; according to the DOM Level 1 spec, 
"If the newChild is already in the tree, it is first removed."



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116677&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 03:30:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Oct 2000 19:30:14 -0700
Subject: [Python-bugs-list] [Bug #116678] minidom doesn't raise exception for illegal children
Message-ID: <200010120230.TAA20913@bush.i.sourceforge.net>

Bug #116678, was updated on 2000-Oct-11 19:30
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: minidom doesn't raise exception for illegal children

Details: Some types of DOM node such as Text can't have children.
minidom doesn't check for this at all:

from xml.dom import minidom
doc = minidom.Document()
text = doc.createTextNode('lorem ipsum')
elem = doc.createElement('leaf')
text.appendChild( elem )
print text.toxml()

This outputs just 'lorem ipsum', but elem really is a child 
of text; Text.toxml() just isn't recursing because it doesn't expect to do so.



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116678&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 03:55:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Oct 2000 19:55:00 -0700
Subject: [Python-bugs-list] [Bug #116677] minidom:Node.appendChild() has wrong semantics
Message-ID: <200010120255.TAA15145@delerium.i.sourceforge.net>

Bug #116677, was updated on 2000-Oct-11 19:24
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: minidom:Node.appendChild() has wrong semantics

Details: Consider this test program:

from xml.dom import minidom
doc = minidom.Document()
root = doc.createElement('root') ; doc.appendChild( root )

elem = doc.createElement('leaf')
root.appendChild( elem )
root.appendChild( elem )

print doc.toxml()
print root.childNodes

It prints:
<root><leaf/><leaf/></root>
[<DOM Element: leaf at 135586476>, <DOM Element: leaf at 135586476>]

'elem' is now linked into the DOM tree in two places, which is wrong; according to the DOM Level 1 spec, 
"If the newChild is already in the tree, it is first removed."



Follow-Ups:

Date: 2000-Oct-11 19:55
By: fdrake

Comment:
Andrew:  Are you using 2.0c1 or CVS?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116677&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 04:11:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Oct 2000 20:11:55 -0700
Subject: [Python-bugs-list] [Bug #116677] minidom:Node.appendChild() has wrong semantics
Message-ID: <200010120311.UAA15669@delerium.i.sourceforge.net>

Bug #116677, was updated on 2000-Oct-11 19:24
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: minidom:Node.appendChild() has wrong semantics

Details: Consider this test program:

from xml.dom import minidom
doc = minidom.Document()
root = doc.createElement('root') ; doc.appendChild( root )

elem = doc.createElement('leaf')
root.appendChild( elem )
root.appendChild( elem )

print doc.toxml()
print root.childNodes

It prints:
<root><leaf/><leaf/></root>
[<DOM Element: leaf at 135586476>, <DOM Element: leaf at 135586476>]

'elem' is now linked into the DOM tree in two places, which is wrong; according to the DOM Level 1 spec, 
"If the newChild is already in the tree, it is first removed."



Follow-Ups:

Date: 2000-Oct-11 19:55
By: fdrake

Comment:
Andrew:  Are you using 2.0c1 or CVS?
-------------------------------------------------------

Date: 2000-Oct-11 20:11
By: akuchling

Comment:
CVS as of this evening.  Did it work before?

(Hmm... tonight test_minidom is failing for me for some reason.  
Wonder if it's related?)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116677&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 06:05:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 11 Oct 2000 22:05:39 -0700
Subject: [Python-bugs-list] [Bug #116682] 2.0 stalls Mac on external drive
Message-ID: <200010120505.WAA26180@bush.i.sourceforge.net>

Bug #116682, was updated on 2000-Oct-11 22:05
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: 2.0 stalls Mac on external drive

Details: Both 2.0 and 1.52 cause problems when they are on an external drive. The machine boots fine on a cold boot, but on restart the alias in the extensions folder to Python core can't find the original file as the drive is not yet mounted and so the machine doesn't get past the Happy Mac. (This is on system 8.1). Perhaps it would work better if the original was in the system folder and the alias was in the Python folder?

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116682&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 15:37:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 07:37:03 -0700
Subject: [Python-bugs-list] [Bug #116677] minidom:Node.appendChild() has wrong semantics
Message-ID: <200010121437.HAA14584@bush.i.sourceforge.net>

Bug #116677, was updated on 2000-Oct-11 19:24
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: minidom:Node.appendChild() has wrong semantics

Details: Consider this test program:

from xml.dom import minidom
doc = minidom.Document()
root = doc.createElement('root') ; doc.appendChild( root )

elem = doc.createElement('leaf')
root.appendChild( elem )
root.appendChild( elem )

print doc.toxml()
print root.childNodes

It prints:
<root><leaf/><leaf/></root>
[<DOM Element: leaf at 135586476>, <DOM Element: leaf at 135586476>]

'elem' is now linked into the DOM tree in two places, which is wrong; according to the DOM Level 1 spec, 
"If the newChild is already in the tree, it is first removed."



Follow-Ups:

Date: 2000-Oct-11 19:55
By: fdrake

Comment:
Andrew:  Are you using 2.0c1 or CVS?
-------------------------------------------------------

Date: 2000-Oct-11 20:11
By: akuchling

Comment:
CVS as of this evening.  Did it work before?

(Hmm... tonight test_minidom is failing for me for some reason.  
Wonder if it's related?)
-------------------------------------------------------

Date: 2000-Oct-12 07:37
By: none

Comment:
The test_minidom failure turned out to be caused by something else.  However, I rechecked my test case and it's still broken with tonight's CVS.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116677&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 15:50:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 07:50:47 -0700
Subject: [Python-bugs-list] [Bug #116255] 2.0b2:  LDSHARED incorrect on SGI IRIX
Message-ID: <200010121450.HAA08925@delerium.i.sourceforge.net>

Bug #116255, was updated on 2000-Oct-06 10:06
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 2.0b2:  LDSHARED incorrect on SGI IRIX

Details: I think that's the problem.  But someone versed in Python Distutils will have to judge whether my fix is the right one.

NumPy 17.0 fails to build for me on 2.0b2 on IRIX 6.5.  This patch to the Python 2.0b2 installed tree fixes it and let's NumPy build correctly on IRIX.

config/Makefile:
-LDSHARED=       ld
+LDSHARED=       ld -shared $(LDFLAGS)

------------------------------------------------------------
Here is more detail on the error and the fix:

The NumPy build (for the latest version) fails on IRIX.

  cc -n32 -O ... 
  cc -n32 -O ... 
  ... 
  ld <list of .o's> -o build/lib.irix64-6.5-2.0/_numpy.so 

  ld: FATAL 12 : Expecting o32 objects:  
  build/temp.irix64-6.5-2.0/Src/_numpymodule.o is n32. 

There are two things failing the NumPy build. First, the ld invocation (in Distutils I assume) isn't specifying $LDFLAGS on the invocation line (which contains -n32), and second the ld invocation isn't specifying -shared.  The former is needed so the linker links a file with the same architecture as the source files it compiles; the latter is needed in order to build a shared object.

Thanks,

Randall



Follow-Ups:

Date: 2000-Oct-12 07:50
By: VizNut

Comment:
I just pulled and tested 2.0c1.  LDSHARED is not set correctly in this version either.  

This incorrect LDSHARED setting results in packages using Python's Makefile facility (PIL, DistUtils modules, etc.)  to fail when linking their shared object modules.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116255&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 16:43:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 08:43:59 -0700
Subject: [Python-bugs-list] [Bug #115221] test_poll hangs on Debian Linux 2.2
Message-ID: <200010121543.IAA17175@bush.i.sourceforge.net>

Bug #115221, was updated on 2000-Sep-24 07:38
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 4
Summary: test_poll hangs on Debian Linux 2.2

Details: When run from the command-line test_poll.py prints
"This is a test." 12 times and then hangs, without ever printing "Poll test 1 complete".

All other tests seem to work just fine.

Follow-Ups:

Date: 2000-Sep-27 10:58
By: nascheme

Comment:
I can't reproduce this on my Debian 2.2 system running Linux
 2.2.16.  Can you give the output from "uname -a" and "dpkg 
-l libc6"?  I am using libc6 2.1.3-13.
-------------------------------------------------------

Date: 2000-Oct-05 07:17
By: jhylton

Comment:
Andrew -- Is this still a problem for you?  
-------------------------------------------------------

Date: 2000-Oct-05 07:52
By: akuchling

Comment:
I don't have a Debian system to reproduce this on.

-------------------------------------------------------

Date: 2000-Oct-05 08:43
By: larsga

Comment:
I did a "cvs update", recompiled and ran the regtest again. Problem still persists.

Traceback is
Traceback (most recent call last):
  File "test_poll.py", line 171, in ?
    test_poll1()
  File "test_poll.py", line 65, in test_poll1
    poll_unit_tests()
  File "test_poll.py", line 77, in poll_unit_tests
    r = p.poll()
KeyboardInterrupt

[larsga@pc-larsga test]$ uname -a
Linux pc-larsga 2.0.36 #2 Sun Jan 17 19:38:45 EST 1999 i686 unknown
[larsga@pc-larsga test]$ dpkg -l libc6
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  libc6          2.1.3-10       GNU C Library: Shared libraries and Timezone

-------------------------------------------------------

Date: 2000-Oct-05 08:48
By: akuchling

Comment:
Interesting; Neil has libc6-2.1.3-13, while Lars has 2.1.3-10.  Presumably that last tag is a release level?

On the other hand, Neil is running a 2.2 Linux while Lars is running 2.0.36, and Neil also reported problems with
poll on a 2.0 machine.  So the finger of suspicion is pointing at the kernel...
-------------------------------------------------------

Date: 2000-Oct-07 08:43
By: twouters

Comment:
When running test_poll on the current CVS tree on RedHat 5.2 with a 2.0.36 kernel, I also get a test_poll error, though not the same one:

 This is a test.
 This is a test.
[...]
test test_poll crashed -- select.error: (9, 'Bad file descriptor')
Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 235, in runtest
    __import__(test, globals(), locals(), [])
  File "./Lib/test/test_poll.py", line 171, in ?
    test_poll1()
  File "./Lib/test/test_poll.py", line 65, in test_poll1
    poll_unit_tests()
  File "./Lib/test/test_poll.py", line 77, in poll_unit_tests
    r = p.poll()
error: (9, 'Bad file descriptor')
1 test failed: test_poll

RedHat 5.2 with a 2.2 kernel works fine. Let me know if you want me to submit a separate bugreport for the rh52-kernel2.0-poll error.

-------------------------------------------------------

Date: 2000-Oct-11 16:44
By: jhylton

Comment:
Would this patch fix the most recently reported problem?

Index: Lib/test/test_poll.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_poll.py,v
retrieving revision 1.3
diff -c -r1.3 test_poll.py
*** Lib/test/test_poll.py       2000/08/29 16:53:34     1.3
--- Lib/test/test_poll.py       2000/10/11 23:44:31
***************
*** 74,81 ****
          pass
      p = select.poll()
      p.register(FD)
!     r = p.poll()
!     assert r[0] == (FD, select.POLLNVAL)
  
      f = open(TESTFN, 'w')
      fd = f.fileno()
--- 74,87 ----
          pass
      p = select.poll()
      p.register(FD)
!     try:
!         r = p.poll()
!     except select.error, msg:
!         # old versions of Linux seem to raise an exception instead of
!         # returning POLLNVAL 
!         pass
!     else:
!         assert r[0] == (FD, select.POLLNVAL)
  
      f = open(TESTFN, 'w')
      fd = f.fileno()

-------------------------------------------------------

Date: 2000-Oct-12 08:43
By: jhylton

Comment:
Does anyone care about this bug report anymore?  Since there has been no response, I'm lowering the priority...
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115221&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 16:44:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 08:44:50 -0700
Subject: [Python-bugs-list] [Bug #116682] 2.0 stalls Mac on external drive
Message-ID: <200010121544.IAA17272@bush.i.sourceforge.net>

Bug #116682, was updated on 2000-Oct-11 22:05
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: 2.0 stalls Mac on external drive

Details: Both 2.0 and 1.52 cause problems when they are on an external drive. The machine boots fine on a cold boot, but on restart the alias in the extensions folder to Python core can't find the original file as the drive is not yet mounted and so the machine doesn't get past the Happy Mac. (This is on system 8.1). Perhaps it would work better if the original was in the system folder and the alias was in the Python folder?

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116682&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 16:58:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 08:58:18 -0700
Subject: [Python-bugs-list] [Bug #116716] urllib.quote and Unicode
Message-ID: <200010121558.IAA17755@bush.i.sourceforge.net>

Bug #116716, was updated on 2000-Oct-12 08:58
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: urllib.quote and Unicode

Details: Currently urllib.quote does not handle
Unicode strings. urllib should be able to handle those.
According to http://www.w3.org/TR/html4/appendix/notes.html#h-B.2.1
what is required is:

1. Represent each character in UTF-8 (see [RFC2279]) as 
   one or more bytes. 
2. Escape these bytes with the URI escaping mechanism
   (i.e., by converting each byte to %HH, where HH is the
   hexadecimal notation of the byte value). 

urllib.quote already does 2. For Unicode strings it should
do 1. too.

This chances the meaning of urllib.quote slightly, now an
8bit string would be interpreted as being utf8 encoded. To
fix this an 8bit string should be transcoded from the default encoding to utf8 first, i.e. what should be
inserted at the beginning of quote is:
if type(s) == types.StringType:
   s = unicode(s,sys.getdefaultencoding())
s = s.encode("utf8")


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116716&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 17:13:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 09:13:13 -0700
Subject: [Python-bugs-list] [Bug #116716] urllib.quote and Unicode
Message-ID: <200010121613.JAA18349@bush.i.sourceforge.net>

Bug #116716, was updated on 2000-Oct-12 08:58
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: urllib.quote and Unicode

Details: Currently urllib.quote does not handle
Unicode strings. urllib should be able to handle those.
According to http://www.w3.org/TR/html4/appendix/notes.html#h-B.2.1
what is required is:

1. Represent each character in UTF-8 (see [RFC2279]) as 
   one or more bytes. 
2. Escape these bytes with the URI escaping mechanism
   (i.e., by converting each byte to %HH, where HH is the
   hexadecimal notation of the byte value). 

urllib.quote already does 2. For Unicode strings it should
do 1. too.

This chances the meaning of urllib.quote slightly, now an
8bit string would be interpreted as being utf8 encoded. To
fix this an 8bit string should be transcoded from the default encoding to utf8 first, i.e. what should be
inserted at the beginning of quote is:
if type(s) == types.StringType:
   s = unicode(s,sys.getdefaultencoding())
s = s.encode("utf8")


Follow-Ups:

Date: 2000-Oct-12 09:13
By: gvanrossum

Comment:
Sure. Added to PEP-42.

I have a feeling that there are probably a lot of places in the standard library where decisions like this may have to be made...!

(Exercise for the reader: code this so that it works with JPython too...)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116716&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 17:14:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 09:14:21 -0700
Subject: [Python-bugs-list] [Bug #116716] urllib.quote and Unicode
Message-ID: <200010121614.JAA18454@bush.i.sourceforge.net>

Bug #116716, was updated on 2000-Oct-12 08:58
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: urllib.quote and Unicode

Details: Currently urllib.quote does not handle
Unicode strings. urllib should be able to handle those.
According to http://www.w3.org/TR/html4/appendix/notes.html#h-B.2.1
what is required is:

1. Represent each character in UTF-8 (see [RFC2279]) as 
   one or more bytes. 
2. Escape these bytes with the URI escaping mechanism
   (i.e., by converting each byte to %HH, where HH is the
   hexadecimal notation of the byte value). 

urllib.quote already does 2. For Unicode strings it should
do 1. too.

This chances the meaning of urllib.quote slightly, now an
8bit string would be interpreted as being utf8 encoded. To
fix this an 8bit string should be transcoded from the default encoding to utf8 first, i.e. what should be
inserted at the beginning of quote is:
if type(s) == types.StringType:
   s = unicode(s,sys.getdefaultencoding())
s = s.encode("utf8")


Follow-Ups:

Date: 2000-Oct-12 09:13
By: gvanrossum

Comment:
Sure. Added to PEP-42.

I have a feeling that there are probably a lot of places in the standard library where decisions like this may have to be made...!

(Exercise for the reader: code this so that it works with JPython too...)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116716&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 17:17:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 09:17:20 -0700
Subject: [Python-bugs-list] [Bug #116405] Bug in buffer interface
Message-ID: <200010121617.JAA18545@bush.i.sourceforge.net>

Bug #116405, was updated on 2000-Oct-09 02:25
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 5
Summary: Bug in buffer interface

Details: Consider the following code:

PyObject *base = PyBuffer_New(100);
PyObject *buffer = PyBuffer_FromObject(base);
Py_DECREF(base);

After this code is executed,
buffer points to deallocated memory (because
buffer does not hold a reference to base anymore).


Follow-Ups:

Date: 2000-Oct-09 05:48
By: gvanrossum

Comment:
Do you know the old joke that begins with "Doctor, it hurts if I do this..." ?

That code is broken.
-------------------------------------------------------

Date: 2000-Oct-09 05:57
By: theller

Comment:
I know this joke, but it really won't help me.
Are we NOT going to fix this?
How can I use the buffer interface?
-------------------------------------------------------

Date: 2000-Oct-09 06:23
By: gvanrossum

Comment:
Make sure the base stays alive as long as the buffer. The buffer is for advanced uses -- I have a feeling you don't know what it is for and are trying to use it to solve something it isn't intended to solve.

In any case this is not a topic for a bug report.
-------------------------------------------------------

Date: 2000-Oct-09 07:13
By: gvanrossum

Comment:
Reopened.

In private mail, Thomas explained things better. The missing arguments to PyBuffer_FromObject() were a typo in the bug report. The real problem is that the base is already a buffer object!  Thomas writes:

The problem is the following piece of code in bufferobject.c:,
function _PyBuffer_FromObject:

 /* if the base object is another buffer, then "deref" it */
 if ( PyBuffer_Check(base) )
  base = ((PyBufferObject *)base)->b_base;

 return _PyBuffer_FromMemory(base, (char *)p + offset, size, readonly);
}

which should be changed to (IMO)

 /* if the base object is another buffer, then "deref" it */
 if ( PyBuffer_Check(base) && ((PyBufferObject *)base->b_base)
  base = ((PyBufferObject *)base)->b_base;

 return _PyBuffer_FromMemory(base, (char *)p + offset, size, readonly);
}

If base is an object which had been created by PyBuffer_New(),
then its b_base is NULL, and in this case the newly created object
MUST keep the reference to base itself, and not base->b_base.

-------------------------------------------------------

Date: 2000-Oct-12 09:17
By: gvanrossum

Comment:
Added to PEP-42.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116405&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 17:21:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 09:21:45 -0700
Subject: [Python-bugs-list] [Bug #115221] test_poll hangs on Debian Linux 2.2
Message-ID: <200010121621.JAA18740@bush.i.sourceforge.net>

Bug #115221, was updated on 2000-Sep-24 07:38
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 4
Summary: test_poll hangs on Debian Linux 2.2

Details: When run from the command-line test_poll.py prints
"This is a test." 12 times and then hangs, without ever printing "Poll test 1 complete".

All other tests seem to work just fine.

Follow-Ups:

Date: 2000-Sep-27 10:58
By: nascheme

Comment:
I can't reproduce this on my Debian 2.2 system running Linux
 2.2.16.  Can you give the output from "uname -a" and "dpkg 
-l libc6"?  I am using libc6 2.1.3-13.
-------------------------------------------------------

Date: 2000-Oct-05 07:17
By: jhylton

Comment:
Andrew -- Is this still a problem for you?  
-------------------------------------------------------

Date: 2000-Oct-05 07:52
By: akuchling

Comment:
I don't have a Debian system to reproduce this on.

-------------------------------------------------------

Date: 2000-Oct-05 08:43
By: larsga

Comment:
I did a "cvs update", recompiled and ran the regtest again. Problem still persists.

Traceback is
Traceback (most recent call last):
  File "test_poll.py", line 171, in ?
    test_poll1()
  File "test_poll.py", line 65, in test_poll1
    poll_unit_tests()
  File "test_poll.py", line 77, in poll_unit_tests
    r = p.poll()
KeyboardInterrupt

[larsga@pc-larsga test]$ uname -a
Linux pc-larsga 2.0.36 #2 Sun Jan 17 19:38:45 EST 1999 i686 unknown
[larsga@pc-larsga test]$ dpkg -l libc6
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  libc6          2.1.3-10       GNU C Library: Shared libraries and Timezone

-------------------------------------------------------

Date: 2000-Oct-05 08:48
By: akuchling

Comment:
Interesting; Neil has libc6-2.1.3-13, while Lars has 2.1.3-10.  Presumably that last tag is a release level?

On the other hand, Neil is running a 2.2 Linux while Lars is running 2.0.36, and Neil also reported problems with
poll on a 2.0 machine.  So the finger of suspicion is pointing at the kernel...
-------------------------------------------------------

Date: 2000-Oct-07 08:43
By: twouters

Comment:
When running test_poll on the current CVS tree on RedHat 5.2 with a 2.0.36 kernel, I also get a test_poll error, though not the same one:

 This is a test.
 This is a test.
[...]
test test_poll crashed -- select.error: (9, 'Bad file descriptor')
Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 235, in runtest
    __import__(test, globals(), locals(), [])
  File "./Lib/test/test_poll.py", line 171, in ?
    test_poll1()
  File "./Lib/test/test_poll.py", line 65, in test_poll1
    poll_unit_tests()
  File "./Lib/test/test_poll.py", line 77, in poll_unit_tests
    r = p.poll()
error: (9, 'Bad file descriptor')
1 test failed: test_poll

RedHat 5.2 with a 2.2 kernel works fine. Let me know if you want me to submit a separate bugreport for the rh52-kernel2.0-poll error.

-------------------------------------------------------

Date: 2000-Oct-11 16:44
By: jhylton

Comment:
Would this patch fix the most recently reported problem?

Index: Lib/test/test_poll.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_poll.py,v
retrieving revision 1.3
diff -c -r1.3 test_poll.py
*** Lib/test/test_poll.py       2000/08/29 16:53:34     1.3
--- Lib/test/test_poll.py       2000/10/11 23:44:31
***************
*** 74,81 ****
          pass
      p = select.poll()
      p.register(FD)
!     r = p.poll()
!     assert r[0] == (FD, select.POLLNVAL)
  
      f = open(TESTFN, 'w')
      fd = f.fileno()
--- 74,87 ----
          pass
      p = select.poll()
      p.register(FD)
!     try:
!         r = p.poll()
!     except select.error, msg:
!         # old versions of Linux seem to raise an exception instead of
!         # returning POLLNVAL 
!         pass
!     else:
!         assert r[0] == (FD, select.POLLNVAL)
  
      f = open(TESTFN, 'w')
      fd = f.fileno()

-------------------------------------------------------

Date: 2000-Oct-12 08:43
By: jhylton

Comment:
Does anyone care about this bug report anymore?  Since there has been no response, I'm lowering the priority...
-------------------------------------------------------

Date: 2000-Oct-12 09:21
By: akuchling

Comment:
If the suggested patch actually fixes the test suite, I'd approve adding it.  Have any of the original respondents tried the patch?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115221&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 17:24:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 09:24:57 -0700
Subject: [Python-bugs-list] [Bug #116720] function to open a file and create intermediate directories
Message-ID: <200010121624.JAA12896@delerium.i.sourceforge.net>

Bug #116720, was updated on 2000-Oct-12 09:24
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: function to open a file and create intermediate directories

Details: A function would be useful (maybe available in the
os module), that opens a file for writing and creates
all necessary intermediate directories. Here is the
Python function that does exactly that:

def forceopen(name, filemode, dirmode=0777):
    try:
        return open(name, filemode)
    except IOError, e:
       if e[0] != 2: # didn't work for some other reason
           raise
       lastsep = name.rfind(os.sep)
       if lastsep == -1:
           raise
       os.makedirs(name[:lastsep], dirmode)
       return open(name, filemode)


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116720&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 17:26:19 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 09:26:19 -0700
Subject: [Python-bugs-list] [Bug #116255] 2.0b2:  LDSHARED incorrect on SGI IRIX
Message-ID: <200010121626.JAA12929@delerium.i.sourceforge.net>

Bug #116255, was updated on 2000-Oct-06 10:06
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 2.0b2:  LDSHARED incorrect on SGI IRIX

Details: I think that's the problem.  But someone versed in Python Distutils will have to judge whether my fix is the right one.

NumPy 17.0 fails to build for me on 2.0b2 on IRIX 6.5.  This patch to the Python 2.0b2 installed tree fixes it and let's NumPy build correctly on IRIX.

config/Makefile:
-LDSHARED=       ld
+LDSHARED=       ld -shared $(LDFLAGS)

------------------------------------------------------------
Here is more detail on the error and the fix:

The NumPy build (for the latest version) fails on IRIX.

  cc -n32 -O ... 
  cc -n32 -O ... 
  ... 
  ld <list of .o's> -o build/lib.irix64-6.5-2.0/_numpy.so 

  ld: FATAL 12 : Expecting o32 objects:  
  build/temp.irix64-6.5-2.0/Src/_numpymodule.o is n32. 

There are two things failing the NumPy build. First, the ld invocation (in Distutils I assume) isn't specifying $LDFLAGS on the invocation line (which contains -n32), and second the ld invocation isn't specifying -shared.  The former is needed so the linker links a file with the same architecture as the source files it compiles; the latter is needed in order to build a shared object.

Thanks,

Randall



Follow-Ups:

Date: 2000-Oct-12 07:50
By: VizNut

Comment:
I just pulled and tested 2.0c1.  LDSHARED is not set correctly in this version either.  

This incorrect LDSHARED setting results in packages using Python's Makefile facility (PIL, DistUtils modules, etc.)  to fail when linking their shared object modules.

-------------------------------------------------------

Date: 2000-Oct-12 09:26
By: gvanrossum

Comment:
Dear VizNut (what's your real name?), I'm not unwilling to fix this, but I can't apply your patch -- that file is generated.

The curious thing is that the configure script does test for IRIX and sets LDSHARED correctly when IRIX/5* or IRIX*/6* is detected.

I wonder what went wrong???

The only thing I can think of is that somehow uname returns something else than IRIX? What is the output of uname -s? Of uname -a?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116255&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 17:28:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 09:28:10 -0700
Subject: [Python-bugs-list] [Bug #113797] Build problems on Reliant Unix
Message-ID: <200010121628.JAA12961@delerium.i.sourceforge.net>

Bug #113797, was updated on 2000-Sep-07 07:33
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: Later
Bug Group: Platform-specific
Priority: 1
Summary: Build problems on Reliant Unix

Details: - the linker requires the options '-W1 -Blargedynsym', otherwise, Python's global functions and variables are not visible to external modules

- when building --with-threads, the linker requires the option -Kpthread

- mmapmodule.o requires a special library

Python version: 2.0b1

compiler version:CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000
CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000


Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 13:45
By: fdrake

Comment:
We need to know the output of "uname -s" and "uname -r" for this system.  (If "uname -r" reports an error, please try "uname -v".)

Are you willing to test a modified configure script on this platform?

What additional library is required for the mmap module?
-------------------------------------------------------

Date: 2000-Sep-12 21:59
By: fdrake

Comment:
Received the following response from Daniel Dittmar <ddittmar@users.sourceforge.net>:

> We need to know the output of "uname -s" and "uname -r" 
> for this system.  (If "uname -r" reports an error, please 
> try "uname -v".)

uname -s
ReliantUNIX-N

uname -r
5.45


> Are you willing to test a modified configure script on
> this platform?

sure.

> What additional library is required for the mmap module?

The man page states -lucb. This didn't work on my machine 
as the BSD compatibility layer is not active. I tell you 
more as soon as I know how to activate it.

***********

Another problem: to detect pthreads, the compiler must be 
called with -Kpthread. Otherwise, pthread.h goes into a 
branch where it tries to include a non existent header, 
fails, and configure reports 'no pthreads'.

Daniel

-------------------------------------------------------

Date: 2000-Sep-15 11:57
By: fdrake

Comment:
For the mmap issue, I've added a comment to Modules/Setup.in to let installers know that -lucb may be needed.  In revision 1.110.
-------------------------------------------------------

Date: 2000-Sep-15 13:37
By: fdrake

Comment:
I'm sending a modified version of  the configure script to Daniel Dittmar to test for the first two points in this bug report.
-------------------------------------------------------

Date: 2000-Sep-21 08:17
By: fdrake

Comment:
Sent query to Daniel Dittmar asking if he's had a chance to test the revised configure script I sent.
-------------------------------------------------------

Date: 2000-Sep-21 08:46
By: fdrake

Comment:
Received message from Daniel indicating he should get a chace to test the changes this weekend, so it should be available for 2.0b2.
-------------------------------------------------------

Date: 2000-Sep-24 05:46
By: ddittmar

Comment:
- configure --without-threads works with the configure patch Revision 1.158

- mmapmodule would work if it includes the lines

#include <unistd.h>

static int
getpagesize (void)
{
    return sysconf (_SC_PAGESIZE);
}

This would be the preferred way as using the BSD compatibility with -lucb is discouraged.

It requires chages to configure (has_pagesize, has_sysconf_sc_pagesize)

- configure --with-threads doesn't build yet, keeping contact with fdrake
-------------------------------------------------------

Date: 2000-Sep-25 08:10
By: fdrake

Comment:
Fix to make sure the public API properly exposed to extensions checked in as configure.in revision 1.155.  The rest of these issues can be dealt with in 2.0 final.
-------------------------------------------------------

Date: 2000-Sep-28 10:36
By: fdrake

Comment:
I've sent a patch for the mmap module to Daniel to test on Reliant UNIX; the patch should remove the need to link to libucb on that platform (the only platform that needed that as far as we know).
-------------------------------------------------------

Date: 2000-Oct-01 09:34
By: ddittmar

Comment:
The patch for the mmap module works on 2.0b2
-------------------------------------------------------

Date: 2000-Oct-01 10:51
By: fdrake

Comment:
mmap patch checked in as Modules/mmapmodule.c revision 2.24.
-------------------------------------------------------

Date: 2000-Oct-02 08:30
By: fdrake

Comment:
Sent another version of the configure script to Daniel Dittmar for testing the thread support.  I think this is the last remaining problem listed in this bug report.
-------------------------------------------------------

Date: 2000-Oct-03 09:16
By: fdrake

Comment:
Daniel Dittmar's response:
- the configure script works, except that the correct option is '-Kpthread'
(you mistyped '-Lpthread'

- there's a compilation error in thread_pthread.h:181: the expression
'(long) threadid' is not valid. The definition of pthread_t is 

typedef struct PTHREAD_HANDLE_T {
    void               *field1;
    short int           field2;
    short int           field3;
    } pthread_handle_t;

typedef pthread_handle_t pthread_t;

so I doubt that the alternative 

return (long) *(long *) &threadid

is valid. I could compile it with this version, but I doubt it's returning a
meaningful thread id. Is there a test for the thread module?

I'm away for the rest of the week, so I couldn't test anything for the
Wednesday date.

- for your information, I'm including the results of 'make test', at least
the failed ones:
test test_fork1 crashed -- exceptions.OSError: [Errno 4] Interrupted system
call
test test_popen2 crashed -- exceptions.IOError: [Errno 4] Interrupted system
call
test_signal
Trace/Breakpoint Trap - core dumped
make: *** Error code 133 (ignored)
make: *** Error code 133 (bu21) (ignored)

These test leave a few python processes around.

I'll probably look into this when I return.

Daniel

-------------------------------------------------------

Date: 2000-Oct-03 09:22
By: fdrake

Comment:
I've sent a note to Daniel asking for the config.h and config.log files generated by configure.  There's a real problem with the way we're creating thread identifiers; casting to a long just isn't sufficient.

It might be good to know what kind of processor is on the machine.
-------------------------------------------------------

Date: 2000-Oct-05 19:00
By: fdrake

Comment:
This won't be resolved for Python 2.0.  There's enough that would be effected by revising the thread identification code that we don't want to destabilize the sources at this point.

We should be able to resolve this for Python 2.1.  I've added a comment about this to the platform notes section of the README file (revision 1.102) to alert the reader to this situation.
-------------------------------------------------------

Date: 2000-Oct-12 09:28
By: fdrake

Comment:
I'm recording here part of the needed patch for threads; this is needed in configure.in to get the -Kpthread option passed to the compiler and linker in all the appropriate places.  There are still problems in the code.

(It won't look right in a browser, but it provides all the needed information.)

***************
*** 752,757 ****
--- 752,761 ----
      if test ! -z "$withval" -a -d "$withval"
      then LDFLAGS="$LDFLAGS -L$withval"
      fi
+     case "$ac_sys_system" in
+         ReliantUNIX*) LDFLAGS="$LDFLAGS -Kpthread";
+                       OPT="$OPT -Kpthread";;
+     esac
      AC_DEFINE(_REENTRANT)
      AC_CHECK_HEADER(mach/cthreads.h, [AC_DEFINE(WITH_THREAD)
      AC_DEFINE(C_THREADS)

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113797&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 17:35:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 09:35:40 -0700
Subject: [Python-bugs-list] [Bug #110924] support Unicode for Python source code
Message-ID: <200010121635.JAA13277@delerium.i.sourceforge.net>

Bug #110924, was updated on 2000-Aug-02 08:17
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Closed
Resolution: Fixed
Bug Group: Feature Request
Priority: 1
Summary: support Unicode for Python source code

Details: exec u"print 42"
doesn't work.

Follow-Ups:

Date: 2000-Aug-09 02:35
By: effbot

Comment:
python doesn't support 16-bit source code -- so what exactly do you want exec to do?
-------------------------------------------------------

Date: 2000-Aug-17 05:17
By: none

Comment:
That's exactly my point. Python should support Unicode
everywhere, in __str__ and __repr__, exec and eval, in open(), as a format for the source code (which would result in all variable names to be Unicode)...

Currenly working with Unicode (e.g. for XML) is a mess, because it's supported nowhere.

exec "a='ü'" seems to work and seems to treat the string as iso-8859-1 (or not at all)

-------------------------------------------------------

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 05:21
By: lemburg

Comment:
I don't think that the situation is that bad. You can't program
Python in Unicode, but this doesn't stop you from using it
in your Python programs.

Note that __str__ and __repr__ do support Unicode (it gets converted
to an 8-bit string using the default encoding).

There's currently not much need to have exec or eval() automatically
apply any conversion... you can always use str() around the argument
to make it support both 8-bit strings and Unicode.

-------------------------------------------------------

Date: 2000-Sep-16 15:18
By: bwarsaw

Comment:
Reassigning to Guido for final disposal, but I believe this should be marked either as "not a bug" or added to PEP 42.
-------------------------------------------------------

Date: 2000-Sep-16 19:51
By: gvanrossum

Comment:
There's an Accepted patch for this by Marc-Andre Lemburg.
Assigned to Marc-Andre so he can close the bug when he applies the patch.

(Marc-Andre: if you don't have time to apply the patch, let me know and I'll take care of it.)
-------------------------------------------------------

Date: 2000-Sep-19 14:07
By: lemburg

Comment:
exec and eval() now also accept Unicode as code parameter.

This is implemented by having the two APIs convert Unicode
to a string using the default encoding prior to processing the
code string.

-------------------------------------------------------

Date: 2000-Oct-04 09:01
By: none

Comment:
This doesn't solve the problem,
it only hides it.

When I set the defaultencoding to
"utf16" in site.py, I get the following error:

>>> exec u"a = 42"
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: expected string without null bytes

-------------------------------------------------------

Date: 2000-Oct-04 16:54
By: lemburg

Comment:
Setting the default encoding to anything which doesn't extend
ASCII is not a good idea. If you want to make Python more
Unicode aware you should test drive setting the default
encoding to UTF-8.

The patches to eval() and exec only provide coercion of Unicode
objects to normal 8-bit strings which the Python parser can handle.

There currently is no Unicode support in the Python compiler.
Patches are welcome ;-) ... and then the "bug" should be opened
again.

Perhaps this should go into the PEP-042 file ?!


-------------------------------------------------------

Date: 2000-Oct-12 09:35
By: doerwalter

Comment:
I think this should go into PEP-042. At least the bug decription "support Unicode for Python source code" and the
resolution "Fixed" don't fit together. ;) But on the other hand I realize that this is not a "Small Feature Request".
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110924&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 17:47:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 09:47:32 -0700
Subject: [Python-bugs-list] [Bug #116636] Bug in StringIO.write()
Message-ID: <200010121647.JAA19742@bush.i.sourceforge.net>

Bug #116636, was updated on 2000-Oct-11 10:53
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: None
Bug Group: None
Priority: 5
Summary: Bug in StringIO.write()

Details: If the file position is less than the end of the "file", and a write is performed extending past then end of the file, the data string is corrupted. 100% reliable failure on all platforms!

This is apparently an old bug (since 1.5.2 at least), but still exists in 2.0c1.

To reproduce:

	s = StringIO("abcdef")
	s.seek(3)
	s.write("uvwxyz")	# write data that starts before the end
				# of the buffer and extends beyond the end
				# (self.len is not properly updated in this case)
	s.write("m")		# this incorrectly pads the buffer with '\0'
	print `s.getvalue()`

The result is:

	'abcuvwxyz\000\000\000m'

I fixed my copy by adding the following lines to the StingIO.write method:

	def write(self, s):
		if self.closed:
			raise ValueError, "I/O operation on closed file"
		if not s: return
		if self.pos > self.len:
			self.buflist.append('\0'*(self.pos - self.len))
			self.len = self.pos
		newpos = self.pos + len(s)
		if self.pos < self.len:
			if self.buflist:
				self.buf = self.buf + string.joinfields(self.buflist, '')
				self.buflist = []
			self.buflist = [self.buf[:self.pos], s, self.buf[newpos:]]
			self.buf = ''
			if self.len < newpos:		# ADDED LINE
				self.len = newpos	# ADDED LINE
		else:
			self.buflist.append(s)
			self.len = newpos
		self.pos = newpos

Bob
bobalex@rsv.ricoh.com


Follow-Ups:

Date: 2000-Oct-12 09:47
By: gvanrossum

Comment:
Thanks! Fixed in the CVS tree and will be fixed in 2.0 final coming Monday.

Bob, what's your full name, for the ACKS file?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116636&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 17:48:49 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 09:48:49 -0700
Subject: [Python-bugs-list] [Bug #116144] Python 2.0b1  hangs
Message-ID: <200010121648.JAA19765@bush.i.sourceforge.net>

Bug #116144, was updated on 2000-Oct-05 08:35
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: Python 2.0b1  hangs

Details: Hi

My python program hangs after a while,  cannot even kill through ^C.  just hangs!

I am running python on the DEC Alpha system.   The program goes through 
a large flat file biological database. Reads entry by entry and prints 
some information after parsing each entry.  (an entry consists of number of lines).
I can give you more detail, if this was an unknown problem.


Ramu


Follow-Ups:

Date: 2000-Oct-05 11:07
By: gvanrossum

Comment:
We definitely need more information! One problem is that we don't have a DEC Alpha system to test on, so we can't easily try if out even if you gave us the source of your script and the input data!

Of course it's also possible that it's a bug in your program, or a change in Python that has nothing to do with DEC Alpha. But we can't tell from what you're saying! Can you reproduce the problem with a small test script? Also, please try if this is still broken with Python 2.0b2.
-------------------------------------------------------

Date: 2000-Oct-06 09:06
By: chennaramu

Comment:
Hi

Thanks for the response.  Actually I tested with  version 1.5.2  1.6  and 2.0b on Dec
machines . Same problem.

I am trying with linux, so far it is running (it will take another 5-7 hours to finish).
If  this succeeds with linux,  I will again try with DEC machine and let you know.

The data file is too large, I can give you ftp address to copy . 

Ramu

-------------------------------------------------------

Date: 2000-Oct-06 10:20
By: gvanrossum

Comment:
So at least show us your code! If you dont' want to make it public, mail it to guido@beopen.com.
-------------------------------------------------------

Date: 2000-Oct-06 11:04
By: tim_one

Comment:
The combination of "parsing" and "can't kill via ^C" suggests it's hung in the bowels of a regexp search (if so, should be reducible to a 1-liner!).
-------------------------------------------------------

Date: 2000-Oct-12 09:48
By: gvanrossum

Comment:
Got report from Ramu that his program now works. It's not clear what fixed it, but since this is so frustrating to debug, I'll close the bug report!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116144&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 18:04:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 10:04:56 -0700
Subject: [Python-bugs-list] [Bug #116716] urllib.quote and Unicode
Message-ID: <200010121704.KAA20503@bush.i.sourceforge.net>

Bug #116716, was updated on 2000-Oct-12 08:58
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: urllib.quote and Unicode

Details: Currently urllib.quote does not handle
Unicode strings. urllib should be able to handle those.
According to http://www.w3.org/TR/html4/appendix/notes.html#h-B.2.1
what is required is:

1. Represent each character in UTF-8 (see [RFC2279]) as 
   one or more bytes. 
2. Escape these bytes with the URI escaping mechanism
   (i.e., by converting each byte to %HH, where HH is the
   hexadecimal notation of the byte value). 

urllib.quote already does 2. For Unicode strings it should
do 1. too.

This chances the meaning of urllib.quote slightly, now an
8bit string would be interpreted as being utf8 encoded. To
fix this an 8bit string should be transcoded from the default encoding to utf8 first, i.e. what should be
inserted at the beginning of quote is:
if type(s) == types.StringType:
   s = unicode(s,sys.getdefaultencoding())
s = s.encode("utf8")


Follow-Ups:

Date: 2000-Oct-12 09:13
By: gvanrossum

Comment:
Sure. Added to PEP-42.

I have a feeling that there are probably a lot of places in the standard library where decisions like this may have to be made...!

(Exercise for the reader: code this so that it works with JPython too...)
-------------------------------------------------------

Date: 2000-Oct-12 10:04
By: lemburg

Comment:
FYI:
To recode an 8-bit string using the default encoding into 
a string using a different encoding, you only have to call the
.encode() method on the string object, e.g.

>>> "abc".encode('utf-16')
'\377\376a\000b\000c\000'
>>> "abc".encode('utf-8')
'abc'

But with ASCII as default encoding there's nothing much recode
into UTF-8 anyway ;-)  Still, the method makes writing polymorphic
code which produces 8-bit strings as output a tad easier.

Perhaps JPython's strings should have a .encode() method too...


-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116716&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 18:06:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 10:06:30 -0700
Subject: [Python-bugs-list] [Bug #116720] function to open a file and create intermediate directories
Message-ID: <200010121706.KAA20540@bush.i.sourceforge.net>

Bug #116720, was updated on 2000-Oct-12 09:24
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Wont Fix
Bug Group: Feature Request
Priority: 5
Summary: function to open a file and create intermediate directories

Details: A function would be useful (maybe available in the
os module), that opens a file for writing and creates
all necessary intermediate directories. Here is the
Python function that does exactly that:

def forceopen(name, filemode, dirmode=0777):
    try:
        return open(name, filemode)
    except IOError, e:
       if e[0] != 2: # didn't work for some other reason
           raise
       lastsep = name.rfind(os.sep)
       if lastsep == -1:
           raise
       os.makedirs(name[:lastsep], dirmode)
       return open(name, filemode)


Follow-Ups:

Date: 2000-Oct-12 10:06
By: fdrake

Comment:
This seems too esoteric a function to include in the standard libraries.  Without some serious justification, I don't see why this should be added since it's simple enough to add to an application's utility libraries.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116720&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 18:15:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 10:15:01 -0700
Subject: [Python-bugs-list] [Bug #116453] [Windows] TclError does not always produce error messages
Message-ID: <200010121715.KAA14854@delerium.i.sourceforge.net>

Bug #116453, was updated on 2000-Oct-09 17:00
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: [Windows] TclError does not always produce error messages

Details: In 1.5.2, doing l=Tkinter.Label(text1="bla") gives a traceback that ends with
TclError: unknown option "-text1"
In 2.0c1 (and any other recent version), with Tcl 8.3, it gives
TclError
It would be good if the error message would be provided as well.

According to tcl.h, direct access to interp->result is discouraged since 8.0; applications should use Tcl_GetObjResult (probably, GetStringResult is as good). I have not verified whether that solves the problem.

Follow-Ups:

Date: 2000-Oct-09 17:39
By: gvanrossum

Comment:
I cannot reproduce this with 2.0rc1 on Red Hat Linux 6.2, but I get the same phenomenon on Windows.

I 'll experiment with the suggestion after 2.0rc1 is released.
-------------------------------------------------------

Date: 2000-Oct-12 10:15
By: gvanrossum

Comment:
I don't know where you got this suggestion, but it was a good one!

Replacing all occurrences of interp->result  with Tcl_GetStringResult() fixed it.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116453&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 18:18:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 10:18:01 -0700
Subject: [Python-bugs-list] [Bug #113795] IDLE 0.6 with Python 2.0b1 doesn't handle chinese characters
Message-ID: <200010121718.KAA14917@delerium.i.sourceforge.net>

Bug #113795, was updated on 2000-Sep-07 06:49
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Closed
Resolution: Later
Bug Group: 3rd Party
Priority: 1
Summary: IDLE 0.6 with Python 2.0b1 doesn't handle chinese characters

Details: I just switched from 1.5.2 to 2.0b1 on W2K/Simplified Chinese version. I used to be able to input chinese characters directly into IDLE, and access violations did happen quite often. Now with 2.0b1, I can't even input chinese characters into the IDLE window anymore:IDLE automatically changed chinese characters into illegible stuff; it's the same when I copy from a text editor and paste into the IDLE window. I guess it's related to the induction of unicode support in 2.0, but is there a workaround I should know, or I should switch back to 1.5.2, or it's a bug worth fixing?

Thanks.


Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 23:13
By: tim_one

Comment:
Assigned to Fredrik, because Swedes have an uncanny intuition about how IDLE and Tk work in the presence of characters I can't get at <0.9 wink>.  Boosted the priority because it sounds like a legit practical problem.
-------------------------------------------------------

Date: 2000-Sep-20 12:47
By: loewis

Comment:
I can reproduce the problem by installing a Russion or Arabic keyboard layout on Win2k; typing into an Entry or Text widget displays Latin-1 characters. I can observe the same problem with a plain 8.3 wish, so it appears to be a bug in Tk - which apparently truncates characters on input. So I propose to close this as 3rd Party/Later, and recategorize it as Tkinter.
-------------------------------------------------------

Date: 2000-Oct-03 08:23
By: gvanrossum

Comment:
I'll take this so Fredrik can concentrate on SRE.
-------------------------------------------------------

Date: 2000-Oct-12 10:18
By: gvanrossum

Comment:
Closed per Martin's suggestion.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113795&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 18:25:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 10:25:48 -0700
Subject: [Python-bugs-list] [Bug #116289] Programs using Tkinter sometimes can't shut down
Message-ID: <200010121725.KAA15270@delerium.i.sourceforge.net>

Bug #116289, was updated on 2000-Oct-06 19:25
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: Programs using Tkinter sometimes can't shut down

Details: The following msg from the Tutor list is about 1.6, but I noticed the same thing several times today using 2.0b2+CVS.  In my case, I was running IDLE via

python ../tool/idle/idle.pyw

from a DOS box in my PCbuild directory.  Win98SE.  *Most* of the time, shutting down IDLE via Ctrl+Q left the DOS box hanging.  As with the poster, the only way to regain control was to use the Task Manager to kill off Winoldap.

-----Original Message-----
From: Joseph Stubenrauch <nothingisgoingtochangemyworld@yahoo.com>
Sent: Friday, October 06, 2000 9:23 PM
To: tutor@python.org
Subject: Re: [Tutor] Python 1.6 BUG


Strange, I have been experiencing the same bug myself.
Here's the low down for me:

Python 1.6 with win95
I am running a little Tkinter program
The command line I use is simply: "python foo.py"
About 25-35% of the time, when I close the Tkinter
window, DOS seems to "freeze" and never returns to the
c:\ command prompt.  I have to ctrl-alt-delete
repeatedly and shut down "winoldapp" to get rid of the
window and then shell back into DOS and keep working.
It's a bit of a pain, since I have the habit of
testing EVERYTHING in tiny little stages, so I change
one little thing, test it ... freeze ... ARGH!  Change
one more tiny thing, test it ... freeze ... ARGH! 
However, sometimes it seems to behave and doesn't
bother me for an entire several hour session of python
work.

That's my report on the problem.

Cheers,

Joe


Follow-Ups:

Date: 2000-Oct-07 00:37
By: tim_one

Comment:
More info (none good, but some worse so boosted priority):

+ Happens under release and debug builds.

+ Have not been able to provoke when starting in the debugger.

+ Ctrl+Alt+Del and killing Winoldap is not enough to clean everything up.  There's still a Python (or Python_d) process hanging around that Ctrl+Alt+Del doesn't show.

+ This process makes it impossible to delete the associated Python .dll, and in particular makes it impossible to rebuild Python successfully without a reboot.

+ These processes cannot be killed!  Wintop and Process Viewer both fail to get the job done.  PrcView (a freeware process viewer) itself locks up if I try to kill them using it.  Process Viewer freezes for several seconds before giving up.

+ Attempting to attach to the process with the MSVC debugger (in order to find out what the heck it's doing) finds the process OK, but then yields the cryptic and undocumented error msg "Cannot execute program".

+ The processes are not accumulating cycles.

+ Smells like deadlock.
-------------------------------------------------------

Date: 2000-Oct-12 10:25
By: gvanrossum

Comment:
The recent fix to _tkinter (Tcl_GetStringResult(interp) instead of interp->result) didn't fix this either.

As Tim has remarked in private but not yet recorded here, a workaround is to use pythonw instead of python, so I'm lowering thepriority again.

Also note that the hanging process that Tim writes about apparently prevents Win98 from shutting down properly.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116289&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 18:42:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 10:42:08 -0700
Subject: [Python-bugs-list] [Bug #116172] 2.0b2 curses module fails to build on SGI
Message-ID: <200010121742.KAA15971@delerium.i.sourceforge.net>

Bug #116172, was updated on 2000-Oct-05 12:40
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: 2.0b2 curses module fails to build on SGI

Details: I didn't see this in the database.

Trying to build 2.0b2 here on SGI IRIX 6.5.  I have this
line in Setup:

     _curses _cursesmodule.c -lcurses -ltermcap

This used to work on 1.5.2 on IRIX 6.5, but it doesn't with 2.0b2.

Here is a digested version of the errors:

cc -n32  -O -KPIC -I./../Include -I.. -DHAVE_CONFIG_H -c ./_cursesmodule.c
...
  The identifier "attr_t" is undefined.
  The identifier "ACS_S3" is undefined.
  The identifier "ACS_LEQUAL" is undefined.
  The identifier "ACS_GEQUAL" is undefined.
  The identifier "ACS_PI" is undefined.
  The identifier "ACS_NEQUAL" is undefined.
  The identifier "ACS_STERLING" is undefined.
  A value of type "int" cannot be assigned to an entity of type "char *".
        capname = tigetstr( capname );
                ^
  The identifier "A_HORIZONTAL" is undefined.
  The identifier "A_LEFT" is undefined.
  The identifier "A_LOW" is undefined.
  The identifier "A_RIGHT" is undefined.
  The identifier "A_TOP" is undefined.
  The identifier "A_VERTICAL" is undefined.


Follow-Ups:

Date: 2000-Oct-06 07:50
By: gvanrossum

Comment:
I don't know, but I think this may be caused by IRIX having an old, incompatible version of curses. So it probably won't work. Too bad. You may be able to get a different curses implementation (there must be a free one that comes with Linux???).
-------------------------------------------------------

Date: 2000-Oct-06 08:42
By: jhylton

Comment:
Eric, can you look at this today?
-------------------------------------------------------

Date: 2000-Oct-06 11:26
By: VizNut

Comment:
A quick grep reveals Sun Solaris 7 doesn't have them either.

If the intent is to break with standard curses, to avoid confusion it might be best to rename the module from curses to "linux_curses" or "ncurses" (if that's the appropriate curses variety).

Thanks,

-------------------------------------------------------

Date: 2000-Oct-12 10:42
By: gvanrossum

Comment:
This appears to be simply a matter of the platform's curses library being *reeeeeeeally* old. So I'm lowering the priority.

The ncurses API is actually quite old, and vendors have no excuse for not providing it. That's why it's not a good idea to call the module linuxcurses or ncurses.

However, it's quite possible that your vendor provides both the old curses API and the ncurses API, under those names. In that case it shouldn't be hard to change the source code to include "ncurses.h" and the Makefile to link with -lncurses. If you get this working, I'd be glad to accept a patch via the SourceForge Patch manager! This can't be done in 2.0 though (we're in a code freeze stage right now where only critical bugfixes may be checked in).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116172&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 19:16:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 11:16:56 -0700
Subject: [Python-bugs-list] [Bug #115308] codecs base classes need documentation
Message-ID: <200010121816.LAA17409@delerium.i.sourceforge.net>

Bug #115308, was updated on 2000-Sep-25 12:00
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: codecs base classes need documentation

Details: The documentation for the codecs module includes a note that base classes need to be implemented; this needs to happen for the 2.0 final release.

There should be some note at the top of the section about what the module is for -- Unicode is not mentioned, but that's the primary (expected) use.  Let's say something about that, and perhaps give examples at the end (especially for handling encoded files).

For the open() function, the docs refer to a "buffering" parameter, and say that it matches the meaning of the the same thing for the open() built-in.  It should be called "bufsize" to match the built-in documentation.

Follow-Ups:

Date: 2000-Sep-25 14:03
By: lemburg

Comment:
I'll try to write something up, but can't promise anything this
week. I that's a problem, you'll have to assign the bug
to someone else.

Note that the codecs.py module has extensive doc-string
documentation which can be used as basis.

-------------------------------------------------------

Date: 2000-Oct-07 02:01
By: lemburg

Comment:
I'll try to get around and put something together next week.

When is the 2.0 docs deadline, BTW ?

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115308&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 19:24:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 11:24:03 -0700
Subject: [Python-bugs-list] [Bug #116285] Unicode encoders don't report errors properly
Message-ID: <200010121824.LAA17684@delerium.i.sourceforge.net>

Bug #116285, was updated on 2000-Oct-06 17:32
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Remind
Bug Group: Feature Request
Priority: 6
Summary: Unicode encoders don't report errors properly

Details: In current CVS, u"\366".encode("koi8-r") gives '\366'. This is incorrect -
koi8-r does not support LATIN SMALL LETTER O WITH DIAERESIS, so it should raise a UnicodeError instead.

Follow-Ups:

Date: 2000-Oct-09 01:14
By: lemburg

Comment:
Note that this is due to the way the character mapping codec
works: if the dictionary doesn't include a mapping for a certain
character it simply copies that character without raising an
error.

All standard codecs in Python 2.0 which use the generic character
codec only contain explicit mappings from the encoding to Unicode
(for the decoding part). When encoding from Unicode to the encoding,
the decoding map is simply reversed.

To produce correct error
output in all possible cases, the reverse mapping would have to
include all Unicode characters which cannot be mapped to a encoding
character (and map these to None). This is not feasable, so the
"bug" is hard to fix... certainly not for Python 2.0.

I'm setting the bug report to "Feature Request" meaning that it should be
reopened for the 2.1 cycle.
-------------------------------------------------------

Date: 2000-Oct-12 11:24
By: lemburg

Comment:
Closed for 2.0. This request should be reopened for the 2.1 cycle.

As Martin pointed out in private mail, the situation with correct
error handling is not all that bad: the encoders default to latin-1
mappings (ie. 1-1) when converting Unicode to the encoding 
in case no mapping is given for the character.

The fix would be to add explicit encoding mappings for all supplied
standard codecs which map all Latin-1 characters which do not
have a corresponding character in the encoding to None. This will
then cause the codec to raise an error saying that the mapping is
undefined.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116285&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 19:50:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 11:50:10 -0700
Subject: [Python-bugs-list] [Bug #116732] httplib no longer supports old, pre-1.0 HTTP servers
Message-ID: <200010121850.LAA24810@bush.i.sourceforge.net>

Bug #116732, was updated on 2000-Oct-12 11:50
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: httplib no longer supports old, pre-1.0 HTTP servers

Details: A very old Web server may return a response without any HTTP headers.  This is still supported by all browsers I am familiar with and was supported by the old version of httplib.  Greg's new version does not support it, but should.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116732&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 20:54:02 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 12:54:02 -0700
Subject: [Python-bugs-list] [Bug #116649] urllib2.urlopen fails on redirects?
Message-ID: <200010121954.MAA27192@bush.i.sourceforge.net>

Bug #116649, was updated on 2000-Oct-11 12:04
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: urllib2.urlopen fails on redirects?

Details: The following code produces an AttributeError exception un urllib2.  The equivalent code run from urllib works ok.  This was tested on Windows 2000, Python 2.0 Release Candidate 1.

### TEST CODE ########################
def testUrlRedirect(url):
	print "urllib.urlopen - ",
	u = urllib.urlopen(url)
	print "SUCCESS"

	print "urllib2.urlopen - ",
	u = urllib2.urlopen(url)
	print "SUCCESS"
testUrlRedirect('http://www.realestatemarketing.com')


### OUTPUT ##########################
urllib.urlopen -  SUCCESS
urllib2.urlopen -
Traceback (most recent call last):
  File "C:\dev_share\ffs\bin\brokers.py", line 38, in ?
    testUrlRedirect('http://www.realestatemarketing.com')
  File "C:\dev_share\ffs\bin\brokers.py", line 34, in testUrlRedirect
    u = urllib2.urlopen(url)
  File "c:\python20\lib\urllib2.py", line 137, in urlopen
    return _opener.open(url, data)
  File "c:\python20\lib\urllib2.py", line 321, in open
    '_open', req)
  File "c:\python20\lib\urllib2.py", line 300, in _call_chain
    result = apply(func, args)
  File "c:\python20\lib\urllib2.py", line 757, in http_open
    if h.sock:
AttributeError: 'HTTP' instance has no attribute 'sock'

Follow-Ups:

Date: 2000-Oct-12 12:54
By: jhylton

Comment:
Fixed in revision 1.6 of urllib2

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116649&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 20:58:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 12:58:58 -0700
Subject: [Python-bugs-list] [Bug #116732] httplib no longer supports old, pre-1.0 HTTP servers
Message-ID: <200010121958.MAA27375@bush.i.sourceforge.net>

Bug #116732, was updated on 2000-Oct-12 11:50
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 6
Summary: httplib no longer supports old, pre-1.0 HTTP servers

Details: A very old Web server may return a response without any HTTP headers.  This is still supported by all browsers I am familiar with and was supported by the old version of httplib.  Greg's new version does not support it, but should.


Follow-Ups:

Date: 2000-Oct-12 12:58
By: jhylton

Comment:
Fixed in revision 1.24 of httplib

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116732&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 21:23:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 13:23:52 -0700
Subject: [Python-bugs-list] [Bug #116263] Tools/compiler cannot  handle "from foo import *"
Message-ID: <200010122023.NAA28444@bush.i.sourceforge.net>

Bug #116263, was updated on 2000-Oct-06 11:17
Here is a current snapshot of the bug.

Project: Python
Category: demos and tools
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: Tools/compiler cannot  handle "from foo import *"

Details: Try compiling a file containing "from types import *" to see the
traceback.  The compiler does not seem to know about the 
IMPORT_STAR opcode.

Follow-Ups:

Date: 2000-Oct-12 13:23
By: jhylton

Comment:
fixed in rev. 1.12 of transformer.py (etc.)

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116263&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 21:26:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 13:26:29 -0700
Subject: [Python-bugs-list] [Bug #116285] Unicode encoders don't report errors properly
Message-ID: <200010122026.NAB22433@delerium.i.sourceforge.net>

Bug #116285, was updated on 2000-Oct-06 17:32
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: Remind
Bug Group: Feature Request
Priority: 3
Summary: Unicode encoders don't report errors properly

Details: In current CVS, u"\366".encode("koi8-r") gives '\366'. This is incorrect -
koi8-r does not support LATIN SMALL LETTER O WITH DIAERESIS, so it should raise a UnicodeError instead.

Follow-Ups:

Date: 2000-Oct-09 01:14
By: lemburg

Comment:
Note that this is due to the way the character mapping codec
works: if the dictionary doesn't include a mapping for a certain
character it simply copies that character without raising an
error.

All standard codecs in Python 2.0 which use the generic character
codec only contain explicit mappings from the encoding to Unicode
(for the decoding part). When encoding from Unicode to the encoding,
the decoding map is simply reversed.

To produce correct error
output in all possible cases, the reverse mapping would have to
include all Unicode characters which cannot be mapped to a encoding
character (and map these to None). This is not feasable, so the
"bug" is hard to fix... certainly not for Python 2.0.

I'm setting the bug report to "Feature Request" meaning that it should be
reopened for the 2.1 cycle.
-------------------------------------------------------

Date: 2000-Oct-12 11:24
By: lemburg

Comment:
Closed for 2.0. This request should be reopened for the 2.1 cycle.

As Martin pointed out in private mail, the situation with correct
error handling is not all that bad: the encoders default to latin-1
mappings (ie. 1-1) when converting Unicode to the encoding 
in case no mapping is given for the character.

The fix would be to add explicit encoding mappings for all supplied
standard codecs which map all Latin-1 characters which do not
have a corresponding character in the encoding to None. This will
then cause the codec to raise an error saying that the mapping is
undefined.
-------------------------------------------------------

Date: 2000-Oct-12 13:26
By: lemburg

Comment:
Reopened so that the bug doesn't get forgotten in 2.1. Instead
of closing the bug, I will set the priority to 3 which should signal
"not vital for the Python 2.0 release".
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116285&group_id=5470


From noreply@sourceforge.net  Thu Oct 12 21:53:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 13:53:57 -0700
Subject: [Python-bugs-list] [Bug #115308] codecs base classes need documentation
Message-ID: <200010122053.NAA29683@bush.i.sourceforge.net>

Bug #115308, was updated on 2000-Sep-25 12:00
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: codecs base classes need documentation

Details: The documentation for the codecs module includes a note that base classes need to be implemented; this needs to happen for the 2.0 final release.

There should be some note at the top of the section about what the module is for -- Unicode is not mentioned, but that's the primary (expected) use.  Let's say something about that, and perhaps give examples at the end (especially for handling encoded files).

For the open() function, the docs refer to a "buffering" parameter, and say that it matches the meaning of the the same thing for the open() built-in.  It should be called "bufsize" to match the built-in documentation.

Follow-Ups:

Date: 2000-Sep-25 14:03
By: lemburg

Comment:
I'll try to write something up, but can't promise anything this
week. I that's a problem, you'll have to assign the bug
to someone else.

Note that the codecs.py module has extensive doc-string
documentation which can be used as basis.

-------------------------------------------------------

Date: 2000-Oct-07 02:01
By: lemburg

Comment:
I'll try to get around and put something together next week.

When is the 2.0 docs deadline, BTW ?

-------------------------------------------------------

Date: 2000-Oct-12 13:53
By: fdrake

Comment:
Closed using content based on patch #101877, checked in as Doc/lib/libcodecs.tex revision 1.4.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115308&group_id=5470


From noreply@sourceforge.net  Fri Oct 13 03:41:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 19:41:20 -0700
Subject: [Python-bugs-list] [Bug #115026] SSL features undocumented
Message-ID: <200010130241.TAA03883@delerium.i.sourceforge.net>

Bug #115026, was updated on 2000-Sep-21 15:29
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: Later
Bug Group: None
Priority: 3
Summary: SSL features undocumented

Details: The socket.ssl function, and the SSL objects, are not documented.

Follow-Ups:

Date: 2000-Sep-21 20:46
By: fdrake

Comment:
Low priority for 2.0, but reasonable patches will be considered.
-------------------------------------------------------

Date: 2000-Oct-12 19:41
By: fdrake

Comment:
I should note that the SSL support in the socket module was discussed briefly at a PythonLabs meeting a few weeks ago in the context of a bug report complaining that the SSL code here wasn't portable to Windows.

We decided that SSL support probably belonged in a separate module in the first place, so all this might change in some future release.  Especially if anyone would like to fund some work on getting SSL support working across platforms.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115026&group_id=5470


From noreply@sourceforge.net  Fri Oct 13 04:02:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 12 Oct 2000 20:02:28 -0700
Subject: [Python-bugs-list] [Bug #116678] minidom doesn't raise exception for illegal children
Message-ID: <200010130302.UAA11218@bush.i.sourceforge.net>

Bug #116678, was updated on 2000-Oct-11 19:30
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: minidom doesn't raise exception for illegal children

Details: Some types of DOM node such as Text can't have children.
minidom doesn't check for this at all:

from xml.dom import minidom
doc = minidom.Document()
text = doc.createTextNode('lorem ipsum')
elem = doc.createElement('leaf')
text.appendChild( elem )
print text.toxml()

This outputs just 'lorem ipsum', but elem really is a child 
of text; Text.toxml() just isn't recursing because it doesn't expect to do so.



Follow-Ups:

Date: 2000-Oct-12 20:02
By: fdrake

Comment:
This is a bug with detecting an improper use.  It should be fixed, but need not be for Python 2.0.  Correct use will not produce erroneous behavior.  Reducing priority by one.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116678&group_id=5470


From noreply@sourceforge.net  Fri Oct 13 11:21:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Oct 2000 03:21:05 -0700
Subject: [Python-bugs-list] [Bug #116720] function to open a file and create intermediate directories
Message-ID: <200010131021.DAA24976@delerium.i.sourceforge.net>

Bug #116720, was updated on 2000-Oct-12 09:24
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Wont Fix
Bug Group: Feature Request
Priority: 5
Summary: function to open a file and create intermediate directories

Details: A function would be useful (maybe available in the
os module), that opens a file for writing and creates
all necessary intermediate directories. Here is the
Python function that does exactly that:

def forceopen(name, filemode, dirmode=0777):
    try:
        return open(name, filemode)
    except IOError, e:
       if e[0] != 2: # didn't work for some other reason
           raise
       lastsep = name.rfind(os.sep)
       if lastsep == -1:
           raise
       os.makedirs(name[:lastsep], dirmode)
       return open(name, filemode)


Follow-Ups:

Date: 2000-Oct-12 10:06
By: fdrake

Comment:
This seems too esoteric a function to include in the standard libraries.  Without some serious justification, I don't see why this should be added since it's simple enough to add to an application's utility libraries.
-------------------------------------------------------

Date: 2000-Oct-13 03:21
By: doerwalter

Comment:
It's about as esoteric as os.makedir. For what purpose would somebody want to recursively make some directories, if not to put a file in there?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116720&group_id=5470


From noreply@sourceforge.net  Fri Oct 13 14:33:36 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Oct 2000 06:33:36 -0700
Subject: [Python-bugs-list] [Bug #116787] StringIO does not check constructor argument type
Message-ID: <200010131333.GAA32203@delerium.i.sourceforge.net>

Bug #116787, was updated on 2000-Oct-13 06:33
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: StringIO does not check constructor argument type

Details: Python 2.0c1 (#7, Oct  9 2000, 18:44:43) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.6 -- press F1 for help
>>> import StringIO
>>> file = open("C:/Python20/readme.txt")
>>> fstr = StringIO.StringIO(file.readlines())

# The above line differs from the behavior of cStringIO, which correctly
# reports: "TypeError: expected string, list found"
# Doom is inevitable after this...

>>> len(fstr.getvalue())
838
>>> fstr.readline()
Traceback (innermost last):
  File "<pyshell#4>", line 1, in ?
    fstr.readline()
  File "c:\python20\lib\StringIO.py", line 85, in readline
    i = string.find(self.buf, '\n', self.pos)
  File "c:\python20\lib\string.py", line 172, in find
    return s.find(*args)
AttributeError: find
>>> 

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116787&group_id=5470


From noreply@sourceforge.net  Fri Oct 13 15:07:23 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Oct 2000 07:07:23 -0700
Subject: [Python-bugs-list] [Bug #116787] StringIO does not check constructor argument type
Message-ID: <200010131407.HAA03258@bush.i.sourceforge.net>

Bug #116787, was updated on 2000-Oct-13 06:33
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: StringIO does not check constructor argument type

Details: Python 2.0c1 (#7, Oct  9 2000, 18:44:43) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.6 -- press F1 for help
>>> import StringIO
>>> file = open("C:/Python20/readme.txt")
>>> fstr = StringIO.StringIO(file.readlines())

# The above line differs from the behavior of cStringIO, which correctly
# reports: "TypeError: expected string, list found"
# Doom is inevitable after this...

>>> len(fstr.getvalue())
838
>>> fstr.readline()
Traceback (innermost last):
  File "<pyshell#4>", line 1, in ?
    fstr.readline()
  File "c:\python20\lib\StringIO.py", line 85, in readline
    i = string.find(self.buf, '\n', self.pos)
  File "c:\python20\lib\string.py", line 172, in find
    return s.find(*args)
AttributeError: find
>>> 

Follow-Ups:

Date: 2000-Oct-13 07:07
By: fdrake

Comment:
I'm not convinced this is a bug.  Is there a reason StringIO should not accept any sequence object that returns characters for each position?  Unicode and UserString objects should be acceptable. This seems particularly difficult to test for up front.  I think the allowance of only 8-bit strings should be documented as a limitation of the currrent implementation of cStringIO.

Guido will need to make a pronouncement here.  Adding a test for the input type being a string or Unicode object would be easy enough.  Guido, feel free to assign back to me to handle this based on your decision.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116787&group_id=5470


From noreply@sourceforge.net  Fri Oct 13 15:23:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Oct 2000 07:23:39 -0700
Subject: [Python-bugs-list] [Bug #116787] StringIO does not check constructor argument type
Message-ID: <200010131423.HAA03865@bush.i.sourceforge.net>

Bug #116787, was updated on 2000-Oct-13 06:33
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: StringIO does not check constructor argument type

Details: Python 2.0c1 (#7, Oct  9 2000, 18:44:43) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.6 -- press F1 for help
>>> import StringIO
>>> file = open("C:/Python20/readme.txt")
>>> fstr = StringIO.StringIO(file.readlines())

# The above line differs from the behavior of cStringIO, which correctly
# reports: "TypeError: expected string, list found"
# Doom is inevitable after this...

>>> len(fstr.getvalue())
838
>>> fstr.readline()
Traceback (innermost last):
  File "<pyshell#4>", line 1, in ?
    fstr.readline()
  File "c:\python20\lib\StringIO.py", line 85, in readline
    i = string.find(self.buf, '\n', self.pos)
  File "c:\python20\lib\string.py", line 172, in find
    return s.find(*args)
AttributeError: find
>>> 

Follow-Ups:

Date: 2000-Oct-13 07:07
By: fdrake

Comment:
I'm not convinced this is a bug.  Is there a reason StringIO should not accept any sequence object that returns characters for each position?  Unicode and UserString objects should be acceptable. This seems particularly difficult to test for up front.  I think the allowance of only 8-bit strings should be documented as a limitation of the currrent implementation of cStringIO.

Guido will need to make a pronouncement here.  Adding a test for the input type being a string or Unicode object would be easy enough.  Guido, feel free to assign back to me to handle this based on your decision.
-------------------------------------------------------

Date: 2000-Oct-13 07:23
By: gvanrossum

Comment:
Eh, Fred, he didn't complain about Unicode string. The argument was totally bogus (a list of strings).

But I agree that it's not a bug -- we can't possibly put type checks in all library routines. The argument has a bad type and (eventually) you get an exception. That's all we promise.

Incidentally, StringIO *does* seem to support Unicode strings "just right" (unlike cStringIO, which attempts to coerce Unicode args to ASCII first).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116787&group_id=5470


From noreply@sourceforge.net  Fri Oct 13 15:28:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Oct 2000 07:28:04 -0700
Subject: [Python-bugs-list] [Bug #116787] StringIO does not check constructor argument type
Message-ID: <200010131428.HAA04053@bush.i.sourceforge.net>

Bug #116787, was updated on 2000-Oct-13 06:33
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: StringIO does not check constructor argument type

Details: Python 2.0c1 (#7, Oct  9 2000, 18:44:43) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.6 -- press F1 for help
>>> import StringIO
>>> file = open("C:/Python20/readme.txt")
>>> fstr = StringIO.StringIO(file.readlines())

# The above line differs from the behavior of cStringIO, which correctly
# reports: "TypeError: expected string, list found"
# Doom is inevitable after this...

>>> len(fstr.getvalue())
838
>>> fstr.readline()
Traceback (innermost last):
  File "<pyshell#4>", line 1, in ?
    fstr.readline()
  File "c:\python20\lib\StringIO.py", line 85, in readline
    i = string.find(self.buf, '\n', self.pos)
  File "c:\python20\lib\string.py", line 172, in find
    return s.find(*args)
AttributeError: find
>>> 

Follow-Ups:

Date: 2000-Oct-13 07:07
By: fdrake

Comment:
I'm not convinced this is a bug.  Is there a reason StringIO should not accept any sequence object that returns characters for each position?  Unicode and UserString objects should be acceptable. This seems particularly difficult to test for up front.  I think the allowance of only 8-bit strings should be documented as a limitation of the currrent implementation of cStringIO.

Guido will need to make a pronouncement here.  Adding a test for the input type being a string or Unicode object would be easy enough.  Guido, feel free to assign back to me to handle this based on your decision.
-------------------------------------------------------

Date: 2000-Oct-13 07:23
By: gvanrossum

Comment:
Eh, Fred, he didn't complain about Unicode string. The argument was totally bogus (a list of strings).

But I agree that it's not a bug -- we can't possibly put type checks in all library routines. The argument has a bad type and (eventually) you get an exception. That's all we promise.

Incidentally, StringIO *does* seem to support Unicode strings "just right" (unlike cStringIO, which attempts to coerce Unicode args to ASCII first).
-------------------------------------------------------

Date: 2000-Oct-13 07:28
By: holdenweb

Comment:
I guess I was mostly looking at the inconsistency between cStringIO and StringIO.
It seems reasonable that a C module should check more rigorously, now you point
it out, since the results are more likely to be fatal under those circumstances.

Thanks for looking.  Delete this bug as necessary.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116787&group_id=5470


From noreply@sourceforge.net  Fri Oct 13 15:40:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Oct 2000 07:40:57 -0700
Subject: [Python-bugs-list] [Bug #116289] Programs using Tkinter sometimes can't shut down
Message-ID: <200010131440.HAA02337@delerium.i.sourceforge.net>

Bug #116289, was updated on 2000-Oct-06 19:25
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: Programs using Tkinter sometimes can't shut down

Details: The following msg from the Tutor list is about 1.6, but I noticed the same thing several times today using 2.0b2+CVS.  In my case, I was running IDLE via

python ../tool/idle/idle.pyw

from a DOS box in my PCbuild directory.  Win98SE.  *Most* of the time, shutting down IDLE via Ctrl+Q left the DOS box hanging.  As with the poster, the only way to regain control was to use the Task Manager to kill off Winoldap.

-----Original Message-----
From: Joseph Stubenrauch <nothingisgoingtochangemyworld@yahoo.com>
Sent: Friday, October 06, 2000 9:23 PM
To: tutor@python.org
Subject: Re: [Tutor] Python 1.6 BUG


Strange, I have been experiencing the same bug myself.
Here's the low down for me:

Python 1.6 with win95
I am running a little Tkinter program
The command line I use is simply: "python foo.py"
About 25-35% of the time, when I close the Tkinter
window, DOS seems to "freeze" and never returns to the
c:\ command prompt.  I have to ctrl-alt-delete
repeatedly and shut down "winoldapp" to get rid of the
window and then shell back into DOS and keep working.
It's a bit of a pain, since I have the habit of
testing EVERYTHING in tiny little stages, so I change
one little thing, test it ... freeze ... ARGH!  Change
one more tiny thing, test it ... freeze ... ARGH! 
However, sometimes it seems to behave and doesn't
bother me for an entire several hour session of python
work.

That's my report on the problem.

Cheers,

Joe


Follow-Ups:

Date: 2000-Oct-07 00:37
By: tim_one

Comment:
More info (none good, but some worse so boosted priority):

+ Happens under release and debug builds.

+ Have not been able to provoke when starting in the debugger.

+ Ctrl+Alt+Del and killing Winoldap is not enough to clean everything up.  There's still a Python (or Python_d) process hanging around that Ctrl+Alt+Del doesn't show.

+ This process makes it impossible to delete the associated Python .dll, and in particular makes it impossible to rebuild Python successfully without a reboot.

+ These processes cannot be killed!  Wintop and Process Viewer both fail to get the job done.  PrcView (a freeware process viewer) itself locks up if I try to kill them using it.  Process Viewer freezes for several seconds before giving up.

+ Attempting to attach to the process with the MSVC debugger (in order to find out what the heck it's doing) finds the process OK, but then yields the cryptic and undocumented error msg "Cannot execute program".

+ The processes are not accumulating cycles.

+ Smells like deadlock.
-------------------------------------------------------

Date: 2000-Oct-12 10:25
By: gvanrossum

Comment:
The recent fix to _tkinter (Tcl_GetStringResult(interp) instead of interp->result) didn't fix this either.

As Tim has remarked in private but not yet recorded here, a workaround is to use pythonw instead of python, so I'm lowering thepriority again.

Also note that the hanging process that Tim writes about apparently prevents Win98 from shutting down properly.
-------------------------------------------------------

Date: 2000-Oct-13 07:40
By: gvanrossum

Comment:
Back to Tim since I have no clue what to do here.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116289&group_id=5470


From noreply@sourceforge.net  Fri Oct 13 15:45:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Oct 2000 07:45:34 -0700
Subject: [Python-bugs-list] [Bug #110665] Compiling python on hpux 11.00 with threads (PR#360)
Message-ID: <200010131445.HAA02551@delerium.i.sourceforge.net>

Bug #110665, was updated on 2000-Jul-31 14:12
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: Compiling python on hpux 11.00 with threads (PR#360)

Details: Jitterbug-Id: 360
Submitted-By: philipp.jocham@salomon.at
Date: Fri, 16 Jun 2000 08:47:06 -0400 (EDT)
Version: 1.5.2
OS: HP-UX 11.00


There are two missing details in the configure process to make this work
out of the box.

First: The function 
	pthread_create
isn't found in library libpthread.a but in libcma.a, because
pthread_create is just a macro in sys/pthread.h pointing to 
	__pthread_create_system

After patching ./configure directly and running 
	./configure --with-thread
(now detecting the correct library /usr/lib/libpthread.a) I also
added -lcl to Modules/Makefile at
	LIBS=           -lnet -lnsl -ldld  -lpthread -lcl

otherwise importing of modules with threads didn't work 
(in this case oci_.sl from DCOracle). 

I'm not sure about the correct syntax or wether it's the correct
place and method, but I would suggest a solution like the following
code snippet.

[...]
AC_MSG_CHECKING(for --with-thread)
[...]
AC_DEFINE(_POSIX_THREADS)
LIBS="$LIBS -lpthread -lcl"
LIBOBJS="$LIBOBJS thread.o"], [
AC_CHECK_LIB(pthread, __pthread_create_system, [AC_DEFINE(WITH_THREAD)
[...]

I hope this helps to make installation process smoother.
Fell free to contact me, if there are further questions.
Philipp
-- 
I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.



====================================================================
Audit trail:
Tue Jul 11 08:26:01 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-22 02:56
By: gvanrossum

Comment:
Taking this because I'm considering to redesign the thread configuration section in configure.in anyway -- there's a similar bug report for Alpha OSF1.
-------------------------------------------------------

Date: 2000-Sep-25 06:10
By: gvanrossum

Comment:
I'm hoping that this was fixed by recent changes. Sent an email to the original submittor to verify.
-------------------------------------------------------

Date: 2000-Oct-06 10:40
By: gvanrossum

Comment:
I have two reports from people for whom configure, build and run  with threads now works on HP-UX 10 and 11. I'm not sure what to do about this report... What's different on Philipp's system???
-------------------------------------------------------

Date: 2000-Oct-10 04:55
By: edg

Comment:
I can confirm that the bug still exists in 2.0c1.
It works fine on HP-UX 10.20 (which only has libcma),
but not on HP-UX 11 (which both has libcma and libpthread).
The pthread_create function is not defined as a macro though,
but as a static function:

static int pthread_create(pthread_t *tid, const pthread_attr_t *attr, void *(*start_routine)(void *), void *arg)
   { return(__pthread_create_system(tid, attr, start_routine, arg)); }

I don't see an easy way to work around this.
I'm not a configure expert, but perhaps the script should
first check whether this code compiles and links:

#include <pthread.h>
int main()
{
   pthread_create(0,0,0,0);
   return 0;
}

and if not, fall back on the other tests ?

-------------------------------------------------------

Date: 2000-Oct-13 07:45
By: gvanrossum

Comment:
OK, so the correct thing to do seems to be to somehow add #include <pthread.h> to the tests for thread libraries. I'm afraid I won't be able to fix this in 2.0final, but I'll think about fixing it in 2.1 (or 2.0.1, whichever comes first :-).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110665&group_id=5470


From noreply@sourceforge.net  Fri Oct 13 15:49:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Oct 2000 07:49:03 -0700
Subject: [Python-bugs-list] [Bug #114923] ToolTip not showing text on AIX 4.3
Message-ID: <200010131449.HAA02702@delerium.i.sourceforge.net>

Bug #114923, was updated on 2000-Sep-20 14:27
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: ToolTip not showing text on AIX 4.3

Details: IDLE0.6 runs nicely on AIX except that the tip text itself does not show when the pop up box appears. The box seems to be sized properly but is blank.

-Robin Friedrich

Follow-Ups:

Date: 2000-Sep-20 16:54
By: gvanrossum

Comment:
Could it be a Tcl version problem? It's hard to debug this... :-(
-------------------------------------------------------

Date: 2000-Sep-21 14:17
By: none

Comment:
Yes I imagine it will be hard to debug. The tclTk version is 8.3.2. I am unaware of problems with that on the X windows platforms. Has this been noticed on other unices with 2.0b1?  --Robin F.
-------------------------------------------------------

Date: 2000-Sep-21 14:23
By: gvanrossum

Comment:
BTW, where do you expect to see tooltips? The only place I can think of is when you type a function name followed by a left paren. Is that it? What function name did you use?

(And yes, this works fine for me on Linux.)

Could it have to do with font? color? Perhaps your window manager?
Source is in CallTipWindow.py if you want to play.
-------------------------------------------------------

Date: 2000-Sep-25 11:39
By: none

Comment:
The open paren binding yes. Any function like those in the string module.
OK I've played with CallTipWindow.py and the main() test routine exhibits the bug nicely. The code looks dead simple and should work. I can only blame Tk 8.3.2. I tried linking in our old Tk 8.0 libraries/headers (hoping Tkinter was still compatible with it) and the tooltip call now raises the following. We are using X/Motif with the CDE window manager.

>>> idle.CallTipWindow.main()
>>> Exception in Tkinter callback
Traceback (most recent call last):
  File "./Lib/lib-tk/Tkinter.py", line 1283, in __call__
    args = apply(self.subst, args)
  File "./Lib/lib-tk/Tkinter.py", line 1053, in _substitute
    e.delta = getint(D)
ValueError: invalid literal for int(): D




-------------------------------------------------------

Date: 2000-Sep-25 12:41
By: gvanrossum

Comment:
The getint(D) problem is because earlier versions of Tkinter don't support the mousewheel delta value.

Try again with the current CVS version (or wait 1.5 days for Python 2.0b2 to be released). The getint(D) problem should be solved in the CVS version (a try/except is put around it).
-------------------------------------------------------

Date: 2000-Sep-25 13:37
By: none

Comment:
I tried to trap the error and go on but then the test still fails to show text in the tooltip window with 8.0 Tk. I'm kinda stumped at this point.   Do you know of any other AIX users which I could pester instead of you?

-Robin F.
-------------------------------------------------------

Date: 2000-Oct-13 07:49
By: gvanrossum

Comment:
Hi Robin, I don't know of any other AIX users -- Vladimir Marangozov is in the middle of a move and hasn't resurfaced yet. (You can always try python-list@python.org of course.)

You could try to upgrade to Tcl/tk 8.3 -- I'm suspecting a Tcl or Tk error at this point and AIX is a minority platform for them too...

Also, try the CVS version of _tkinter.c (or wait for 2.0final) -- yesterday I checked in a change that avoids using interp->result, which is deprecated and caused (different) problems on Windows. Who knows. Just a lark.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114923&group_id=5470


From noreply@sourceforge.net  Fri Oct 13 17:11:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Oct 2000 09:11:44 -0700
Subject: [Python-bugs-list] [Bug #116255] 2.0b2:  LDSHARED incorrect on SGI IRIX
Message-ID: <200010131611.JAA06199@delerium.i.sourceforge.net>

Bug #116255, was updated on 2000-Oct-06 10:06
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 2.0b2:  LDSHARED incorrect on SGI IRIX

Details: I think that's the problem.  But someone versed in Python Distutils will have to judge whether my fix is the right one.

NumPy 17.0 fails to build for me on 2.0b2 on IRIX 6.5.  This patch to the Python 2.0b2 installed tree fixes it and let's NumPy build correctly on IRIX.

config/Makefile:
-LDSHARED=       ld
+LDSHARED=       ld -shared $(LDFLAGS)

------------------------------------------------------------
Here is more detail on the error and the fix:

The NumPy build (for the latest version) fails on IRIX.

  cc -n32 -O ... 
  cc -n32 -O ... 
  ... 
  ld <list of .o's> -o build/lib.irix64-6.5-2.0/_numpy.so 

  ld: FATAL 12 : Expecting o32 objects:  
  build/temp.irix64-6.5-2.0/Src/_numpymodule.o is n32. 

There are two things failing the NumPy build. First, the ld invocation (in Distutils I assume) isn't specifying $LDFLAGS on the invocation line (which contains -n32), and second the ld invocation isn't specifying -shared.  The former is needed so the linker links a file with the same architecture as the source files it compiles; the latter is needed in order to build a shared object.

Thanks,

Randall



Follow-Ups:

Date: 2000-Oct-12 07:50
By: VizNut

Comment:
I just pulled and tested 2.0c1.  LDSHARED is not set correctly in this version either.  

This incorrect LDSHARED setting results in packages using Python's Makefile facility (PIL, DistUtils modules, etc.)  to fail when linking their shared object modules.

-------------------------------------------------------

Date: 2000-Oct-12 09:26
By: gvanrossum

Comment:
Dear VizNut (what's your real name?), I'm not unwilling to fix this, but I can't apply your patch -- that file is generated.

The curious thing is that the configure script does test for IRIX and sets LDSHARED correctly when IRIX/5* or IRIX*/6* is detected.

I wonder what went wrong???

The only thing I can think of is that somehow uname returns something else than IRIX? What is the output of uname -s? Of uname -a?
-------------------------------------------------------

Date: 2000-Oct-13 09:11
By: VizNut

Comment:
> Dear VizNut (what's your real name?), 

Hi Guido.  This is Randall Hopper.  I'm a somewhat infrequent poster to the list -- pretty busy with other things lately.  But I did want to make sure I helped test Python 2.

> I'm not unwilling to fix this, but I can't apply your patch -- that file is generated.

> The curious thing is that the configure script does test for IRIX and sets LDSHARED correctly when IRIX/5* or IRIX*/6* is detected.

> The only thing I can think of is that somehow uname returns something else than IRIX? What is the output of uname -s? Of uname -a?

Ahhh, that's it.  Thanks for explaining what it is doing.  Yes, on IRIX systems that support 64-bit addressing (all recent systems), uname -s returns "IRIX64".  On older systems, it returns "IRIX".  So when identifying IRIX, both should be accepted.

SGI should have come up with a better idea IMO, but then so should Microsoft with 64-bit Windows and "win32".

Just to be concrete, here is the output of the two command invocations you mentioned on modern SGI Octane and Onyx2 systems:

> uname -a
IRIX64 ralph 6.5 07201611 IP30
> uname -s
IRIX64

> uname -a
IRIX64 ethyl 6.5 07201611 IP27
> uname -s
IRIX64

Thanks in advance!

Randall


-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116255&group_id=5470


From noreply@sourceforge.net  Fri Oct 13 17:42:07 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Oct 2000 09:42:07 -0700
Subject: [Python-bugs-list] [Bug #116255] 2.0b2:  LDSHARED incorrect on SGI IRIX
Message-ID: <200010131642.JAA09593@bush.i.sourceforge.net>

Bug #116255, was updated on 2000-Oct-06 10:06
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 2.0b2:  LDSHARED incorrect on SGI IRIX

Details: I think that's the problem.  But someone versed in Python Distutils will have to judge whether my fix is the right one.

NumPy 17.0 fails to build for me on 2.0b2 on IRIX 6.5.  This patch to the Python 2.0b2 installed tree fixes it and let's NumPy build correctly on IRIX.

config/Makefile:
-LDSHARED=       ld
+LDSHARED=       ld -shared $(LDFLAGS)

------------------------------------------------------------
Here is more detail on the error and the fix:

The NumPy build (for the latest version) fails on IRIX.

  cc -n32 -O ... 
  cc -n32 -O ... 
  ... 
  ld <list of .o's> -o build/lib.irix64-6.5-2.0/_numpy.so 

  ld: FATAL 12 : Expecting o32 objects:  
  build/temp.irix64-6.5-2.0/Src/_numpymodule.o is n32. 

There are two things failing the NumPy build. First, the ld invocation (in Distutils I assume) isn't specifying $LDFLAGS on the invocation line (which contains -n32), and second the ld invocation isn't specifying -shared.  The former is needed so the linker links a file with the same architecture as the source files it compiles; the latter is needed in order to build a shared object.

Thanks,

Randall



Follow-Ups:

Date: 2000-Oct-12 07:50
By: VizNut

Comment:
I just pulled and tested 2.0c1.  LDSHARED is not set correctly in this version either.  

This incorrect LDSHARED setting results in packages using Python's Makefile facility (PIL, DistUtils modules, etc.)  to fail when linking their shared object modules.

-------------------------------------------------------

Date: 2000-Oct-12 09:26
By: gvanrossum

Comment:
Dear VizNut (what's your real name?), I'm not unwilling to fix this, but I can't apply your patch -- that file is generated.

The curious thing is that the configure script does test for IRIX and sets LDSHARED correctly when IRIX/5* or IRIX*/6* is detected.

I wonder what went wrong???

The only thing I can think of is that somehow uname returns something else than IRIX? What is the output of uname -s? Of uname -a?
-------------------------------------------------------

Date: 2000-Oct-13 09:11
By: VizNut

Comment:
> Dear VizNut (what's your real name?), 

Hi Guido.  This is Randall Hopper.  I'm a somewhat infrequent poster to the list -- pretty busy with other things lately.  But I did want to make sure I helped test Python 2.

> I'm not unwilling to fix this, but I can't apply your patch -- that file is generated.

> The curious thing is that the configure script does test for IRIX and sets LDSHARED correctly when IRIX/5* or IRIX*/6* is detected.

> The only thing I can think of is that somehow uname returns something else than IRIX? What is the output of uname -s? Of uname -a?

Ahhh, that's it.  Thanks for explaining what it is doing.  Yes, on IRIX systems that support 64-bit addressing (all recent systems), uname -s returns "IRIX64".  On older systems, it returns "IRIX".  So when identifying IRIX, both should be accepted.

SGI should have come up with a better idea IMO, but then so should Microsoft with 64-bit Windows and "win32".

Just to be concrete, here is the output of the two command invocations you mentioned on modern SGI Octane and Onyx2 systems:

> uname -a
IRIX64 ralph 6.5 07201611 IP30
> uname -s
IRIX64

> uname -a
IRIX64 ethyl 6.5 07201611 IP27
> uname -s
IRIX64

Thanks in advance!

Randall


-------------------------------------------------------

Date: 2000-Oct-13 09:42
By: VizNut

Comment:
To help track this, I started picking through configure and references related to uname.  I found through experimentation that this variable in my Python build script environment:

setenv MACHDEP irix646

was preventing LDSHARED from being set correctly by configure.  I had been setting this with Python thus far because Python installs object files in a directory under $PREFIX with this $MACHDEP string in a directory name, and $MACHDEP is set differently based on whether this is an IRIX or an IRIX64 system, regardless of the compile architecture settings (you can compile code for IRIX on an IRIX64 system via -o32 and -n32). 

Even when building for the same architecture, generating the same object files, it would install in a different subdirectory name based on $MACHDEP on different systems.

Unsetting this variable allows LDSHARED to be set correctly.  It's a work-around for now at least.

Thanks for the help.  If you'd like, we can close this bug out.  And later if I come up with a patch to fix the "different install directory" problem (if I find it's still needed with Python2), I'll open another PR.

Thanks,

Randall





-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116255&group_id=5470


From noreply@sourceforge.net  Fri Oct 13 17:56:15 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Oct 2000 09:56:15 -0700
Subject: [Python-bugs-list] [Bug #116255] 2.0b2:  LDSHARED incorrect on SGI IRIX
Message-ID: <200010131656.JAA08132@delerium.i.sourceforge.net>

Bug #116255, was updated on 2000-Oct-06 10:06
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Invalid
Bug Group: None
Priority: 5
Summary: 2.0b2:  LDSHARED incorrect on SGI IRIX

Details: I think that's the problem.  But someone versed in Python Distutils will have to judge whether my fix is the right one.

NumPy 17.0 fails to build for me on 2.0b2 on IRIX 6.5.  This patch to the Python 2.0b2 installed tree fixes it and let's NumPy build correctly on IRIX.

config/Makefile:
-LDSHARED=       ld
+LDSHARED=       ld -shared $(LDFLAGS)

------------------------------------------------------------
Here is more detail on the error and the fix:

The NumPy build (for the latest version) fails on IRIX.

  cc -n32 -O ... 
  cc -n32 -O ... 
  ... 
  ld <list of .o's> -o build/lib.irix64-6.5-2.0/_numpy.so 

  ld: FATAL 12 : Expecting o32 objects:  
  build/temp.irix64-6.5-2.0/Src/_numpymodule.o is n32. 

There are two things failing the NumPy build. First, the ld invocation (in Distutils I assume) isn't specifying $LDFLAGS on the invocation line (which contains -n32), and second the ld invocation isn't specifying -shared.  The former is needed so the linker links a file with the same architecture as the source files it compiles; the latter is needed in order to build a shared object.

Thanks,

Randall



Follow-Ups:

Date: 2000-Oct-12 07:50
By: VizNut

Comment:
I just pulled and tested 2.0c1.  LDSHARED is not set correctly in this version either.  

This incorrect LDSHARED setting results in packages using Python's Makefile facility (PIL, DistUtils modules, etc.)  to fail when linking their shared object modules.

-------------------------------------------------------

Date: 2000-Oct-12 09:26
By: gvanrossum

Comment:
Dear VizNut (what's your real name?), I'm not unwilling to fix this, but I can't apply your patch -- that file is generated.

The curious thing is that the configure script does test for IRIX and sets LDSHARED correctly when IRIX/5* or IRIX*/6* is detected.

I wonder what went wrong???

The only thing I can think of is that somehow uname returns something else than IRIX? What is the output of uname -s? Of uname -a?
-------------------------------------------------------

Date: 2000-Oct-13 09:11
By: VizNut

Comment:
> Dear VizNut (what's your real name?), 

Hi Guido.  This is Randall Hopper.  I'm a somewhat infrequent poster to the list -- pretty busy with other things lately.  But I did want to make sure I helped test Python 2.

> I'm not unwilling to fix this, but I can't apply your patch -- that file is generated.

> The curious thing is that the configure script does test for IRIX and sets LDSHARED correctly when IRIX/5* or IRIX*/6* is detected.

> The only thing I can think of is that somehow uname returns something else than IRIX? What is the output of uname -s? Of uname -a?

Ahhh, that's it.  Thanks for explaining what it is doing.  Yes, on IRIX systems that support 64-bit addressing (all recent systems), uname -s returns "IRIX64".  On older systems, it returns "IRIX".  So when identifying IRIX, both should be accepted.

SGI should have come up with a better idea IMO, but then so should Microsoft with 64-bit Windows and "win32".

Just to be concrete, here is the output of the two command invocations you mentioned on modern SGI Octane and Onyx2 systems:

> uname -a
IRIX64 ralph 6.5 07201611 IP30
> uname -s
IRIX64

> uname -a
IRIX64 ethyl 6.5 07201611 IP27
> uname -s
IRIX64

Thanks in advance!

Randall


-------------------------------------------------------

Date: 2000-Oct-13 09:42
By: VizNut

Comment:
To help track this, I started picking through configure and references related to uname.  I found through experimentation that this variable in my Python build script environment:

setenv MACHDEP irix646

was preventing LDSHARED from being set correctly by configure.  I had been setting this with Python thus far because Python installs object files in a directory under $PREFIX with this $MACHDEP string in a directory name, and $MACHDEP is set differently based on whether this is an IRIX or an IRIX64 system, regardless of the compile architecture settings (you can compile code for IRIX on an IRIX64 system via -o32 and -n32). 

Even when building for the same architecture, generating the same object files, it would install in a different subdirectory name based on $MACHDEP on different systems.

Unsetting this variable allows LDSHARED to be set correctly.  It's a work-around for now at least.

Thanks for the help.  If you'd like, we can close this bug out.  And later if I come up with a patch to fix the "different install directory" problem (if I find it's still needed with Python2), I'll open another PR.

Thanks,

Randall





-------------------------------------------------------

Date: 2000-Oct-13 09:56
By: gvanrossum

Comment:
If I understand this correctly, it was a user error (set MACHDEP in environment).

Closing.

Thanks for your patience, Randall!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116255&group_id=5470


From noreply@sourceforge.net  Fri Oct 13 21:18:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Oct 2000 13:18:39 -0700
Subject: [Python-bugs-list] [Bug #115221] test_poll hangs on Debian Linux 2.2
Message-ID: <200010132018.NAA20752@delerium.i.sourceforge.net>

Bug #115221, was updated on 2000-Sep-24 07:38
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 4
Summary: test_poll hangs on Debian Linux 2.2

Details: When run from the command-line test_poll.py prints
"This is a test." 12 times and then hangs, without ever printing "Poll test 1 complete".

All other tests seem to work just fine.

Follow-Ups:

Date: 2000-Sep-27 10:58
By: nascheme

Comment:
I can't reproduce this on my Debian 2.2 system running Linux
 2.2.16.  Can you give the output from "uname -a" and "dpkg 
-l libc6"?  I am using libc6 2.1.3-13.
-------------------------------------------------------

Date: 2000-Oct-05 07:17
By: jhylton

Comment:
Andrew -- Is this still a problem for you?  
-------------------------------------------------------

Date: 2000-Oct-05 07:52
By: akuchling

Comment:
I don't have a Debian system to reproduce this on.

-------------------------------------------------------

Date: 2000-Oct-05 08:43
By: larsga

Comment:
I did a "cvs update", recompiled and ran the regtest again. Problem still persists.

Traceback is
Traceback (most recent call last):
  File "test_poll.py", line 171, in ?
    test_poll1()
  File "test_poll.py", line 65, in test_poll1
    poll_unit_tests()
  File "test_poll.py", line 77, in poll_unit_tests
    r = p.poll()
KeyboardInterrupt

[larsga@pc-larsga test]$ uname -a
Linux pc-larsga 2.0.36 #2 Sun Jan 17 19:38:45 EST 1999 i686 unknown
[larsga@pc-larsga test]$ dpkg -l libc6
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  libc6          2.1.3-10       GNU C Library: Shared libraries and Timezone

-------------------------------------------------------

Date: 2000-Oct-05 08:48
By: akuchling

Comment:
Interesting; Neil has libc6-2.1.3-13, while Lars has 2.1.3-10.  Presumably that last tag is a release level?

On the other hand, Neil is running a 2.2 Linux while Lars is running 2.0.36, and Neil also reported problems with
poll on a 2.0 machine.  So the finger of suspicion is pointing at the kernel...
-------------------------------------------------------

Date: 2000-Oct-07 08:43
By: twouters

Comment:
When running test_poll on the current CVS tree on RedHat 5.2 with a 2.0.36 kernel, I also get a test_poll error, though not the same one:

 This is a test.
 This is a test.
[...]
test test_poll crashed -- select.error: (9, 'Bad file descriptor')
Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 235, in runtest
    __import__(test, globals(), locals(), [])
  File "./Lib/test/test_poll.py", line 171, in ?
    test_poll1()
  File "./Lib/test/test_poll.py", line 65, in test_poll1
    poll_unit_tests()
  File "./Lib/test/test_poll.py", line 77, in poll_unit_tests
    r = p.poll()
error: (9, 'Bad file descriptor')
1 test failed: test_poll

RedHat 5.2 with a 2.2 kernel works fine. Let me know if you want me to submit a separate bugreport for the rh52-kernel2.0-poll error.

-------------------------------------------------------

Date: 2000-Oct-11 16:44
By: jhylton

Comment:
Would this patch fix the most recently reported problem?

Index: Lib/test/test_poll.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_poll.py,v
retrieving revision 1.3
diff -c -r1.3 test_poll.py
*** Lib/test/test_poll.py       2000/08/29 16:53:34     1.3
--- Lib/test/test_poll.py       2000/10/11 23:44:31
***************
*** 74,81 ****
          pass
      p = select.poll()
      p.register(FD)
!     r = p.poll()
!     assert r[0] == (FD, select.POLLNVAL)
  
      f = open(TESTFN, 'w')
      fd = f.fileno()
--- 74,87 ----
          pass
      p = select.poll()
      p.register(FD)
!     try:
!         r = p.poll()
!     except select.error, msg:
!         # old versions of Linux seem to raise an exception instead of
!         # returning POLLNVAL 
!         pass
!     else:
!         assert r[0] == (FD, select.POLLNVAL)
  
      f = open(TESTFN, 'w')
      fd = f.fileno()

-------------------------------------------------------

Date: 2000-Oct-12 08:43
By: jhylton

Comment:
Does anyone care about this bug report anymore?  Since there has been no response, I'm lowering the priority...
-------------------------------------------------------

Date: 2000-Oct-12 09:21
By: akuchling

Comment:
If the suggested patch actually fixes the test suite, I'd approve adding it.  Have any of the original respondents tried the patch?
-------------------------------------------------------

Date: 2000-Oct-13 13:18
By: larsga

Comment:
I just tried it now, and it did not fix the problem on my
Debian 2.2 system. It still hangs.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115221&group_id=5470


From noreply@sourceforge.net  Sat Oct 14 00:46:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Oct 2000 16:46:32 -0700
Subject: [Python-bugs-list] [Bug #116682] 2.0 stalls Mac on external drive
Message-ID: <200010132346.QAA28689@delerium.i.sourceforge.net>

Bug #116682, was updated on 2000-Oct-11 22:05
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: 2.0 stalls Mac on external drive

Details: Both 2.0 and 1.52 cause problems when they are on an external drive. The machine boots fine on a cold boot, but on restart the alias in the extensions folder to Python core can't find the original file as the drive is not yet mounted and so the machine doesn't get past the Happy Mac. (This is on system 8.1). Perhaps it would work better if the original was in the system folder and the alias was in the Python folder?

Follow-Ups:

Date: 2000-Oct-13 16:46
By: jackjansen

Comment:
Various SIG users have tried to repeat this bug, but without success. However, as there are other problems with having the alias for PythonCore pointing to a different partition than the system disk (people have reported their applets not working, or working intermittently) the installer now detects this situation and offers to copy PythonCore in stead of aliasing it. That solution should fix this problem too.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116682&group_id=5470


From noreply@sourceforge.net  Sat Oct 14 00:55:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Oct 2000 16:55:08 -0700
Subject: [Python-bugs-list] [Bug #116850] Bad comment in Setup.in
Message-ID: <200010132355.QAA29025@delerium.i.sourceforge.net>

Bug #116850, was updated on 2000-Oct-13 16:55
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Bad comment in Setup.in

Details: Setup.in has this in it:

# (See http://www.jenkon-dev.com/~rd/python/ for an interface to
# BSD DB 2.1.0.)

which is incorrect.  (The server hasn't even existed for about 3 years!) If
you want to give a pointer to a web site you could use this one:

      http://electricrain.com/greg/python/bsddb3/

But it might be better to just remove it all together...



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116850&group_id=5470


From noreply@sourceforge.net  Sat Oct 14 02:43:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Oct 2000 18:43:14 -0700
Subject: [Python-bugs-list] [Bug #115900] difference between pre and sre for buggy expressions
Message-ID: <200010140143.SAA00366@delerium.i.sourceforge.net>

Bug #115900, was updated on 2000-Oct-03 03:11
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: difference between pre and sre for buggy expressions

Details: def check_pattern(pattern):
    import pre, sre

    pre_version = pre.compile(pattern)

    print pre_version.match('-1234a')
    print pre_version.match(' 1234a')

    sre_version = sre.compile(pattern)

    print sre_version.match('-1234a')
    print sre_version.match(' 1234a')

# This is a buggy re: It is trying to match a minus sign as part of a
# set of characters, but does not follow the documented rule of
# "precede it with a backslash, or place it as the first character"
# However, pre and sre behave differently, and neither behaviour is
# quite what I was expecting. Is this a hint of a bug?
check_pattern('([\s-])(\.?)'  + r'([HLEr0123456789\s-])(\.?)'*4 +r'([abcd]?)')

# Preceeding them with a backslash makes pre and sre behave identically.
check_pattern('([\s\-])(\.?)'  + r'([HLEr0123456789\s\-])(\.?)'*4 +r'([abcd]?)')


Follow-Ups:

Date: 2000-Oct-13 18:43
By: jdnier

Comment:
I've also run into a few bogus regexes that sre (NT4; python 2.0c1) swallows but pre doesn't. These patterns are contrived but typos happen and without a compile traceback the problem can be hard to discover. Just run C:\Python20\Tools\Scripts\redemo.py, give it a string to search like "aaaaaabbb" and enter, for example,

(?
(?)
a+??    <-shouldn't this raise 'nothing to repeat' error?
            It matches a single 'a'; the second '?' is ignored
a+???   <-this matches the null string
a+????  <-this finally errors "nothing to repeat"
a???????????   <-never errors; matches null string
a++++++++   <-never errors; matches same as a+

It's the "matches the null string" part that seems evil, even if you allow sre to be more permissive and not complain about the regex syntax errors. Also, a* and permutations seem to work as expected, so it looks like something is up with + and ? in particular.

Other novelties...

a?+?
a????+?
a?????+
a+???
a(?)????????????b


-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115900&group_id=5470


From noreply@sourceforge.net  Sat Oct 14 05:15:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 13 Oct 2000 21:15:44 -0700
Subject: [Python-bugs-list] [Bug #116850] Bad comment in Setup.in
Message-ID: <200010140415.VAA05678@delerium.i.sourceforge.net>

Bug #116850, was updated on 2000-Oct-13 16:55
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: Bad comment in Setup.in

Details: Setup.in has this in it:

# (See http://www.jenkon-dev.com/~rd/python/ for an interface to
# BSD DB 2.1.0.)

which is incorrect.  (The server hasn't even existed for about 3 years!) If
you want to give a pointer to a web site you could use this one:

      http://electricrain.com/greg/python/bsddb3/

But it might be better to just remove it all together...



Follow-Ups:

Date: 2000-Oct-13 21:15
By: fdrake

Comment:
Updated Modules/Setup.in, revision 1.112.

I decided to use the updated link; some people will want to use DB 3, and locating stuff is still hard enough we want to help where we can.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116850&group_id=5470


From noreply@sourceforge.net  Sat Oct 14 16:55:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 14 Oct 2000 08:55:35 -0700
Subject: [Python-bugs-list] [Bug #116872] 2.0c1 can't "import string" ?!
Message-ID: <200010141555.IAA26252@bush.i.sourceforge.net>

Bug #116872, was updated on 2000-Oct-14 08:55
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 2.0c1 can't "import string" ?!

Details: Win98, 2.0c1 just installed.
D:\Python20>python
Python 2.0c1 (#7, Oct  9 2000, 18:44:43) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import string
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "d:\python20\lib\string.py", line 191, in ?
    _StringType = type('')
SystemError: new style getargs format but argument is not a tuple
>>>

??? an installation problem, maybe... ???  What COULD
it ever be...???  Does make the system near-unusable
(IDLE can't start, etc).


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116872&group_id=5470


From noreply@sourceforge.net  Sat Oct 14 17:41:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 14 Oct 2000 09:41:31 -0700
Subject: [Python-bugs-list] [Bug #116872] 2.0c1 can't "import string" ?!
Message-ID: <200010141641.JAA27902@bush.i.sourceforge.net>

Bug #116872, was updated on 2000-Oct-14 08:55
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 2.0c1 can't "import string" ?!

Details: Win98, 2.0c1 just installed.
D:\Python20>python
Python 2.0c1 (#7, Oct  9 2000, 18:44:43) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import string
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "d:\python20\lib\string.py", line 191, in ?
    _StringType = type('')
SystemError: new style getargs format but argument is not a tuple
>>>

??? an installation problem, maybe... ???  What COULD
it ever be...???  Does make the system near-unusable
(IDLE can't start, etc).


Follow-Ups:

Date: 2000-Oct-14 09:41
By: aleax

Comment:
Problem disappears when uninstalling everything
Python-related, rebooting, and reinstalling; so,
it must have been an installation problem.  Still
curious as to what exactly could have caused it,
but, clearly, no urgency.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116872&group_id=5470


From noreply@sourceforge.net  Sun Oct 15 15:06:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 15 Oct 2000 07:06:17 -0700
Subject: [Python-bugs-list] [Bug #116678] minidom doesn't raise exception for illegal children
Message-ID: <200010151406.HAA08582@bush.i.sourceforge.net>

Bug #116678, was updated on 2000-Oct-11 19:30
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: minidom doesn't raise exception for illegal children

Details: Some types of DOM node such as Text can't have children.
minidom doesn't check for this at all:

from xml.dom import minidom
doc = minidom.Document()
text = doc.createTextNode('lorem ipsum')
elem = doc.createElement('leaf')
text.appendChild( elem )
print text.toxml()

This outputs just 'lorem ipsum', but elem really is a child 
of text; Text.toxml() just isn't recursing because it doesn't expect to do so.



Follow-Ups:

Date: 2000-Oct-12 20:02
By: fdrake

Comment:
This is a bug with detecting an improper use.  It should be fixed, but need not be for Python 2.0.  Correct use will not produce erroneous behavior.  Reducing priority by one.
-------------------------------------------------------

Date: 2000-Oct-15 07:06
By: loewis

Comment:
I believe this is not a bug, but an intended deviation from the DOM spec.
minidom (as the proposed documentation in patch 101821 explains) does
not support the IDL exceptions of module DOM, so it cannot report errors about improper usage.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116678&group_id=5470


From noreply@sourceforge.net  Sun Oct 15 17:47:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 15 Oct 2000 09:47:13 -0700
Subject: [Python-bugs-list] [Bug #116289] Programs using Tkinter sometimes can't shut down
Message-ID: <200010151647.JAA17626@delerium.i.sourceforge.net>

Bug #116289, was updated on 2000-Oct-06 19:25
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: Programs using Tkinter sometimes can't shut down

Details: The following msg from the Tutor list is about 1.6, but I noticed the same thing several times today using 2.0b2+CVS.  In my case, I was running IDLE via

python ../tool/idle/idle.pyw

from a DOS box in my PCbuild directory.  Win98SE.  *Most* of the time, shutting down IDLE via Ctrl+Q left the DOS box hanging.  As with the poster, the only way to regain control was to use the Task Manager to kill off Winoldap.

-----Original Message-----
From: Joseph Stubenrauch <nothingisgoingtochangemyworld@yahoo.com>
Sent: Friday, October 06, 2000 9:23 PM
To: tutor@python.org
Subject: Re: [Tutor] Python 1.6 BUG


Strange, I have been experiencing the same bug myself.
Here's the low down for me:

Python 1.6 with win95
I am running a little Tkinter program
The command line I use is simply: "python foo.py"
About 25-35% of the time, when I close the Tkinter
window, DOS seems to "freeze" and never returns to the
c:\ command prompt.  I have to ctrl-alt-delete
repeatedly and shut down "winoldapp" to get rid of the
window and then shell back into DOS and keep working.
It's a bit of a pain, since I have the habit of
testing EVERYTHING in tiny little stages, so I change
one little thing, test it ... freeze ... ARGH!  Change
one more tiny thing, test it ... freeze ... ARGH! 
However, sometimes it seems to behave and doesn't
bother me for an entire several hour session of python
work.

That's my report on the problem.

Cheers,

Joe


Follow-Ups:

Date: 2000-Oct-07 00:37
By: tim_one

Comment:
More info (none good, but some worse so boosted priority):

+ Happens under release and debug builds.

+ Have not been able to provoke when starting in the debugger.

+ Ctrl+Alt+Del and killing Winoldap is not enough to clean everything up.  There's still a Python (or Python_d) process hanging around that Ctrl+Alt+Del doesn't show.

+ This process makes it impossible to delete the associated Python .dll, and in particular makes it impossible to rebuild Python successfully without a reboot.

+ These processes cannot be killed!  Wintop and Process Viewer both fail to get the job done.  PrcView (a freeware process viewer) itself locks up if I try to kill them using it.  Process Viewer freezes for several seconds before giving up.

+ Attempting to attach to the process with the MSVC debugger (in order to find out what the heck it's doing) finds the process OK, but then yields the cryptic and undocumented error msg "Cannot execute program".

+ The processes are not accumulating cycles.

+ Smells like deadlock.
-------------------------------------------------------

Date: 2000-Oct-12 10:25
By: gvanrossum

Comment:
The recent fix to _tkinter (Tcl_GetStringResult(interp) instead of interp->result) didn't fix this either.

As Tim has remarked in private but not yet recorded here, a workaround is to use pythonw instead of python, so I'm lowering thepriority again.

Also note that the hanging process that Tim writes about apparently prevents Win98 from shutting down properly.
-------------------------------------------------------

Date: 2000-Oct-13 07:40
By: gvanrossum

Comment:
Back to Tim since I have no clue what to do here.
-------------------------------------------------------

Date: 2000-Oct-15 09:47
By: none

Comment:
Same as I've reported earlier; it hangs in the call to
Tcl_Finalize (which is called by the DLL finalization
code).  It's less likely to hang if I call Tcl_Finalize
from the _tkinter DLL (from user code).

Note that the problem isn't really Python-related -- I
have stand-alone samples (based on wish) that hangs in
the same way.

More later.

</F>
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116289&group_id=5470


From noreply@sourceforge.net  Mon Oct 16 02:53:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 15 Oct 2000 18:53:18 -0700
Subject: [Python-bugs-list] [Bug #116872] 2.0c1 can't "import string" ?!
Message-ID: <200010160153.SAA05172@delerium.i.sourceforge.net>

Bug #116872, was updated on 2000-Oct-14 08:55
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Invalid
Bug Group: None
Priority: 5
Summary: 2.0c1 can't "import string" ?!

Details: Win98, 2.0c1 just installed.
D:\Python20>python
Python 2.0c1 (#7, Oct  9 2000, 18:44:43) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import string
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "d:\python20\lib\string.py", line 191, in ?
    _StringType = type('')
SystemError: new style getargs format but argument is not a tuple
>>>

??? an installation problem, maybe... ???  What COULD
it ever be...???  Does make the system near-unusable
(IDLE can't start, etc).


Follow-Ups:

Date: 2000-Oct-14 09:41
By: aleax

Comment:
Problem disappears when uninstalling everything
Python-related, rebooting, and reinstalling; so,
it must have been an installation problem.  Still
curious as to what exactly could have caused it,
but, clearly, no urgency.
-------------------------------------------------------

Date: 2000-Oct-15 18:53
By: tim_one

Comment:
Marked Closed & Invalid:  it's a unique (never reported before or after) one-shot that went away after reinstalling.  There's nothing reproducible here for anyone to look at.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116872&group_id=5470


From noreply@sourceforge.net  Mon Oct 16 08:06:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 16 Oct 2000 00:06:13 -0700
Subject: [Python-bugs-list] [Bug #116964] gettext may fail to find .mo file
Message-ID: <200010160706.AAA12814@bush.i.sourceforge.net>

Bug #116964, was updated on 2000-Oct-16 00:06
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: gettext may fail to find .mo file

Details: Ulf Betlehem <flu@iki.fi> wrote to me:

        ok, I compiled 2.0c1 and tried gettext. Now, there seems to be
        a bug in the "normalize and expand" code that can prevent
        gettext from finding an existing .mo file. The normalization
        is done using a dictionary and therefore the languages get
        reordered (as dict keys do). Later when selecting language the
        function returns None if 'C' happens to come before the
        required languages. I've included a patch to fix this.

I will enter Ulf's patch into the patch manager ASAP.
Regards, PeFu

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116964&group_id=5470


From noreply@sourceforge.net  Mon Oct 16 08:18:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 16 Oct 2000 00:18:17 -0700
Subject: [Python-bugs-list] [Bug #116964] gettext may fail to find .mo file
Message-ID: <200010160718.AAA13272@bush.i.sourceforge.net>

Bug #116964, was updated on 2000-Oct-16 00:06
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: gettext may fail to find .mo file

Details: Ulf Betlehem <flu@iki.fi> wrote to me:

        ok, I compiled 2.0c1 and tried gettext. Now, there seems to be
        a bug in the "normalize and expand" code that can prevent
        gettext from finding an existing .mo file. The normalization
        is done using a dictionary and therefore the languages get
        reordered (as dict keys do). Later when selecting language the
        function returns None if 'C' happens to come before the
        required languages. I've included a patch to fix this.

I will enter Ulf's patch into the patch manager ASAP.
Regards, PeFu

Follow-Ups:

Date: 2000-Oct-16 00:18
By: PeFu

Comment:
Patch #101928 should fix this bug.
This patch was also prepared by Ulf Betlehem.  Thank you Ulf!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116964&group_id=5470


From noreply@sourceforge.net  Mon Oct 16 08:43:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 16 Oct 2000 00:43:58 -0700
Subject: [Python-bugs-list] [Bug #116677] minidom:Node.appendChild() has wrong semantics
Message-ID: <200010160743.AAA14176@bush.i.sourceforge.net>

Bug #116677, was updated on 2000-Oct-11 19:24
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: minidom:Node.appendChild() has wrong semantics

Details: Consider this test program:

from xml.dom import minidom
doc = minidom.Document()
root = doc.createElement('root') ; doc.appendChild( root )

elem = doc.createElement('leaf')
root.appendChild( elem )
root.appendChild( elem )

print doc.toxml()
print root.childNodes

It prints:
<root><leaf/><leaf/></root>
[<DOM Element: leaf at 135586476>, <DOM Element: leaf at 135586476>]

'elem' is now linked into the DOM tree in two places, which is wrong; according to the DOM Level 1 spec, 
"If the newChild is already in the tree, it is first removed."



Follow-Ups:

Date: 2000-Oct-11 19:55
By: fdrake

Comment:
Andrew:  Are you using 2.0c1 or CVS?
-------------------------------------------------------

Date: 2000-Oct-11 20:11
By: akuchling

Comment:
CVS as of this evening.  Did it work before?

(Hmm... tonight test_minidom is failing for me for some reason.  
Wonder if it's related?)
-------------------------------------------------------

Date: 2000-Oct-12 07:37
By: none

Comment:
The test_minidom failure turned out to be caused by something else.  However, I rechecked my test case and it's still broken with tonight's CVS.
-------------------------------------------------------

Date: 2000-Oct-16 00:43
By: loewis

Comment:
This is indeed a bug in minidom, but I don't think it should be corrected for 2.0; I suggest to reduce the priority of it, or close it as "later".

While this is a deviation from the DOM spec, it seems as a border case. As such, it should be documented; users can always explicitly remove the node before appending it elsewhere.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116677&group_id=5470


From noreply@sourceforge.net  Mon Oct 16 14:47:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 16 Oct 2000 06:47:57 -0700
Subject: [Python-bugs-list] [Bug #116677] minidom:Node.appendChild() has wrong semantics
Message-ID: <200010161347.GAA31258@delerium.i.sourceforge.net>

Bug #116677, was updated on 2000-Oct-11 19:24
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: minidom:Node.appendChild() has wrong semantics

Details: Consider this test program:

from xml.dom import minidom
doc = minidom.Document()
root = doc.createElement('root') ; doc.appendChild( root )

elem = doc.createElement('leaf')
root.appendChild( elem )
root.appendChild( elem )

print doc.toxml()
print root.childNodes

It prints:
<root><leaf/><leaf/></root>
[<DOM Element: leaf at 135586476>, <DOM Element: leaf at 135586476>]

'elem' is now linked into the DOM tree in two places, which is wrong; according to the DOM Level 1 spec, 
"If the newChild is already in the tree, it is first removed."



Follow-Ups:

Date: 2000-Oct-11 19:55
By: fdrake

Comment:
Andrew:  Are you using 2.0c1 or CVS?
-------------------------------------------------------

Date: 2000-Oct-11 20:11
By: akuchling

Comment:
CVS as of this evening.  Did it work before?

(Hmm... tonight test_minidom is failing for me for some reason.  
Wonder if it's related?)
-------------------------------------------------------

Date: 2000-Oct-12 07:37
By: none

Comment:
The test_minidom failure turned out to be caused by something else.  However, I rechecked my test case and it's still broken with tonight's CVS.
-------------------------------------------------------

Date: 2000-Oct-16 00:43
By: loewis

Comment:
This is indeed a bug in minidom, but I don't think it should be corrected for 2.0; I suggest to reduce the priority of it, or close it as "later".

While this is a deviation from the DOM spec, it seems as a border case. As such, it should be documented; users can always explicitly remove the node before appending it elsewhere.
-------------------------------------------------------

Date: 2000-Oct-16 06:47
By: akuchling

Comment:
I don't see why this particular deviation is a border case.
All the methods for modifying a DOM tree -- appendChild(),
insertBefore(), replaceChild() -- all behave the same way,
first removing the added node if it's already in the tree somewhere.  This will make it more difficult to translate DOM-using code from, say, Java, to Python + minidom, since you'll have to remember to add extra .removeChild() calls.
Worse still, the problems caused by this will be hard to track down; portions of your DOM tree are aliased, but .toxml() won't make this clear.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116677&group_id=5470


From noreply@sourceforge.net  Mon Oct 16 16:11:23 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 16 Oct 2000 08:11:23 -0700
Subject: [Python-bugs-list] [Bug #117004] Tools/compiler does not create doc strings
Message-ID: <200010161511.IAA02318@delerium.i.sourceforge.net>

Bug #117004, was updated on 2000-Oct-16 08:11
Here is a current snapshot of the bug.

Project: Python
Category: demos and tools
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Tools/compiler does not create doc strings

Details: Transformer.get_docstring() seems to be working fine but the __doc__ attributes are always None in the compiled code.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117004&group_id=5470


From noreply@sourceforge.net  Mon Oct 16 16:11:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 16 Oct 2000 08:11:59 -0700
Subject: [Python-bugs-list] [Bug #117004] Tools/compiler does not create doc strings
Message-ID: <200010161511.IAA02324@delerium.i.sourceforge.net>

Bug #117004, was updated on 2000-Oct-16 08:11
Here is a current snapshot of the bug.

Project: Python
Category: demos and tools
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: Tools/compiler does not create doc strings

Details: Transformer.get_docstring() seems to be working fine but the __doc__ attributes are always None in the compiled code.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117004&group_id=5470


From noreply@sourceforge.net  Mon Oct 16 16:45:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 16 Oct 2000 08:45:52 -0700
Subject: [Python-bugs-list] [Bug #116964] gettext may fail to find .mo file
Message-ID: <200010161545.IAA03761@delerium.i.sourceforge.net>

Bug #116964, was updated on 2000-Oct-16 00:06
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: gettext may fail to find .mo file

Details: Ulf Betlehem <flu@iki.fi> wrote to me:

        ok, I compiled 2.0c1 and tried gettext. Now, there seems to be
        a bug in the "normalize and expand" code that can prevent
        gettext from finding an existing .mo file. The normalization
        is done using a dictionary and therefore the languages get
        reordered (as dict keys do). Later when selecting language the
        function returns None if 'C' happens to come before the
        required languages. I've included a patch to fix this.

I will enter Ulf's patch into the patch manager ASAP.
Regards, PeFu

Follow-Ups:

Date: 2000-Oct-16 00:18
By: PeFu

Comment:
Patch #101928 should fix this bug.
This patch was also prepared by Ulf Betlehem.  Thank you Ulf!
-------------------------------------------------------

Date: 2000-Oct-16 08:45
By: bwarsaw

Comment:
Fixed by application of (approximately) patch #101928 in revision gettext.py 1.9.  Made it into Python 2.0
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116964&group_id=5470


From noreply@sourceforge.net  Mon Oct 16 21:20:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 16 Oct 2000 13:20:10 -0700
Subject: [Python-bugs-list] [Bug #117028] Installation fails if prefix directory does not exist.
Message-ID: <200010162020.NAA11368@bush.i.sourceforge.net>

Bug #117028, was updated on 2000-Oct-16 13:20
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Installation fails if prefix directory does not exist.

Details: I just downloaded and installed Python-2.0c1. I configured with :

bash% ./configure --prefix=/local/python/python-2.0c1

The directory /local/python/python-2.0c1 did not exist. The install program did not offer to make this directory, and hence make install failed.

I have made a fix for this (I'd be overjoyed if you would consider using it!).

bash% diff -Naur Makefile.in.new Makefile.in.old :
--- Makefile.in.new	Mon Oct 16 22:10:23 2000
+++ Makefile.in.old	Mon Oct 16 22:06:53 2000
@@ -102,7 +102,6 @@
 INSTALL=	@srcdir@/install-sh -c
 INSTALL_PROGRAM=${INSTALL} -m $(EXEMODE)
 INSTALL_DATA=	${INSTALL} -m $(FILEMODE)
-INSTALL_DIR=    @srcdir@/install-sh -d -m $(DIRMODE)
 
 # Use this to make a link between python$(VERSION) and python in $(BINDIR)
 LN=@LN@
@@ -218,12 +217,7 @@
 		PYTHONPATH= $(TESTPYTHON) $(TESTPROG) $(TESTOPTS)
 
 # Install everything
-install:	prefixdir altinstall bininstall maninstall
-
-# Make the prefixdir if it does not already exist - logic handled by the install-sh script
-prefixdir:
-		$(INSTALL_DIR) @prefix@
-		$(INSTALL_DIR) @exec_prefix@
+install:	altinstall bininstall maninstall
 
 # Install almost everything without disturbing previous versions
 altinstall:	altbininstall libinstall inclinstall libainstall sharedinstall


bash% diff -Naur install-sh.new install-sh.old:
--- install-sh.new	Mon Oct 16 21:44:30 2000
+++ install-sh.old	Thu Aug 13 18:08:45 1998
@@ -43,10 +43,6 @@
 	    shift
 	    continue;;
 
-	-d) instcmd="mkdir"
-	    shift
-	    continue;;
-
 	-m) chmodcmd="$chmodprog $2"
 	    shift
 	    shift
@@ -83,31 +79,10 @@
 	exit 1
 fi
 
-
-if [ "$instcmd" = "mkdir" ]
-then
-    dirlist=`echo $src | sed 's/\// /g'`
-    cd /;
-    currentdir="/"
-    for dir in $dirlist 
-    do
-	currentdir="$currentdir$dir"
-	if [ ! -d "$dir" ] 
-	then
-	    echo "Creating directory "$currentdir
-	    mkdir $dir
-	    $chmodcmd $dir
-	fi
-	cd $dir
-	currentdir="$currentdir/"
-    done
-    exit 0
-fi
-
-
 if [ x"$dst" = x ]
 then
 	echo "install:  no destination specified"
+	exit 1
 fi
 
 
@@ -143,4 +118,3 @@
 
 
 exit 0
-


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117028&group_id=5470


From noreply@sourceforge.net  Mon Oct 16 21:39:15 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 16 Oct 2000 13:39:15 -0700
Subject: [Python-bugs-list] [Bug #117028] Installation fails if prefix directory does not exist.
Message-ID: <200010162039.NAA15890@delerium.i.sourceforge.net>

Bug #117028, was updated on 2000-Oct-16 13:20
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Installation fails if prefix directory does not exist.

Details: I just downloaded and installed Python-2.0c1. I configured with :

bash% ./configure --prefix=/local/python/python-2.0c1

The directory /local/python/python-2.0c1 did not exist. The install program did not offer to make this directory, and hence make install failed.

I have made a fix for this (I'd be overjoyed if you would consider using it!).

bash% diff -Naur Makefile.in.new Makefile.in.old :
--- Makefile.in.new	Mon Oct 16 22:10:23 2000
+++ Makefile.in.old	Mon Oct 16 22:06:53 2000
@@ -102,7 +102,6 @@
 INSTALL=	@srcdir@/install-sh -c
 INSTALL_PROGRAM=${INSTALL} -m $(EXEMODE)
 INSTALL_DATA=	${INSTALL} -m $(FILEMODE)
-INSTALL_DIR=    @srcdir@/install-sh -d -m $(DIRMODE)
 
 # Use this to make a link between python$(VERSION) and python in $(BINDIR)
 LN=@LN@
@@ -218,12 +217,7 @@
 		PYTHONPATH= $(TESTPYTHON) $(TESTPROG) $(TESTOPTS)
 
 # Install everything
-install:	prefixdir altinstall bininstall maninstall
-
-# Make the prefixdir if it does not already exist - logic handled by the install-sh script
-prefixdir:
-		$(INSTALL_DIR) @prefix@
-		$(INSTALL_DIR) @exec_prefix@
+install:	altinstall bininstall maninstall
 
 # Install almost everything without disturbing previous versions
 altinstall:	altbininstall libinstall inclinstall libainstall sharedinstall


bash% diff -Naur install-sh.new install-sh.old:
--- install-sh.new	Mon Oct 16 21:44:30 2000
+++ install-sh.old	Thu Aug 13 18:08:45 1998
@@ -43,10 +43,6 @@
 	    shift
 	    continue;;
 
-	-d) instcmd="mkdir"
-	    shift
-	    continue;;
-
 	-m) chmodcmd="$chmodprog $2"
 	    shift
 	    shift
@@ -83,31 +79,10 @@
 	exit 1
 fi
 
-
-if [ "$instcmd" = "mkdir" ]
-then
-    dirlist=`echo $src | sed 's/\// /g'`
-    cd /;
-    currentdir="/"
-    for dir in $dirlist 
-    do
-	currentdir="$currentdir$dir"
-	if [ ! -d "$dir" ] 
-	then
-	    echo "Creating directory "$currentdir
-	    mkdir $dir
-	    $chmodcmd $dir
-	fi
-	cd $dir
-	currentdir="$currentdir/"
-    done
-    exit 0
-fi
-
-
 if [ x"$dst" = x ]
 then
 	echo "install:  no destination specified"
+	exit 1
 fi
 
 
@@ -143,4 +118,3 @@
 
 
 exit 0
-


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117028&group_id=5470


From noreply@sourceforge.net  Mon Oct 16 21:45:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 16 Oct 2000 13:45:10 -0700
Subject: [Python-bugs-list] [Bug #117032] test_fcntl should not use /tmp/delete-me
Message-ID: <200010162045.NAA16110@delerium.i.sourceforge.net>

Bug #117032, was updated on 2000-Oct-16 13:45
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 2
Summary: test_fcntl should not use /tmp/delete-me

Details: This test should be updated to use test_support.TESTFN.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117032&group_id=5470


From noreply@sourceforge.net  Tue Oct 17 10:54:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Oct 2000 02:54:10 -0700
Subject: [Python-bugs-list] [Bug #117070] README instructions for configuring Setup are not helpful
Message-ID: <200010170954.CAA08667@bush.i.sourceforge.net>

Bug #117070, was updated on 2000-Oct-17 02:54
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: README instructions for configuring Setup are not helpful

Details: The instructions in the README file for configuring the Setup file are not useful. There is no indication of when you are supposed to edit the file. So far as I can tell the only way to configure python is either:

  ./configure
  make
  vim Modules/Setup
  make

or:

  ./configure
  vim Modules/Setup.in
  make

neither of which are particularly satisfactory.

The README file simply says "if [the Setup file] does not exist yet, make a copy yourself", without any indication of how you actually do this. 'make Setup' in the Modules directory does not work because there is no Makefile in the Modules directory yet.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117070&group_id=5470


From noreply@sourceforge.net  Tue Oct 17 15:18:02 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Oct 2000 07:18:02 -0700
Subject: [Python-bugs-list] [Bug #110682] pdb can only step when at botframe (PR#4)
Message-ID: <200010171418.HAA19029@bush.i.sourceforge.net>

Bug #110682, was updated on 2000-Jul-31 14:14
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: Later
Bug Group: None
Priority: 3
Summary: pdb can only step when at botframe (PR#4)

Details: Jitterbug-Id: 4
Submitted-By: MHammond@skippinet.com.au
Date: Mon, 12 Jul 1999 15:38:43 -0400 (EDT)
Version: 1.5.2
OS: Windows


[Resubmitted by GvR]

It is a problem that bugged me for _ages_.  Since the years I first wrote
the Pythonwin debugger Ive learnt alot about how it works :-)

The problem is simply:  when the frame being debugged is self.botframe, it
is impossible to continue - only "step" works.  A "continue" command
functions as a step until you start debugging a frame below self.botframe.

It is less of a problem with pdb, but makes a GUI debugger clunky - if you
start a debug session by stepping into a module, the "go" command seems
broken.

The simplest way to demonstrate the problem is to create a module, and add
a "pdb.set_trace()" statement at the top_level (ie, at indent level 0).
You will not be able to "continue" until you enter a function.

My solution was this:  instead of run() calling "exec" directly, it calls
another internal function.  This internal function contains a single line -
the "exec", and therefore never needs to be debugged directly.  Then
stop_here is modified accordingly.

The end result is that "self.botframe" becomes an "intermediate" frame, and
is never actually stopped at - ie, self.botframe effectivly becomes one
frame _below_ the bottom frame the user is interested in.

Im not yet trying to propose a patch, just to discuss this and see if the
"right thing" can be determined and put into pdb.

Thanks,

Mark.




====================================================================
Audit trail:
Mon Jul 12 15:39:35 1999	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Oct-17 07:18
By: none

Comment:
My common workaround is to always create a function called debug(): that calls the function in the module I am debugging.  Instead of doing a runcall for my function I do a runcall on debug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110682&group_id=5470


From noreply@sourceforge.net  Tue Oct 17 15:19:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Oct 2000 07:19:08 -0700
Subject: [Python-bugs-list] [Bug #110682] pdb can only step when at botframe (PR#4)
Message-ID: <200010171419.HAA19067@bush.i.sourceforge.net>

Bug #110682, was updated on 2000-Jul-31 14:14
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: Later
Bug Group: None
Priority: 3
Summary: pdb can only step when at botframe (PR#4)

Details: Jitterbug-Id: 4
Submitted-By: MHammond@skippinet.com.au
Date: Mon, 12 Jul 1999 15:38:43 -0400 (EDT)
Version: 1.5.2
OS: Windows


[Resubmitted by GvR]

It is a problem that bugged me for _ages_.  Since the years I first wrote
the Pythonwin debugger Ive learnt alot about how it works :-)

The problem is simply:  when the frame being debugged is self.botframe, it
is impossible to continue - only "step" works.  A "continue" command
functions as a step until you start debugging a frame below self.botframe.

It is less of a problem with pdb, but makes a GUI debugger clunky - if you
start a debug session by stepping into a module, the "go" command seems
broken.

The simplest way to demonstrate the problem is to create a module, and add
a "pdb.set_trace()" statement at the top_level (ie, at indent level 0).
You will not be able to "continue" until you enter a function.

My solution was this:  instead of run() calling "exec" directly, it calls
another internal function.  This internal function contains a single line -
the "exec", and therefore never needs to be debugged directly.  Then
stop_here is modified accordingly.

The end result is that "self.botframe" becomes an "intermediate" frame, and
is never actually stopped at - ie, self.botframe effectivly becomes one
frame _below_ the bottom frame the user is interested in.

Im not yet trying to propose a patch, just to discuss this and see if the
"right thing" can be determined and put into pdb.

Thanks,

Mark.




====================================================================
Audit trail:
Mon Jul 12 15:39:35 1999	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Oct-17 07:18
By: none

Comment:
My common workaround is to always create a function called debug(): that calls the function in the module I am debugging.  Instead of doing a runcall for my function I do a runcall on debug.
-------------------------------------------------------

Date: 2000-Oct-17 07:19
By: none

Comment:
Sorry I forgot to sigh the comment for 2000-Oct-17 07:18
David Hurt
davehurt@flash.net
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110682&group_id=5470


From noreply@sourceforge.net  Tue Oct 17 16:55:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Oct 2000 08:55:11 -0700
Subject: [Python-bugs-list] [Bug #117090] PIL (TkImaging) extension instructions wrong
Message-ID: <200010171555.IAA23227@bush.i.sourceforge.net>

Bug #117090, was updated on 2000-Oct-17 08:55
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: PIL (TkImaging) extension instructions wrong

Details: Modules/Setup.in contains:
# *** Uncomment and edit for PIL (TkImaging) extension only:
#       -DWITH_PIL -I../Extensions/Imaging/libImaging tkImaging.c \

However, there is no directory 'Extensions' or any source
file tkImaging.c

Either these instructions should be removed from Setup.in, or tkImaging.c should be added to the distribution, or instructions should be added where to find tkImaging.c and
the associated imaging libraries.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117090&group_id=5470


From noreply@sourceforge.net  Tue Oct 17 16:59:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Oct 2000 08:59:39 -0700
Subject: [Python-bugs-list] [Bug #117092] Testsuite dumps core on Win2000 / IDLE
Message-ID: <200010171559.IAA26573@delerium.i.sourceforge.net>

Bug #117092, was updated on 2000-Oct-17 08:59
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Testsuite dumps core on Win2000 / IDLE

Details: On a fresh installation of Python2.0 under Win2k, when running test.testall I get an "ApplicationError". The last test output is:

test_array
*****************************
array after append: <--[ApplicationError dialog appears]


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117092&group_id=5470


From noreply@sourceforge.net  Tue Oct 17 22:08:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Oct 2000 14:08:31 -0700
Subject: [Python-bugs-list] [Bug #117109] Compilation Fails if LONG_BIT != 8*SIZEOF_LONG
Message-ID: <200010172108.OAA03434@bush.i.sourceforge.net>

Bug #117109, was updated on 2000-Oct-17 14:08
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Compilation Fails if LONG_BIT != 8*SIZEOF_LONG

Details: I encountered this problem building Python 2.0 (final release) on a Linux 2.2.17 system (Intel), using libc6 2.95.-1 (Debian distribution).

I don't know what other information to provide, so please let me know I can be of any further assistance.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117109&group_id=5470


From noreply@sourceforge.net  Tue Oct 17 22:12:41 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Oct 2000 14:12:41 -0700
Subject: [Python-bugs-list] [Bug #117109] Compilation Fails if LONG_BIT != 8*SIZEOF_LONG
Message-ID: <200010172112.OAA03641@bush.i.sourceforge.net>

Bug #117109, was updated on 2000-Oct-17 14:08
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Compilation Fails if LONG_BIT != 8*SIZEOF_LONG

Details: I encountered this problem building Python 2.0 (final release) on a Linux 2.2.17 system (Intel), using libc6 2.95.-1 (Debian distribution).

I don't know what other information to provide, so please let me know I can be of any further assistance.

Follow-Ups:

Date: 2000-Oct-17 14:12
By: dhruvar

Comment:
The error occurs in pyport.h, around here

#if LONG_BIT != 8 * SIZEOF_LONG
/* 04-Oct-2000 LONG_BIT is apparently (mis)defined as 64 on some recent
 * 32-bit platforms using gcc.  We try to catch that here at compile-time
 * rather than waiting for integer multiplication to trigger bogus
 * overflows.
 */
#error "LONG_BIT definition appears wrong for platform (bad gcc config?)."
#endif

The condition evaluates to true on my system, and therefore the build fails.  I was able to work around this by undefining LONG_BIT just before it is tested on line 380.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117109&group_id=5470


From noreply@sourceforge.net  Tue Oct 17 23:32:36 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Oct 2000 15:32:36 -0700
Subject: [Python-bugs-list] [Bug #117109] Compilation Fails if LONG_BIT != 8*SIZEOF_LONG
Message-ID: <200010172232.PAA10248@delerium.i.sourceforge.net>

Bug #117109, was updated on 2000-Oct-17 14:08
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Closed
Resolution: None
Bug Group: 3rd Party
Priority: 5
Summary: Compilation Fails if LONG_BIT != 8*SIZEOF_LONG

Details: I encountered this problem building Python 2.0 (final release) on a Linux 2.2.17 system (Intel), using libc6 2.95.-1 (Debian distribution).

I don't know what other information to provide, so please let me know I can be of any further assistance.

Follow-Ups:

Date: 2000-Oct-17 14:12
By: dhruvar

Comment:
The error occurs in pyport.h, around here

#if LONG_BIT != 8 * SIZEOF_LONG
/* 04-Oct-2000 LONG_BIT is apparently (mis)defined as 64 on some recent
 * 32-bit platforms using gcc.  We try to catch that here at compile-time
 * rather than waiting for integer multiplication to trigger bogus
 * overflows.
 */
#error "LONG_BIT definition appears wrong for platform (bad gcc config?)."
#endif

The condition evaluates to true on my system, and therefore the build fails.  I was able to work around this by undefining LONG_BIT just before it is tested on line 380.
-------------------------------------------------------

Date: 2000-Oct-17 15:32
By: gvanrossum

Comment:
This is a bug in the compiler package you are using. Some vendors distribute broken compilers. There's not much Python can do about that!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117109&group_id=5470


From noreply@sourceforge.net  Tue Oct 17 23:35:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Oct 2000 15:35:50 -0700
Subject: [Python-bugs-list] [Bug #114027] Compiling on alpha-osf1v4: libpthreads is called libpthread
Message-ID: <200010172235.PAA10380@delerium.i.sourceforge.net>

Bug #114027, was updated on 2000-Sep-10 22:43
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: Compiling on alpha-osf1v4: libpthreads is called libpthread

Details: change -lpthreads into -lpthread

Follow-Ups:

Date: 2000-Sep-16 09:59
By: gvanrossum

Comment:
I don't have enough information to resolve this problem.
What Python version were you using?

Did you use the configure script? It should automtically select -lpthreads or -lpthread depending on which one is present. Did this fail for you? Please check the config.log file to find out more about this.

Since I don't have an Alpha OSF1v1 system, I can't debug this for you!
-------------------------------------------------------

Date: 2000-Sep-18 08:01
By: janw

Comment:
Python-2.0b1, with configure. And it looks like configure doesn't get this right.

I asked a colleague to look a bit more into this. He found the following:
1) You can use either pthreads? or decthreads. If you call configure with decthreads it compiles and runs fine, but the manpage says that decthreads are only there for backwards compatibility.
2) In the pthreads? case there are different possibilities:
- You can include the phtread.h file or not.
- You can call pthread_create with arguments or not.
- You can link with -lpthread or with -lpthreads
The manpage for pthread(2) suggests to use the compiler option -pthread, which boils down to cc -D_REENTRANT and ld -lpthread -lexc (modulo other options).
It looks like configure tries with a testfile without including pthread.h, thusly -lpthreads gets used. The sources *do* include pthread.h, but then you have to link against -lpthread.
Suggested fix: Change configure test file so that pthread.h gets included and call pthread_create(0,0,0,0) (eg. give four dummy arguments).
This works for OSF1, but we did not test if it breaks anything on other platforms.

Hope you can understand the description.
-------------------------------------------------------

Date: 2000-Oct-06 10:23
By: gvanrossum

Comment:
I'm afraid I can't quite decypher what you meant by your (clearly well-intended!) diagnosis. Do you think you could whip up a patch for configure.in? (Your suggestion to change the configure test is not specific enough for me to figure oput what needs to be done.)
-------------------------------------------------------

Date: 2000-Oct-17 15:35
By: gvanrossum

Comment:
Can you check that this is fixed in the final release of Python 2.0 (on pythonlabs.com now)? We changed something for the OSF1 platform that should take care of this.

If you confirm it's fixed I'll close the bug report.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114027&group_id=5470


From noreply@sourceforge.net  Wed Oct 18 02:10:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Oct 2000 18:10:58 -0700
Subject: [Python-bugs-list] [Bug #117070] README instructions for configuring Setup are not helpful
Message-ID: <200010180110.SAA15846@delerium.i.sourceforge.net>

Bug #117070, was updated on 2000-Oct-17 02:54
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: README instructions for configuring Setup are not helpful

Details: The instructions in the README file for configuring the Setup file are not useful. There is no indication of when you are supposed to edit the file. So far as I can tell the only way to configure python is either:

  ./configure
  make
  vim Modules/Setup
  make

or:

  ./configure
  vim Modules/Setup.in
  make

neither of which are particularly satisfactory.

The README file simply says "if [the Setup file] does not exist yet, make a copy yourself", without any indication of how you actually do this. 'make Setup' in the Modules directory does not work because there is no Makefile in the Modules directory yet.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117070&group_id=5470


From noreply@sourceforge.net  Wed Oct 18 02:11:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Oct 2000 18:11:58 -0700
Subject: [Python-bugs-list] [Bug #117092] Testsuite dumps core on Win2000 / IDLE
Message-ID: <200010180111.SAA15963@delerium.i.sourceforge.net>

Bug #117092, was updated on 2000-Oct-17 08:59
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: Testsuite dumps core on Win2000 / IDLE

Details: On a fresh installation of Python2.0 under Win2k, when running test.testall I get an "ApplicationError". The last test output is:

test_array
*****************************
array after append: <--[ApplicationError dialog appears]


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117092&group_id=5470


From noreply@sourceforge.net  Wed Oct 18 02:12:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Oct 2000 18:12:48 -0700
Subject: [Python-bugs-list] [Bug #117090] PIL (TkImaging) extension instructions wrong
Message-ID: <200010180112.SAA15967@delerium.i.sourceforge.net>

Bug #117090, was updated on 2000-Oct-17 08:55
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: PIL (TkImaging) extension instructions wrong

Details: Modules/Setup.in contains:
# *** Uncomment and edit for PIL (TkImaging) extension only:
#       -DWITH_PIL -I../Extensions/Imaging/libImaging tkImaging.c \

However, there is no directory 'Extensions' or any source
file tkImaging.c

Either these instructions should be removed from Setup.in, or tkImaging.c should be added to the distribution, or instructions should be added where to find tkImaging.c and
the associated imaging libraries.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117090&group_id=5470


From noreply@sourceforge.net  Wed Oct 18 02:21:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 17 Oct 2000 18:21:58 -0700
Subject: [Python-bugs-list] [Bug #117032] test_fcntl should not use /tmp/delete-me
Message-ID: <200010180121.SAA16311@delerium.i.sourceforge.net>

Bug #117032, was updated on 2000-Oct-16 13:45
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 2
Summary: test_fcntl should not use /tmp/delete-me

Details: This test should be updated to use test_support.TESTFN.


Follow-Ups:

Date: 2000-Oct-17 18:21
By: fdrake

Comment:
Fixed in Lib/test/test_fcntl.py revision 1.12.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117032&group_id=5470


From noreply@sourceforge.net  Wed Oct 18 11:41:07 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Oct 2000 03:41:07 -0700
Subject: [Python-bugs-list] [Bug #117158] String literal documentation is not up to date
Message-ID: <200010181041.DAA00328@bush.i.sourceforge.net>

Bug #117158, was updated on 2000-Oct-18 03:41
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: String literal documentation is not up to date

Details: Section 2.4.1 of the Reference Manual does not mention unicode 
strings and the unicode escape sequences \u and \U at all. 
Moreover, it still states that "\x" escapes consume an arbitrary 
number (>=2) of  hex digits (while it is exactly 2 right now: PEP223).


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117158&group_id=5470


From noreply@sourceforge.net  Wed Oct 18 12:52:23 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Oct 2000 04:52:23 -0700
Subject: [Python-bugs-list] [Bug #117167] _tkinter module segfaults on syntax error
Message-ID: <200010181152.EAA03277@bush.i.sourceforge.net>

Bug #117167, was updated on 2000-Oct-18 04:52
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: _tkinter module segfaults on syntax error

Details: The following listing contains a syntax error (remarked by
a comment ) which causes the python interpreter to segfault
inside _tkinter module.
the problem has been verified on Python 2.0 compiled from source on Debian GNU/Linux 2.2. It was also present on Python 1.6, on the same platform as well as on SUN/Solaris 7.0 (still compiled with gcc).
#
# --- begin listing
#
from Tkinter import *
from string import *



    
# ============================================================================
class DemoWindow( Toplevel ):
    """
    <snip>
    """
    instance = None
    
    def __init__( self,  introduction, code_file ):
        Toplevel.__init__(self)
        
        DemoWindow.instance = self

        # store object attributes
        self.code_file = code_file

        # create and pack the introduction label
        intro_label=Label(self, text=introduction)
        intro_label.pack(side=TOP)

        # this is the frame which contains the two buttons at the end
        button_frame = Frame( self )
        button_frame.pack( side=BOTTOM, pady='2m', fill=X )
        


# --- button.py
# This module demonstrates simple buttons
# It is meant to be called by the demo widget main module
# but it can also run stand-alone
#

class ButtonsDemoWindow( DemoWindow ):
    """
    A demo window with some buttons which changes the demo
    window behaviour
    """
    def __init__( self ):
        intro="""If you click on any of the four buttons below, the background
        <SNIP>
        invoke the current button."""

        # BUG ! This is the syntax error which triggers the bug.        
        DemoWindow(self, intro )
        # It should have been DemoWindow.__init__(self, intro, 'problem.py')

        frame=Frame()
        frame.pack(expand=YES, fill=BOTH )
        for c in ('Peach Puff', 'Light Blue1',
                  'Sea Green2', 'Yellow1' ):
            b = Button(self, text=c)
            b['command'] = callit( self.callback, c );
            
            b.pack( side=top, expand=yes, pady=2,
                    command=callit(self.callback, color) )

    def callback(self, color):
        self.frame['background']=color
            



if __name__ == '__main__':
    ButtonsDemoWindow() 
    mainloop()
 

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117167&group_id=5470


From noreply@sourceforge.net  Wed Oct 18 14:48:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Oct 2000 06:48:48 -0700
Subject: [Python-bugs-list] [Bug #117178] Documentation missing for __iadd__, __isub__, etc.
Message-ID: <200010181348.GAA08040@bush.i.sourceforge.net>

Bug #117178, was updated on 2000-Oct-18 06:48
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Documentation missing for __iadd__, __isub__, etc.

Details: I understand that __iadd__, __isub__, etc. are the
functions you have to implement in a class for it to
support augmented assignment, but there is no documentation
for them under the 3.3 Special Method Names section. I
searched under the Doc directory for __isub__ and found
nothing at all.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117178&group_id=5470


From noreply@sourceforge.net  Wed Oct 18 15:45:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Oct 2000 07:45:27 -0700
Subject: [Python-bugs-list] [Bug #117178] Documentation missing for __iadd__, __isub__, etc.
Message-ID: <200010181445.HAA10348@bush.i.sourceforge.net>

Bug #117178, was updated on 2000-Oct-18 06:48
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Documentation missing for __iadd__, __isub__, etc.

Details: I understand that __iadd__, __isub__, etc. are the
functions you have to implement in a class for it to
support augmented assignment, but there is no documentation
for them under the 3.3 Special Method Names section. I
searched under the Doc directory for __isub__ and found
nothing at all.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117178&group_id=5470


From noreply@sourceforge.net  Wed Oct 18 16:05:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Oct 2000 08:05:03 -0700
Subject: [Python-bugs-list] [Bug #117158] String literal documentation is not up to date
Message-ID: <200010181505.IAA11185@bush.i.sourceforge.net>

Bug #117158, was updated on 2000-Oct-18 03:41
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: String literal documentation is not up to date

Details: Section 2.4.1 of the Reference Manual does not mention unicode 
strings and the unicode escape sequences \u and \U at all. 
Moreover, it still states that "\x" escapes consume an arbitrary 
number (>=2) of  hex digits (while it is exactly 2 right now: PEP223).


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117158&group_id=5470


From noreply@sourceforge.net  Wed Oct 18 16:04:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Oct 2000 08:04:46 -0700
Subject: [Python-bugs-list] [Bug #117167] _tkinter module segfaults on "syntax error"
Message-ID: <200010181504.IAA11163@bush.i.sourceforge.net>

Bug #117167, was updated on 2000-Oct-18 04:52
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Closed
Resolution: None
Bug Group: None
Priority: 5
Summary: _tkinter module segfaults on "syntax error"

Details: The following listing contains a syntax error (remarked by
a comment ) which causes the python interpreter to segfault
inside _tkinter module.
the problem has been verified on Python 2.0 compiled from source on Debian GNU/Linux 2.2. It was also present on Python 1.6, on the same platform as well as on SUN/Solaris 7.0 (still compiled with gcc).
#
# --- begin listing
#
from Tkinter import *
from string import *



    
# ============================================================================
class DemoWindow( Toplevel ):
    """
    <snip>
    """
    instance = None
    
    def __init__( self,  introduction, code_file ):
        Toplevel.__init__(self)
        
        DemoWindow.instance = self

        # store object attributes
        self.code_file = code_file

        # create and pack the introduction label
        intro_label=Label(self, text=introduction)
        intro_label.pack(side=TOP)

        # this is the frame which contains the two buttons at the end
        button_frame = Frame( self )
        button_frame.pack( side=BOTTOM, pady='2m', fill=X )
        


# --- button.py
# This module demonstrates simple buttons
# It is meant to be called by the demo widget main module
# but it can also run stand-alone
#

class ButtonsDemoWindow( DemoWindow ):
    """
    A demo window with some buttons which changes the demo
    window behaviour
    """
    def __init__( self ):
        intro="""If you click on any of the four buttons below, the background
        <SNIP>
        invoke the current button."""

        # BUG ! This is the syntax error which triggers the bug.        
        DemoWindow(self, intro )
        # It should have been DemoWindow.__init__(self, intro, 'problem.py')

        frame=Frame()
        frame.pack(expand=YES, fill=BOTH )
        for c in ('Peach Puff', 'Light Blue1',
                  'Sea Green2', 'Yellow1' ):
            b = Button(self, text=c)
            b['command'] = callit( self.callback, c );
            
            b.pack( side=top, expand=yes, pady=2,
                    command=callit(self.callback, color) )

    def callback(self, color):
        self.frame['background']=color
            



if __name__ == '__main__':
    ButtonsDemoWindow() 
    mainloop()
 

Follow-Ups:

Date: 2000-Oct-18 08:04
By: gvanrossum

Comment:
I get a core dump with 2.0b2 but the expected exception with 2.0. Several significant bugs in _tkinter were present in 2.0b2 that were fixed in 2.0final. I'm closing this report assuming that you were using 2.0b2 or earlier. if you still have this with 2.0, first check that you don't have an older version of _tkinter.so lying around; if it persists, please resubmit the bug report.

(It's not technically a syntax error, it's a call with bogus arguments. :-)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117167&group_id=5470


From noreply@sourceforge.net  Wed Oct 18 19:51:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Oct 2000 11:51:29 -0700
Subject: [Python-bugs-list] [Bug #117195] Broken \ref link in documentation
Message-ID: <200010181851.LAA24383@delerium.i.sourceforge.net>

Bug #117195, was updated on 2000-Oct-18 11:51
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Broken \ref link in documentation

Details: [Report received by python-docs.]

From: Roy Smith <rsmith@micromuse.com>
Date: Wed, 18 Oct 2000 14:45:25 -0700

On the page http://www.python.org/doc/current/ref/exceptions.html, if I
click on the link for secion 7.4
(http://www.python.org/doc/current/ref/node83.html#try), I get an Error
404: file not found.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117195&group_id=5470


From noreply@sourceforge.net  Wed Oct 18 23:28:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Oct 2000 15:28:40 -0700
Subject: [Python-bugs-list] [Bug #117241] class.method(*([self]+args)) gave me a 'unbound method must be called with class instance 1st argument" error message.
Message-ID: <200010182228.PAA30263@bush.i.sourceforge.net>

Bug #117241, was updated on 2000-Oct-18 15:28
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: class.method(*([self]+args)) gave me a 'unbound method must be called with class instance 1st argument" error message.

Details: I have some 1.5 code like this:

apply(BaseMsgTemplate.__call__,[self]+args)

This works great and does what I want, calls the base class call method
with the current instance as self.  I thought I'd convert it to the
new calling syntax:

BaseMsgTemplate.__call__(*([self]+args))

But this gave me the error message:

'unbound method must be called with class instance 1st argument'

I *think* the * argument method is supposed to be functionally
equivalent to apply, so I think this is a bug. 


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117241&group_id=5470


From noreply@sourceforge.net  Wed Oct 18 23:47:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Oct 2000 15:47:35 -0700
Subject: [Python-bugs-list] [Bug #117242] Negative lookbehind fails
Message-ID: <200010182247.PAA31004@bush.i.sourceforge.net>

Bug #117242, was updated on 2000-Oct-18 15:47
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Negative lookbehind fails

Details: Found by Robin Becker and reported on comp.lang.python...
The following example program doesn't match, and it seems like it 
should.

import re
wpat = re.compile(r'(?<!self\.)\b([A-Za-z_]\w*)\s*\(')
m = wpat.search('   a(')


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117242&group_id=5470


From noreply@sourceforge.net  Thu Oct 19 00:19:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Oct 2000 16:19:42 -0700
Subject: [Python-bugs-list] [Bug #117090] PIL (TkImaging) extension instructions wrong
Message-ID: <200010182319.QAA32214@bush.i.sourceforge.net>

Bug #117090, was updated on 2000-Oct-17 08:55
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: PIL (TkImaging) extension instructions wrong

Details: Modules/Setup.in contains:
# *** Uncomment and edit for PIL (TkImaging) extension only:
#       -DWITH_PIL -I../Extensions/Imaging/libImaging tkImaging.c \

However, there is no directory 'Extensions' or any source
file tkImaging.c

Either these instructions should be removed from Setup.in, or tkImaging.c should be added to the distribution, or instructions should be added where to find tkImaging.c and
the associated imaging libraries.


Follow-Ups:

Date: 2000-Oct-18 16:19
By: none

Comment:
I'm not sure "wrong" is the right word here -- the comment is clearly correct, as long as the reader understands that modules that are commented out in the Setup file doesn't necessarily build on all platforms (as mentioned at the top of the Setup file, and also in the README file. "if you get
compilation or link errors, disable it -- you're missing support").

however, the easiest solution here is probably to add a reference to: http://www.pythonware.com/products/pil

</F>
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117090&group_id=5470


From noreply@sourceforge.net  Thu Oct 19 00:28:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Oct 2000 16:28:29 -0700
Subject: [Python-bugs-list] [Bug #117070] README instructions for configuring Setup are not helpful
Message-ID: <200010182328.QAA32549@bush.i.sourceforge.net>

Bug #117070, was updated on 2000-Oct-17 02:54
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: README instructions for configuring Setup are not helpful

Details: The instructions in the README file for configuring the Setup file are not useful. There is no indication of when you are supposed to edit the file. So far as I can tell the only way to configure python is either:

  ./configure
  make
  vim Modules/Setup
  make

or:

  ./configure
  vim Modules/Setup.in
  make

neither of which are particularly satisfactory.

The README file simply says "if [the Setup file] does not exist yet, make a copy yourself", without any indication of how you actually do this. 'make Setup' in the Modules directory does not work because there is no Makefile in the Modules directory yet.

Follow-Ups:

Date: 2000-Oct-18 16:28
By: none

Comment:
in my copy of the README file, there's a section called
"Build instructions", which tells you to build a basic interpreter (configure, make), and then tells you to see the sections on "testing", "configuring additional modules", and "installation"...

sounds like you only read the "configuring additional modules" section...

(satisfactory or not, it's a good idea to make sure the interpreter builds cleanly on your platform *before* you start fiddling with the extension modules...)

</F>
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117070&group_id=5470


From noreply@sourceforge.net  Thu Oct 19 01:28:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Oct 2000 17:28:20 -0700
Subject: [Python-bugs-list] [Bug #117070] README instructions for configuring Setup are not helpful
Message-ID: <200010190028.RAA02374@bush.i.sourceforge.net>

Bug #117070, was updated on 2000-Oct-17 02:54
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: README instructions for configuring Setup are not helpful

Details: The instructions in the README file for configuring the Setup file are not useful. There is no indication of when you are supposed to edit the file. So far as I can tell the only way to configure python is either:

  ./configure
  make
  vim Modules/Setup
  make

or:

  ./configure
  vim Modules/Setup.in
  make

neither of which are particularly satisfactory.

The README file simply says "if [the Setup file] does not exist yet, make a copy yourself", without any indication of how you actually do this. 'make Setup' in the Modules directory does not work because there is no Makefile in the Modules directory yet.

Follow-Ups:

Date: 2000-Oct-18 16:28
By: none

Comment:
in my copy of the README file, there's a section called
"Build instructions", which tells you to build a basic interpreter (configure, make), and then tells you to see the sections on "testing", "configuring additional modules", and "installation"...

sounds like you only read the "configuring additional modules" section...

(satisfactory or not, it's a good idea to make sure the interpreter builds cleanly on your platform *before* you start fiddling with the extension modules...)

</F>
-------------------------------------------------------

Date: 2000-Oct-18 17:28
By: jribbens

Comment:
Your README must be different to mine, mine says "Before you can build Python, you must first configure it."

The method that you are proposing is completely counter-intuitive and is precisely what you *must not* do when compiling most other programs.

If this is what you are supposed to do then it needs to say so in BIG LETTERS.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117070&group_id=5470


From noreply@sourceforge.net  Thu Oct 19 01:42:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 18 Oct 2000 17:42:21 -0700
Subject: [Python-bugs-list] [Bug #117245] Python shared-library modules do not work on OpenBSD 2.7
Message-ID: <200010190042.RAA02783@bush.i.sourceforge.net>

Bug #117245, was updated on 2000-Oct-18 17:42
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Python shared-library modules do not work on OpenBSD 2.7

Details: Python 2.0 compiles and works 100% fine with static modules. However, if I uncomment the '*shared*' line in Modules/Setup, then 'make test' will fail as follows:

cd Modules;  make OPT="-g -O2 -Wall -Wstrict-prototypes" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  sharedmods
rm -f ./Lib/test/*.py[co]
PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 39, in ?
    import random
  File "/tmp/Python-2.0/Lib/random.py", line 23, in ?
    import whrandom
  File "/tmp/Python-2.0/Lib/whrandom.py", line 134, in ?
    _inst = whrandom()
  File "/tmp/Python-2.0/Lib/whrandom.py", line 45, in __init__
    self.seed(x, y, z)
  File "/tmp/Python-2.0/Lib/whrandom.py", line 56, in seed
    import time
ImportError: dynamic module does not define init function (inittime)

But the symbol does exist:

$ nm timemodule.so | fgrep init
000009d0 T _inittime

(I noticed this bug while trying to install third-party modules, specifically the MySQLdb one, and, after testing, found the problem was more generic.)

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117245&group_id=5470


From noreply@sourceforge.net  Thu Oct 19 17:12:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Oct 2000 09:12:00 -0700
Subject: [Python-bugs-list] [Bug #117278] re-opening of bug #117167
Message-ID: <200010191612.JAA31539@bush.i.sourceforge.net>

Bug #117278, was updated on 2000-Oct-19 09:12
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: re-opening of bug #117167

Details: As directed, I'm reopening the bug #117167 (_tkinter segfaults on "syntax error"), because it was closed on incorrect assumptions:
- I believe I am using Python 2.0 final ( python -V says
'python 2.0'; the file I downloaded is named BeOpen-Python-2.0.tar.bz2 ).
- tkinter is a static module, therefore there is no possibility of still using the old one.

----
Additional info :

I verified the same behaviour on Solaris 2.0, with tcl/tk 8.3.1 and gcc 2.8.1. Hereaftter there is the output of gdb 'where' command, obtained from thye dumped core.

---------- output of where ---------------------------

#0  0x94464 in Tkapp_Call (self=0x1b80c0, args=0x18c67c) at ./_tkinter.c:644
#1  0x26fac in call_builtin (func=0x1b80a8, arg=0x18c67c, kw=0x0)
    at ceval.c:2650
#2  0x26e78 in PyEval_CallObjectWithKeywords (func=0x1b80a8, arg=0x229134,
    kw=0x0) at ceval.c:2618
#3  0x2579c in eval_code2 (co=0x1e9ff8, globals=0x0, locals=0x0,
    args=0x18c67c, argcount=0, kws=0xffffffff, kwcount=0, defs=0x22e810,
    defcount=3, owner=0x22e864) at ceval.c:1951
#4  0x253d8 in eval_code2 (co=0x1fae00, globals=0x0, locals=0x18c67c,
    args=0x17a160, argcount=2, kws=0x5, kwcount=1, defs=0x22cba8, defcount=2,
    owner=0x23102c) at ceval.c:1850
#5  0x273bc in call_function (func=0x230ffc, arg=0x2037c4, kw=0x1)
    at ceval.c:2772
#6  0x26e64 in PyEval_CallObjectWithKeywords (func=0x1b4efc, arg=0x1e33e4,
    kw=0x1a07d4) at ceval.c:2616
#7  0x45484 in PyInstance_New (class=0x23102c, arg=0x1e33e4, kw=0x1a07d4)
    at classobject.c:463
#8  0x26fd4 in call_builtin (func=0x23102c, arg=0x1e33e4, kw=0x1a07d4)
    at ceval.c:2653
#9  0x26e78 in PyEval_CallObjectWithKeywords (func=0x23102c, arg=0x1e33e4,
    kw=0x1a07d4) at ceval.c:2618
#10 0x2579c in eval_code2 (co=0x1b42c0, globals=0x1a07d4, locals=0x0,
    args=0x1b55dc, argcount=1705940, kws=0xffffffff, kwcount=0, defs=0x0,
---Type <return> to continue, or q <return> to quit---
    defcount=0, owner=0x187d3c) at ceval.c:1951
#11 0x273bc in call_function (func=0x1bb714, arg=0x1b40ec, kw=0x0)
    at ceval.c:2772
#12 0x26e64 in PyEval_CallObjectWithKeywords (func=0x1b53fc, arg=0x1c8654,
    kw=0x0) at ceval.c:2616
#13 0x45484 in PyInstance_New (class=0x187d3c, arg=0x1c8654, kw=0x0)
    at classobject.c:463
#14 0x26fd4 in call_builtin (func=0x187d3c, arg=0x1c8654, kw=0x0)
    at ceval.c:2653
#15 0x26e78 in PyEval_CallObjectWithKeywords (func=0x187d3c, arg=0x1c8654,
    kw=0x0) at ceval.c:2618
#16 0x2579c in eval_code2 (co=0x1b39b8, globals=0x0, locals=0x0,
    args=0x1b571c, argcount=0, kws=0xffffffff, kwcount=0, defs=0x0,
    defcount=0, owner=0x21b8a4) at ceval.c:1951
#17 0x273bc in call_function (func=0x222474, arg=0x184de4, kw=0x0)
    at ceval.c:2772
#18 0x26e64 in PyEval_CallObjectWithKeywords (func=0x1b5744, arg=0x175364,
    kw=0x0) at ceval.c:2616
#19 0x45484 in PyInstance_New (class=0x21b8a4, arg=0x175364, kw=0x0)
    at classobject.c:463
#20 0x26fd4 in call_builtin (func=0x21b8a4, arg=0x175364, kw=0x0)
    at ceval.c:2653
#21 0x26e78 in PyEval_CallObjectWithKeywords (func=0x21b8a4, arg=0x175364,
---Type <return> to continue, or q <return> to quit---
    kw=0x0) at ceval.c:2618
#22 0x2579c in eval_code2 (co=0x1b4148, globals=0x0, locals=0x0,
    args=0x1b6dc8, argcount=0, kws=0xffffffff, kwcount=0, defs=0x0,
    defcount=0, owner=0x0) at ceval.c:1951
#23 0x22584 in PyEval_EvalCode (co=0x1b4148, globals=0x180b54, locals=0x180b54)
    at ceval.c:319
#24 0x3a39c in run_node (n=0x175658, filename=0x1b4148 "", globals=0x180b54,
    locals=0x180b54) at pythonrun.c:886
#25 0x3a34c in run_err_node (n=0x175658, filename=0x1b4148 "",
    globals=0x180b54, locals=0x180b54) at pythonrun.c:874
#26 0x3a320 in PyRun_FileEx (fp=0x174f20, filename=0xffbef26b "problem.py",
    start=1529432, globals=0x180b54, locals=0x180b54, closeit=1)
    at pythonrun.c:866
#27 0x397e8 in PyRun_SimpleFileEx (fp=0x174f20,
    filename=0xffbef26b "problem.py", closeit=1) at pythonrun.c:579
#28 0x39390 in PyRun_AnyFileEx (fp=0x174f20, filename=0xffbef26b "problem.py",
    closeit=1) at pythonrun.c:459
#29 0x1ee08 in Py_Main (argc=2, argv=0xffbef144) at main.c:289
#30 0x1e74c in main (argc=2, argv=0xffbef144) at python.c:10


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117278&group_id=5470


From noreply@sourceforge.net  Thu Oct 19 22:06:19 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Oct 2000 14:06:19 -0700
Subject: [Python-bugs-list] [Bug #117278] re-opening of bug #117167
Message-ID: <200010192106.OAA11104@bush.i.sourceforge.net>

Bug #117278, was updated on 2000-Oct-19 09:12
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: re-opening of bug #117167

Details: As directed, I'm reopening the bug #117167 (_tkinter segfaults on "syntax error"), because it was closed on incorrect assumptions:
- I believe I am using Python 2.0 final ( python -V says
'python 2.0'; the file I downloaded is named BeOpen-Python-2.0.tar.bz2 ).
- tkinter is a static module, therefore there is no possibility of still using the old one.

----
Additional info :

I verified the same behaviour on Solaris 2.0, with tcl/tk 8.3.1 and gcc 2.8.1. Hereaftter there is the output of gdb 'where' command, obtained from thye dumped core.

---------- output of where ---------------------------

#0  0x94464 in Tkapp_Call (self=0x1b80c0, args=0x18c67c) at ./_tkinter.c:644
#1  0x26fac in call_builtin (func=0x1b80a8, arg=0x18c67c, kw=0x0)
    at ceval.c:2650
#2  0x26e78 in PyEval_CallObjectWithKeywords (func=0x1b80a8, arg=0x229134,
    kw=0x0) at ceval.c:2618
#3  0x2579c in eval_code2 (co=0x1e9ff8, globals=0x0, locals=0x0,
    args=0x18c67c, argcount=0, kws=0xffffffff, kwcount=0, defs=0x22e810,
    defcount=3, owner=0x22e864) at ceval.c:1951
#4  0x253d8 in eval_code2 (co=0x1fae00, globals=0x0, locals=0x18c67c,
    args=0x17a160, argcount=2, kws=0x5, kwcount=1, defs=0x22cba8, defcount=2,
    owner=0x23102c) at ceval.c:1850
#5  0x273bc in call_function (func=0x230ffc, arg=0x2037c4, kw=0x1)
    at ceval.c:2772
#6  0x26e64 in PyEval_CallObjectWithKeywords (func=0x1b4efc, arg=0x1e33e4,
    kw=0x1a07d4) at ceval.c:2616
#7  0x45484 in PyInstance_New (class=0x23102c, arg=0x1e33e4, kw=0x1a07d4)
    at classobject.c:463
#8  0x26fd4 in call_builtin (func=0x23102c, arg=0x1e33e4, kw=0x1a07d4)
    at ceval.c:2653
#9  0x26e78 in PyEval_CallObjectWithKeywords (func=0x23102c, arg=0x1e33e4,
    kw=0x1a07d4) at ceval.c:2618
#10 0x2579c in eval_code2 (co=0x1b42c0, globals=0x1a07d4, locals=0x0,
    args=0x1b55dc, argcount=1705940, kws=0xffffffff, kwcount=0, defs=0x0,
---Type <return> to continue, or q <return> to quit---
    defcount=0, owner=0x187d3c) at ceval.c:1951
#11 0x273bc in call_function (func=0x1bb714, arg=0x1b40ec, kw=0x0)
    at ceval.c:2772
#12 0x26e64 in PyEval_CallObjectWithKeywords (func=0x1b53fc, arg=0x1c8654,
    kw=0x0) at ceval.c:2616
#13 0x45484 in PyInstance_New (class=0x187d3c, arg=0x1c8654, kw=0x0)
    at classobject.c:463
#14 0x26fd4 in call_builtin (func=0x187d3c, arg=0x1c8654, kw=0x0)
    at ceval.c:2653
#15 0x26e78 in PyEval_CallObjectWithKeywords (func=0x187d3c, arg=0x1c8654,
    kw=0x0) at ceval.c:2618
#16 0x2579c in eval_code2 (co=0x1b39b8, globals=0x0, locals=0x0,
    args=0x1b571c, argcount=0, kws=0xffffffff, kwcount=0, defs=0x0,
    defcount=0, owner=0x21b8a4) at ceval.c:1951
#17 0x273bc in call_function (func=0x222474, arg=0x184de4, kw=0x0)
    at ceval.c:2772
#18 0x26e64 in PyEval_CallObjectWithKeywords (func=0x1b5744, arg=0x175364,
    kw=0x0) at ceval.c:2616
#19 0x45484 in PyInstance_New (class=0x21b8a4, arg=0x175364, kw=0x0)
    at classobject.c:463
#20 0x26fd4 in call_builtin (func=0x21b8a4, arg=0x175364, kw=0x0)
    at ceval.c:2653
#21 0x26e78 in PyEval_CallObjectWithKeywords (func=0x21b8a4, arg=0x175364,
---Type <return> to continue, or q <return> to quit---
    kw=0x0) at ceval.c:2618
#22 0x2579c in eval_code2 (co=0x1b4148, globals=0x0, locals=0x0,
    args=0x1b6dc8, argcount=0, kws=0xffffffff, kwcount=0, defs=0x0,
    defcount=0, owner=0x0) at ceval.c:1951
#23 0x22584 in PyEval_EvalCode (co=0x1b4148, globals=0x180b54, locals=0x180b54)
    at ceval.c:319
#24 0x3a39c in run_node (n=0x175658, filename=0x1b4148 "", globals=0x180b54,
    locals=0x180b54) at pythonrun.c:886
#25 0x3a34c in run_err_node (n=0x175658, filename=0x1b4148 "",
    globals=0x180b54, locals=0x180b54) at pythonrun.c:874
#26 0x3a320 in PyRun_FileEx (fp=0x174f20, filename=0xffbef26b "problem.py",
    start=1529432, globals=0x180b54, locals=0x180b54, closeit=1)
    at pythonrun.c:866
#27 0x397e8 in PyRun_SimpleFileEx (fp=0x174f20,
    filename=0xffbef26b "problem.py", closeit=1) at pythonrun.c:579
#28 0x39390 in PyRun_AnyFileEx (fp=0x174f20, filename=0xffbef26b "problem.py",
    closeit=1) at pythonrun.c:459
#29 0x1ee08 in Py_Main (argc=2, argv=0xffbef144) at main.c:289
#30 0x1e74c in main (argc=2, argv=0xffbef144) at python.c:10


Follow-Ups:

Date: 2000-Oct-19 14:06
By: loewis

Comment:
A fix for that is in http://sourceforge.net/patch/?func=detailpatch&patch_id=101980&group_id=5470
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117278&group_id=5470


From noreply@sourceforge.net  Thu Oct 19 22:08:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Oct 2000 14:08:12 -0700
Subject: [Python-bugs-list] [Bug #117167] _tkinter module segfaults on "syntax error"
Message-ID: <200010192108.OAA11138@bush.i.sourceforge.net>

Bug #117167, was updated on 2000-Oct-18 04:52
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Closed
Resolution: None
Bug Group: None
Priority: 5
Summary: _tkinter module segfaults on "syntax error"

Details: The following listing contains a syntax error (remarked by
a comment ) which causes the python interpreter to segfault
inside _tkinter module.
the problem has been verified on Python 2.0 compiled from source on Debian GNU/Linux 2.2. It was also present on Python 1.6, on the same platform as well as on SUN/Solaris 7.0 (still compiled with gcc).
#
# --- begin listing
#
from Tkinter import *
from string import *



    
# ============================================================================
class DemoWindow( Toplevel ):
    """
    <snip>
    """
    instance = None
    
    def __init__( self,  introduction, code_file ):
        Toplevel.__init__(self)
        
        DemoWindow.instance = self

        # store object attributes
        self.code_file = code_file

        # create and pack the introduction label
        intro_label=Label(self, text=introduction)
        intro_label.pack(side=TOP)

        # this is the frame which contains the two buttons at the end
        button_frame = Frame( self )
        button_frame.pack( side=BOTTOM, pady='2m', fill=X )
        


# --- button.py
# This module demonstrates simple buttons
# It is meant to be called by the demo widget main module
# but it can also run stand-alone
#

class ButtonsDemoWindow( DemoWindow ):
    """
    A demo window with some buttons which changes the demo
    window behaviour
    """
    def __init__( self ):
        intro="""If you click on any of the four buttons below, the background
        <SNIP>
        invoke the current button."""

        # BUG ! This is the syntax error which triggers the bug.        
        DemoWindow(self, intro )
        # It should have been DemoWindow.__init__(self, intro, 'problem.py')

        frame=Frame()
        frame.pack(expand=YES, fill=BOTH )
        for c in ('Peach Puff', 'Light Blue1',
                  'Sea Green2', 'Yellow1' ):
            b = Button(self, text=c)
            b['command'] = callit( self.callback, c );
            
            b.pack( side=top, expand=yes, pady=2,
                    command=callit(self.callback, color) )

    def callback(self, color):
        self.frame['background']=color
            



if __name__ == '__main__':
    ButtonsDemoWindow() 
    mainloop()
 

Follow-Ups:

Date: 2000-Oct-18 08:04
By: gvanrossum

Comment:
I get a core dump with 2.0b2 but the expected exception with 2.0. Several significant bugs in _tkinter were present in 2.0b2 that were fixed in 2.0final. I'm closing this report assuming that you were using 2.0b2 or earlier. if you still have this with 2.0, first check that you don't have an older version of _tkinter.so lying around; if it persists, please resubmit the bug report.

(It's not technically a syntax error, it's a call with bogus arguments. :-)
-------------------------------------------------------

Date: 2000-Oct-19 14:08
By: loewis

Comment:
A fix for that bug is in http://sourceforge.net/patch/?func=detailpatch&patch_id=101980&group_id=5470
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117167&group_id=5470


From noreply@sourceforge.net  Thu Oct 19 23:44:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Oct 2000 15:44:59 -0700
Subject: [Python-bugs-list] [Bug #117305] Limited precision enter 3.14 you get 3.1400000000000001
Message-ID: <200010192244.PAA15032@bush.i.sourceforge.net>

Bug #117305, was updated on 2000-Oct-19 15:44
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Limited precision enter 3.14 you get 3.1400000000000001

Details: Just downloaded version 2.0
This is my first day, so I have no experience with Python at all.
I don't know if this is a bug, but according to the online docs 

x = 10 * 3.14 should give me 31.4 not 31.400000000000002.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117305&group_id=5470


From noreply@sourceforge.net  Fri Oct 20 04:06:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Oct 2000 20:06:21 -0700
Subject: [Python-bugs-list] [Bug #117305] Limited precision enter 3.14 you get 3.1400000000000001
Message-ID: <200010200306.UAA24523@bush.i.sourceforge.net>

Bug #117305, was updated on 2000-Oct-19 15:44
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: Limited precision enter 3.14 you get 3.1400000000000001

Details: Just downloaded version 2.0
This is my first day, so I have no experience with Python at all.
I don't know if this is a bug, but according to the online docs 

x = 10 * 3.14 should give me 31.4 not 31.400000000000002.


Follow-Ups:

Date: 2000-Oct-19 20:06
By: fdrake

Comment:
This is a function of the inherant behavior of floating point operations rather than a bug in the implementation.  This does, however, reflect a point on which the documentation is slightly out of date; the full precision of floating point values used to not be reported at the interactive prompt.

The Tutorial is updated as Doc/tut/tut.tex revision 1.119.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117305&group_id=5470


From noreply@sourceforge.net  Fri Oct 20 04:24:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Oct 2000 20:24:01 -0700
Subject: [Python-bugs-list] [Bug #117278] re-opening of bug #117167
Message-ID: <200010200324.UAA27890@delerium.i.sourceforge.net>

Bug #117278, was updated on 2000-Oct-19 09:12
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: re-opening of bug #117167

Details: As directed, I'm reopening the bug #117167 (_tkinter segfaults on "syntax error"), because it was closed on incorrect assumptions:
- I believe I am using Python 2.0 final ( python -V says
'python 2.0'; the file I downloaded is named BeOpen-Python-2.0.tar.bz2 ).
- tkinter is a static module, therefore there is no possibility of still using the old one.

----
Additional info :

I verified the same behaviour on Solaris 2.0, with tcl/tk 8.3.1 and gcc 2.8.1. Hereaftter there is the output of gdb 'where' command, obtained from thye dumped core.

---------- output of where ---------------------------

#0  0x94464 in Tkapp_Call (self=0x1b80c0, args=0x18c67c) at ./_tkinter.c:644
#1  0x26fac in call_builtin (func=0x1b80a8, arg=0x18c67c, kw=0x0)
    at ceval.c:2650
#2  0x26e78 in PyEval_CallObjectWithKeywords (func=0x1b80a8, arg=0x229134,
    kw=0x0) at ceval.c:2618
#3  0x2579c in eval_code2 (co=0x1e9ff8, globals=0x0, locals=0x0,
    args=0x18c67c, argcount=0, kws=0xffffffff, kwcount=0, defs=0x22e810,
    defcount=3, owner=0x22e864) at ceval.c:1951
#4  0x253d8 in eval_code2 (co=0x1fae00, globals=0x0, locals=0x18c67c,
    args=0x17a160, argcount=2, kws=0x5, kwcount=1, defs=0x22cba8, defcount=2,
    owner=0x23102c) at ceval.c:1850
#5  0x273bc in call_function (func=0x230ffc, arg=0x2037c4, kw=0x1)
    at ceval.c:2772
#6  0x26e64 in PyEval_CallObjectWithKeywords (func=0x1b4efc, arg=0x1e33e4,
    kw=0x1a07d4) at ceval.c:2616
#7  0x45484 in PyInstance_New (class=0x23102c, arg=0x1e33e4, kw=0x1a07d4)
    at classobject.c:463
#8  0x26fd4 in call_builtin (func=0x23102c, arg=0x1e33e4, kw=0x1a07d4)
    at ceval.c:2653
#9  0x26e78 in PyEval_CallObjectWithKeywords (func=0x23102c, arg=0x1e33e4,
    kw=0x1a07d4) at ceval.c:2618
#10 0x2579c in eval_code2 (co=0x1b42c0, globals=0x1a07d4, locals=0x0,
    args=0x1b55dc, argcount=1705940, kws=0xffffffff, kwcount=0, defs=0x0,
---Type <return> to continue, or q <return> to quit---
    defcount=0, owner=0x187d3c) at ceval.c:1951
#11 0x273bc in call_function (func=0x1bb714, arg=0x1b40ec, kw=0x0)
    at ceval.c:2772
#12 0x26e64 in PyEval_CallObjectWithKeywords (func=0x1b53fc, arg=0x1c8654,
    kw=0x0) at ceval.c:2616
#13 0x45484 in PyInstance_New (class=0x187d3c, arg=0x1c8654, kw=0x0)
    at classobject.c:463
#14 0x26fd4 in call_builtin (func=0x187d3c, arg=0x1c8654, kw=0x0)
    at ceval.c:2653
#15 0x26e78 in PyEval_CallObjectWithKeywords (func=0x187d3c, arg=0x1c8654,
    kw=0x0) at ceval.c:2618
#16 0x2579c in eval_code2 (co=0x1b39b8, globals=0x0, locals=0x0,
    args=0x1b571c, argcount=0, kws=0xffffffff, kwcount=0, defs=0x0,
    defcount=0, owner=0x21b8a4) at ceval.c:1951
#17 0x273bc in call_function (func=0x222474, arg=0x184de4, kw=0x0)
    at ceval.c:2772
#18 0x26e64 in PyEval_CallObjectWithKeywords (func=0x1b5744, arg=0x175364,
    kw=0x0) at ceval.c:2616
#19 0x45484 in PyInstance_New (class=0x21b8a4, arg=0x175364, kw=0x0)
    at classobject.c:463
#20 0x26fd4 in call_builtin (func=0x21b8a4, arg=0x175364, kw=0x0)
    at ceval.c:2653
#21 0x26e78 in PyEval_CallObjectWithKeywords (func=0x21b8a4, arg=0x175364,
---Type <return> to continue, or q <return> to quit---
    kw=0x0) at ceval.c:2618
#22 0x2579c in eval_code2 (co=0x1b4148, globals=0x0, locals=0x0,
    args=0x1b6dc8, argcount=0, kws=0xffffffff, kwcount=0, defs=0x0,
    defcount=0, owner=0x0) at ceval.c:1951
#23 0x22584 in PyEval_EvalCode (co=0x1b4148, globals=0x180b54, locals=0x180b54)
    at ceval.c:319
#24 0x3a39c in run_node (n=0x175658, filename=0x1b4148 "", globals=0x180b54,
    locals=0x180b54) at pythonrun.c:886
#25 0x3a34c in run_err_node (n=0x175658, filename=0x1b4148 "",
    globals=0x180b54, locals=0x180b54) at pythonrun.c:874
#26 0x3a320 in PyRun_FileEx (fp=0x174f20, filename=0xffbef26b "problem.py",
    start=1529432, globals=0x180b54, locals=0x180b54, closeit=1)
    at pythonrun.c:866
#27 0x397e8 in PyRun_SimpleFileEx (fp=0x174f20,
    filename=0xffbef26b "problem.py", closeit=1) at pythonrun.c:579
#28 0x39390 in PyRun_AnyFileEx (fp=0x174f20, filename=0xffbef26b "problem.py",
    closeit=1) at pythonrun.c:459
#29 0x1ee08 in Py_Main (argc=2, argv=0xffbef144) at main.c:289
#30 0x1e74c in main (argc=2, argv=0xffbef144) at python.c:10


Follow-Ups:

Date: 2000-Oct-19 14:06
By: loewis

Comment:
A fix for that is in http://sourceforge.net/patch/?func=detailpatch&patch_id=101980&group_id=5470
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117278&group_id=5470


From noreply@sourceforge.net  Fri Oct 20 04:28:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 19 Oct 2000 20:28:51 -0700
Subject: [Python-bugs-list] [Bug #117241] class.method(*([self]+args)) gave me a 'unbound method must be called with class instance 1st argument" error message.
Message-ID: <200010200328.UAA28096@delerium.i.sourceforge.net>

Bug #117241, was updated on 2000-Oct-18 15:28
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: class.method(*([self]+args)) gave me a 'unbound method must be called with class instance 1st argument" error message.

Details: I have some 1.5 code like this:

apply(BaseMsgTemplate.__call__,[self]+args)

This works great and does what I want, calls the base class call method
with the current instance as self.  I thought I'd convert it to the
new calling syntax:

BaseMsgTemplate.__call__(*([self]+args))

But this gave me the error message:

'unbound method must be called with class instance 1st argument'

I *think* the * argument method is supposed to be functionally
equivalent to apply, so I think this is a bug. 


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117241&group_id=5470


From noreply@sourceforge.net  Fri Oct 20 09:12:33 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 20 Oct 2000 01:12:33 -0700
Subject: [Python-bugs-list] [Bug #117324] threadmodule.c uses fprintf(stderr...)
Message-ID: <200010200812.BAA03207@bush.i.sourceforge.net>

Bug #117324, was updated on 2000-Oct-20 01:12
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: threadmodule.c uses fprintf(stderr...)

Details: threadmodule.c uses fprintf(stderr...) to tell the user an unhandled exception occured in a thread. I think this should be done through PySys_WriteStderr() instead.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117324&group_id=5470


From noreply@sourceforge.net  Fri Oct 20 17:03:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 20 Oct 2000 09:03:40 -0700
Subject: [Python-bugs-list] [Bug #117328] .py and .pyc icons confusing.
Message-ID: <200010201603.JAA18152@delerium.i.sourceforge.net>

Bug #117328, was updated on 2000-Oct-20 09:03
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: Not a Bug
Priority: 5
Summary: .py and .pyc icons confusing.

Details: A very minor usability problem is that on Windows both the .py and .pyc icons look similar at a glance.  It'd be nice if you could change the colour of the .pyc icon to make it easy to idnetify the differences.

Thanks.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117328&group_id=5470


From noreply@sourceforge.net  Fri Oct 20 17:26:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 20 Oct 2000 09:26:05 -0700
Subject: [Python-bugs-list] [Bug #117242] Negative lookbehind fails
Message-ID: <200010201626.JAA19065@delerium.i.sourceforge.net>

Bug #117242, was updated on 2000-Oct-18 15:47
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Negative lookbehind fails

Details: Found by Robin Becker and reported on comp.lang.python...
The following example program doesn't match, and it seems like it 
should.

import re
wpat = re.compile(r'(?<!self\.)\b([A-Za-z_]\w*)\s*\(')
m = wpat.search('   a(')


Follow-Ups:

Date: 2000-Oct-20 09:26
By: akuchling

Comment:
Patch #101972 is a proposed fix for this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117242&group_id=5470


From noreply@sourceforge.net  Fri Oct 20 18:08:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 20 Oct 2000 10:08:14 -0700
Subject: [Python-bugs-list] [Bug #117329] Compile Python 2.0 on BSDI BSD/OS 4.0.1 fails
Message-ID: <200010201708.KAA20835@delerium.i.sourceforge.net>

Bug #117329, was updated on 2000-Oct-20 10:08
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Compile Python 2.0 on BSDI BSD/OS 4.0.1 fails

Details: When compiling Python 2.0. on BSDI BSD/OS 4.0.1

Configure
     ./configure --prefix=/usr/home/sud2000/python --with-                  threads=no
     no problem

make

     After a lot of warnings like :

        .........
   /usr/include/math.h:177: warning: function declaration
             isn't a prototype
   /usr/include/math.h:257: warning: function declaration
             isn't a prototype
        ........

The compile failed with this message :

   /usr/home/......./Python-2.0/Objects/fileobject.c:274:
                      undefined reference to `TELL64'
   *** Error code 1

        Stop.
   *** Error code 1


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117329&group_id=5470


From noreply@sourceforge.net  Fri Oct 20 18:45:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 20 Oct 2000 10:45:32 -0700
Subject: [Python-bugs-list] [Bug #116172] 2.0b2 curses module fails to build on SGI
Message-ID: <200010201745.KAA22878@delerium.i.sourceforge.net>

Bug #116172, was updated on 2000-Oct-05 12:40
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: 2.0b2 curses module fails to build on SGI

Details: I didn't see this in the database.

Trying to build 2.0b2 here on SGI IRIX 6.5.  I have this
line in Setup:

     _curses _cursesmodule.c -lcurses -ltermcap

This used to work on 1.5.2 on IRIX 6.5, but it doesn't with 2.0b2.

Here is a digested version of the errors:

cc -n32  -O -KPIC -I./../Include -I.. -DHAVE_CONFIG_H -c ./_cursesmodule.c
...
  The identifier "attr_t" is undefined.
  The identifier "ACS_S3" is undefined.
  The identifier "ACS_LEQUAL" is undefined.
  The identifier "ACS_GEQUAL" is undefined.
  The identifier "ACS_PI" is undefined.
  The identifier "ACS_NEQUAL" is undefined.
  The identifier "ACS_STERLING" is undefined.
  A value of type "int" cannot be assigned to an entity of type "char *".
        capname = tigetstr( capname );
                ^
  The identifier "A_HORIZONTAL" is undefined.
  The identifier "A_LEFT" is undefined.
  The identifier "A_LOW" is undefined.
  The identifier "A_RIGHT" is undefined.
  The identifier "A_TOP" is undefined.
  The identifier "A_VERTICAL" is undefined.


Follow-Ups:

Date: 2000-Oct-06 07:50
By: gvanrossum

Comment:
I don't know, but I think this may be caused by IRIX having an old, incompatible version of curses. So it probably won't work. Too bad. You may be able to get a different curses implementation (there must be a free one that comes with Linux???).
-------------------------------------------------------

Date: 2000-Oct-06 08:42
By: jhylton

Comment:
Eric, can you look at this today?
-------------------------------------------------------

Date: 2000-Oct-06 11:26
By: VizNut

Comment:
A quick grep reveals Sun Solaris 7 doesn't have them either.

If the intent is to break with standard curses, to avoid confusion it might be best to rename the module from curses to "linux_curses" or "ncurses" (if that's the appropriate curses variety).

Thanks,

-------------------------------------------------------

Date: 2000-Oct-12 10:42
By: gvanrossum

Comment:
This appears to be simply a matter of the platform's curses library being *reeeeeeeally* old. So I'm lowering the priority.

The ncurses API is actually quite old, and vendors have no excuse for not providing it. That's why it's not a good idea to call the module linuxcurses or ncurses.

However, it's quite possible that your vendor provides both the old curses API and the ncurses API, under those names. In that case it shouldn't be hard to change the source code to include "ncurses.h" and the Makefile to link with -lncurses. If you get this working, I'd be glad to accept a patch via the SourceForge Patch manager! This can't be done in 2.0 though (we're in a code freeze stage right now where only critical bugfixes may be checked in).
-------------------------------------------------------

Date: 2000-Oct-20 10:45
By: akuchling

Comment:
Clarification: ncurses implements the SYSV curses API,
which adds a lot of features on top of the old BSD curses API.  For example, Solaris doesn't use ncurses, but it does 
support the SYSV API, and the module should work there.

There's a STRICT_SYSV_CURSES macro that can be defined 
in _cursesmodule.c that removes certain features that
aren't on every SYSV curses platform.  That macro should be 
defined on SGI, from the following code:

#if defined(__sgi__) || defined(__sun__)
#define STRICT_SYSV_CURSES       /* Don't use ncurses extensions */
typedef chtype attr_t;           /* No attr_t type is available */
#endif                                                                          

Does your compiler not define __sgi__?  Perhaps some different macro should be used for this feature test.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116172&group_id=5470


From noreply@sourceforge.net  Fri Oct 20 21:02:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 20 Oct 2000 13:02:57 -0700
Subject: [Python-bugs-list] [Bug #117324] threadmodule.c uses fprintf(stderr...)
Message-ID: <200010202002.NAA25635@bush.i.sourceforge.net>

Bug #117324, was updated on 2000-Oct-20 01:12
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 4
Summary: threadmodule.c uses fprintf(stderr...)

Details: threadmodule.c uses fprintf(stderr...) to tell the user an unhandled exception occured in a thread. I think this should be done through PySys_WriteStderr() instead.

Follow-Ups:

Date: 2000-Oct-20 13:02
By: fdrake

Comment:
I agree, and have checked in a fix as Modules/threadmodule.c revision 2.40.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117324&group_id=5470


From noreply@sourceforge.net  Sat Oct 21 21:44:33 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Oct 2000 13:44:33 -0700
Subject: [Python-bugs-list] [Bug #117386] Compile fails on RH7
Message-ID: <200010212044.NAA12156@bush.i.sourceforge.net>

Bug #117386, was updated on 2000-Oct-21 13:44
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Compile fails on RH7

Details: ./configure runs properly, no errors.

After running make with no options, it eventually errors out on the following:

gcc -g -O2 -Wall -Wstrict-prototypes -I./../Include -I.. -DHAVE_CONFIG_H   -c -o grammar1.o grammar1.c
gcc -g -O2 -Wall -Wstrict-prototypes -I./../Include -I.. -DHAVE_CONFIG_H   -c -o listnode.o listnode.c
gcc -g -O2 -Wall -Wstrict-prototypes -I./../Include -I.. -DHAVE_CONFIG_H   -c -o node.o node.c
In file included from ../Include/Python.h:54,
                 from node.c:3:
../Include/pyport.h:390:2: #error "LONG_BIT definition appears wrong for platform (bad gcc config?)."
make[1]: *** [node.o] Error 1
make[1]: Leaving directory `/home/eem12/Python-2.0/Parser'
make: *** [Parser] Error 2


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117386&group_id=5470


From noreply@sourceforge.net  Sat Oct 21 21:47:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 21 Oct 2000 13:47:43 -0700
Subject: [Python-bugs-list] [Bug #117386] Compile fails on RH7
Message-ID: <200010212047.NAA12226@bush.i.sourceforge.net>

Bug #117386, was updated on 2000-Oct-21 13:44
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Compile fails on RH7

Details: ./configure runs properly, no errors.

After running make with no options, it eventually errors out on the following:

gcc -g -O2 -Wall -Wstrict-prototypes -I./../Include -I.. -DHAVE_CONFIG_H   -c -o grammar1.o grammar1.c
gcc -g -O2 -Wall -Wstrict-prototypes -I./../Include -I.. -DHAVE_CONFIG_H   -c -o listnode.o listnode.c
gcc -g -O2 -Wall -Wstrict-prototypes -I./../Include -I.. -DHAVE_CONFIG_H   -c -o node.o node.c
In file included from ../Include/Python.h:54,
                 from node.c:3:
../Include/pyport.h:390:2: #error "LONG_BIT definition appears wrong for platform (bad gcc config?)."
make[1]: *** [node.o] Error 1
make[1]: Leaving directory `/home/eem12/Python-2.0/Parser'
make: *** [Parser] Error 2


Follow-Ups:

Date: 2000-Oct-21 13:47
By: nebulascape

Comment:

Nevermind, this seems to be a gcc problem...
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117386&group_id=5470


From noreply@sourceforge.net  Mon Oct 23 08:29:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Oct 2000 00:29:09 -0700
Subject: [Python-bugs-list] [Bug #117464] clash with BSD db when building
Message-ID: <200010230729.AAA07708@sf-web2.i.sourceforge.net>

Bug #117464, was updated on 2000-Oct-23 00:29
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: clash with BSD db when building

Details: On RH7.0, beside the LONG_BIT issue, I came across a db.h missmatch. 
The preprocessor directive values used in bsddbmodule.c correspond to the /usr/include/db1/db.h file, but on my system, /usr/include/db.h points to db3/db.h which does not define the same set of values, and does not compile.

Compiling with the old file works, but obviously it does not link...

configure (with no options) ran trouble free.

The system is:
RedHat 7.0
gcc version 2.96 20000731 (yes with the LONG_BIT problem) 
Python 2.0 final release

Regards,
Pascal    

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117464&group_id=5470


From noreply@sourceforge.net  Mon Oct 23 08:40:23 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Oct 2000 00:40:23 -0700
Subject: [Python-bugs-list] [Bug #117467] missing parameter in function summary
Message-ID: <200010230740.AAA09026@sf-web3.vaspecialprojects.com>

Bug #117467, was updated on 2000-Oct-23 00:40
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: missing parameter in function summary

Details: In the library reference, chapter 11.1 webbrowser :
the function register has an incomplete description.
No mention of the parameter instance in the header.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117467&group_id=5470


From noreply@sourceforge.net  Mon Oct 23 11:55:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Oct 2000 03:55:09 -0700
Subject: [Python-bugs-list] [Bug #117484] Float operations/assignments in Python 2.0
Message-ID: <200010231055.DAA14599@sf-web1.i.sourceforge.net>

Bug #117484, was updated on 2000-Oct-23 03:55
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Float operations/assignments in Python 2.0

Details: Platform : WinNT 4.0 SP 5

go the interpreter window 
>>> x = 5.14
>>> x
5.139998

Could u please explain whats happening?
Wanted to use Python2.0 for test drivers for a financial package?
What do I do?

Thanks,
Kalyan.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117484&group_id=5470


From noreply@sourceforge.net  Mon Oct 23 13:31:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Oct 2000 05:31:50 -0700
Subject: [Python-bugs-list] [Bug #117490] mailbox.Maildir does not create self.boxes in __init__
Message-ID: <200010231231.FAA13266@sf-web3.vaspecialprojects.com>

Bug #117490, was updated on 2000-Oct-23 05:31
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: mailbox.Maildir does not create self.boxes in __init__

Details: The __init__ method of the Maildir class sets "boxes", not
"self.boxes". This means that attempts to manipulate that list fail,
and such mailboxes are always empty.

Here's the patch.

su-2.04# p4 diff2 -du mailbox.py\#1 mailbox.py\#2
==== //depot/hosts/guru/usr/opt/lib/python2.0/mailbox.py#1 (xtext) - //depot/hosts/guru/usr/opt/lib/python2.0/mailbox.py#2 (xtext) ==== content
@@ -185,13 +185,13 @@
 
         # check for new mail
         newdir = os.path.join(self.dirname, 'new')
-        boxes = [os.path.join(newdir, f)
-                 for f in os.listdir(newdir) if f[0] != '.']
+        self.boxes = [os.path.join(newdir, f)
+                      for f in os.listdir(newdir) if f[0] != '.']
 
         # Now check for current mail in this maildir
         curdir = os.path.join(self.dirname, 'cur')
-        boxes += [os.path.join(curdir, f)
-                  for f in os.listdir(curdir) if f[0] != '.']
+        self.boxes += [os.path.join(curdir, f)
+                       for f in os.listdir(curdir) if f[0] != '.']
 
     def next(self):
         if not self.boxes:



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117490&group_id=5470


From noreply@sourceforge.net  Mon Oct 23 14:30:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Oct 2000 06:30:29 -0700
Subject: [Python-bugs-list] [Bug #117386] Compile fails on RH7
Message-ID: <200010231330.GAA17161@sf-web1.i.sourceforge.net>

Bug #117386, was updated on 2000-Oct-21 13:44
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: Compile fails on RH7

Details: ./configure runs properly, no errors.

After running make with no options, it eventually errors out on the following:

gcc -g -O2 -Wall -Wstrict-prototypes -I./../Include -I.. -DHAVE_CONFIG_H   -c -o grammar1.o grammar1.c
gcc -g -O2 -Wall -Wstrict-prototypes -I./../Include -I.. -DHAVE_CONFIG_H   -c -o listnode.o listnode.c
gcc -g -O2 -Wall -Wstrict-prototypes -I./../Include -I.. -DHAVE_CONFIG_H   -c -o node.o node.c
In file included from ../Include/Python.h:54,
                 from node.c:3:
../Include/pyport.h:390:2: #error "LONG_BIT definition appears wrong for platform (bad gcc config?)."
make[1]: *** [node.o] Error 1
make[1]: Leaving directory `/home/eem12/Python-2.0/Parser'
make: *** [Parser] Error 2


Follow-Ups:

Date: 2000-Oct-21 13:47
By: nebulascape

Comment:

Nevermind, this seems to be a gcc problem...
-------------------------------------------------------

Date: 2000-Oct-23 06:30
By: jhylton

Comment:
This is not a bug; as the error message indicates it is a platform/compiler bug.  The gcc install on RH7 is broken, and you should complain to RedHat.  You can work around this problem on your local machine by manually defining LONG_BIT to be 32.


-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117386&group_id=5470


From noreply@sourceforge.net  Mon Oct 23 14:34:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Oct 2000 06:34:20 -0700
Subject: [Python-bugs-list] [Bug #117484] Float operations/assignments in Python 2.0
Message-ID: <200010231334.GAA17212@sf-web1.i.sourceforge.net>

Bug #117484, was updated on 2000-Oct-23 03:55
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Wont Fix
Bug Group: Not a Bug
Priority: 5
Summary: Float operations/assignments in Python 2.0

Details: Platform : WinNT 4.0 SP 5

go the interpreter window 
>>> x = 5.14
>>> x
5.139998

Could u please explain whats happening?
Wanted to use Python2.0 for test drivers for a financial package?
What do I do?

Thanks,
Kalyan.


Follow-Ups:

Date: 2000-Oct-23 06:34
By: jhylton

Comment:
This isn't a bug; it's the way floating point numbers work in nearly every language and on nearly every platform.

http://www.deja.com/=dnc/[ST_rn=ps]/getdoc.xp?AN=607818947

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117484&group_id=5470


From noreply@sourceforge.net  Mon Oct 23 14:35:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Oct 2000 06:35:24 -0700
Subject: [Python-bugs-list] [Bug #117490] mailbox.Maildir does not create self.boxes in __init__
Message-ID: <200010231335.GAA17234@sf-web1.i.sourceforge.net>

Bug #117490, was updated on 2000-Oct-23 05:31
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: mailbox.Maildir does not create self.boxes in __init__

Details: The __init__ method of the Maildir class sets "boxes", not
"self.boxes". This means that attempts to manipulate that list fail,
and such mailboxes are always empty.

Here's the patch.

su-2.04# p4 diff2 -du mailbox.py\#1 mailbox.py\#2
==== //depot/hosts/guru/usr/opt/lib/python2.0/mailbox.py#1 (xtext) - //depot/hosts/guru/usr/opt/lib/python2.0/mailbox.py#2 (xtext) ==== content
@@ -185,13 +185,13 @@
 
         # check for new mail
         newdir = os.path.join(self.dirname, 'new')
-        boxes = [os.path.join(newdir, f)
-                 for f in os.listdir(newdir) if f[0] != '.']
+        self.boxes = [os.path.join(newdir, f)
+                      for f in os.listdir(newdir) if f[0] != '.']
 
         # Now check for current mail in this maildir
         curdir = os.path.join(self.dirname, 'cur')
-        boxes += [os.path.join(curdir, f)
-                  for f in os.listdir(curdir) if f[0] != '.']
+        self.boxes += [os.path.join(curdir, f)
+                       for f in os.listdir(curdir) if f[0] != '.']
 
     def next(self):
         if not self.boxes:



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117490&group_id=5470


From noreply@sourceforge.net  Mon Oct 23 14:36:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Oct 2000 06:36:13 -0700
Subject: [Python-bugs-list] [Bug #117377] API docs, 7.2.1, too restrictive statement
Message-ID: <200010231336.GAA17251@sf-web1.i.sourceforge.net>

Bug #117377, was updated on 2000-Oct-21 07:12
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: API docs, 7.2.1, too restrictive statement

Details: The API docs, 7.2.1, states "data must not be modified in any way" about PyString_AsString, without any qualification or exception.  But PyString_FromStringAndSize(0, n) is correctly documented to leave the data uninitialized; how to change (initialize) it, if data must never be modified after a PyString_AsString?  Actually, it seems, the statement about the latter could and should be qualified as, e.g., "data must not be modified in any way unless the string-object has just been allocated through a call to PyString_FromStringAndSize(0,n)", or something of the kind. Otherwise, some module authors will needlessly malloc the buffer space, put that data there, copy it to the Python string with PyString_FromStringAndSize, then free it -- much more work (time & memory) expenditure than needed; the Numerics module does that, for example.  If this is what is meant, then surely the 0-valued first arg to the allocation function has no use and should be removed...?

Follow-Ups:

Date: 2000-Oct-23 06:36
By: jhylton

Comment:
documentation nit
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117377&group_id=5470


From noreply@sourceforge.net  Mon Oct 23 14:36:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Oct 2000 06:36:34 -0700
Subject: [Python-bugs-list] [Bug #117467] missing parameter in function summary
Message-ID: <200010231336.GAA17255@sf-web1.i.sourceforge.net>

Bug #117467, was updated on 2000-Oct-23 00:40
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: missing parameter in function summary

Details: In the library reference, chapter 11.1 webbrowser :
the function register has an incomplete description.
No mention of the parameter instance in the header.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117467&group_id=5470


From noreply@sourceforge.net  Mon Oct 23 14:37:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Oct 2000 06:37:04 -0700
Subject: [Python-bugs-list] [Bug #117402] Interpreter crashes when str or repr called with an array
Message-ID: <200010231337.GAA17269@sf-web1.i.sourceforge.net>

Bug #117402, was updated on 2000-Oct-22 02:16
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: Interpreter crashes when str or repr called with an array

Details: With Python 2.0 Final Release,


>>> from array import array
>>> z=array('c','hello world')
>>> `z`  #Note that these are back-quotes

It returns a nice "python20.dll" error with a page fault
, whereas run on python 1.6, it returns what we expect,
the string form of the array. (On Unix System V, it
produced a segmentation fault)




For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117402&group_id=5470


From noreply@sourceforge.net  Mon Oct 23 14:38:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Oct 2000 06:38:04 -0700
Subject: [Python-bugs-list] [Bug #117490] mailbox.Maildir does not create self.boxes in __init__
Message-ID: <200010231338.GAA13346@sf-web2.i.sourceforge.net>

Bug #117490, was updated on 2000-Oct-23 05:31
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 8
Summary: mailbox.Maildir does not create self.boxes in __init__

Details: The __init__ method of the Maildir class sets "boxes", not
"self.boxes". This means that attempts to manipulate that list fail,
and such mailboxes are always empty.

Here's the patch.

su-2.04# p4 diff2 -du mailbox.py\#1 mailbox.py\#2
==== //depot/hosts/guru/usr/opt/lib/python2.0/mailbox.py#1 (xtext) - //depot/hosts/guru/usr/opt/lib/python2.0/mailbox.py#2 (xtext) ==== content
@@ -185,13 +185,13 @@
 
         # check for new mail
         newdir = os.path.join(self.dirname, 'new')
-        boxes = [os.path.join(newdir, f)
-                 for f in os.listdir(newdir) if f[0] != '.']
+        self.boxes = [os.path.join(newdir, f)
+                      for f in os.listdir(newdir) if f[0] != '.']
 
         # Now check for current mail in this maildir
         curdir = os.path.join(self.dirname, 'cur')
-        boxes += [os.path.join(curdir, f)
-                  for f in os.listdir(curdir) if f[0] != '.']
+        self.boxes += [os.path.join(curdir, f)
+                       for f in os.listdir(curdir) if f[0] != '.']
 
     def next(self):
         if not self.boxes:



Follow-Ups:

Date: 2000-Oct-23 06:38
By: fdrake

Comment:
Fixed in Lib/mailbox.py revision 1.26; a test case will be added to the regression test suite as well.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117490&group_id=5470


From noreply@sourceforge.net  Mon Oct 23 18:16:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Oct 2000 10:16:03 -0700
Subject: [Python-bugs-list] [Bug #117508] Building 2.0 under Solaris 8 with GCC 2.95.2 fails to link
Message-ID: <200010231716.KAA18181@sf-web3.vaspecialprojects.com>

Bug #117508, was updated on 2000-Oct-23 10:16
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Building 2.0 under Solaris 8 with GCC 2.95.2 fails to link

Details: With no special options to 'configure' the final link step results in

   cd Modules;  make OPT="-g -O2 -Wall -Wstrict-prototypes" VERSION="2.0" \
                   prefix="/usr/local" exec_prefix="/usr/local" \
                   LIBRARY=../libpython2.0.a link
   make[1]: Entering directory `/tmp/pedwards/newbuild/Python-2.0/Modules'
   gcc   python.o \
             ../libpython2.0.a -ldb                                 -lpthread -lsocket -lnsl -ldl  -lthread -lm  -o python 
   Undefined                       first referenced
    symbol                             in file
   dbopen                              ../libpython2.0.a(bsddbmodule.o)
   ld: fatal: Symbol referencing errors. No output written to python
   collect2: ld returned 1 exit status
   make[1]: *** [link] Error 1

This is using GNU make, and GCC with the native linker.  Using the native
compiler works fine.  



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117508&group_id=5470


From noreply@sourceforge.net  Mon Oct 23 20:23:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Oct 2000 12:23:47 -0700
Subject: [Python-bugs-list] [Bug #115696] sre RuntimeError when .*? matches >16K string
Message-ID: <200010231923.MAA19501@sf-web2.i.sourceforge.net>

Bug #115696, was updated on 2000-Sep-29 19:47
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: sre RuntimeError when .*? matches >16K string

Details: The following code (run under WinNT):

    sre.search('x.*?z', 'x%sx' % ("y" * 16037,))

raises "RuntimeError: maximum recursion limit exceeded".

sre doesn't seem to be able to do a minimal match across more than ~16K characters. I think pcre can match something like 2**32 characters, so this is an area where the sre behavior deviates radically from pcre. I have lots of code that breaks with this limit. Yikes! Can something be done?

While trying to come up with the magic number of characters that cause a minimal match to fail, I ran this interactive session 
(I'm not sure if this means anything or if it's a quirk of the interactive interpreter.)

C:\>python
Python 2.0b2 (#6, Sep 26 2000, 14:59:21) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.

>>> import sre

>>> sre.search('x.*?x', 'x%sx' % ('@'*16035,))
<SRE_Match object at 009D7FC0>

>>> sre.search('x.*?x', 'x%sx' % ('@'*16036,))
<SRE_Match object at 009D7040>

>>> sre.search('x.*?x', 'x%sx' % ('@'*16037,))      <-- first failure
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "D:\Python20\lib\sre.py", line 47, in search
    return _compile(pattern, flags).search(string)
RuntimeError: maximum recursion limit exceeded

>>> sre.search('x.*?x', 'x%sx' % ('@'*16037,))      <-- now it works (?!)
<SRE_Match object at 009D7630>

>>> sre.search('x.*?x', 'x%sx' % ('@'*16038,))
<SRE_Match object at 009D7040>

>>>

>>> sre.search('x.*?x', 'x%sx' % ('@'*16166,))
<SRE_Match object at 009D7A60>

>>> sre.search('x.*?x', 'x%sx' % ('@'*16167,))  <-- here it fails again
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "D:\Python20\lib\sre.py", line 47, in search
    return _compile(pattern, flags).search(string)
RuntimeError: maximum recursion limit exceeded

>>> sre.search('x.*?x', 'x%sx' % ('@'*16167,))  <-- continues to fail
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "D:\Python20\lib\sre.py", line 47, in search
    return _compile(pattern, flags).search(string)
RuntimeError: maximum recursion limit exceeded



Follow-Ups:

Date: 2000-Sep-30 21:19
By: gvanrossum

Comment:
Any comments, Fredrik???
-------------------------------------------------------

Date: 2000-Oct-23 12:23
By: nshelley

Comment:
I am getting killed by this same bug!
#!/usr/bin/env python2.0
import re

output = """Using 

== Data Table ==
s	m:d	mb
3.300000	0.000104772187944365	-1.23330767339032e-15
3.200000	0.000103862130408037	-1.23481086168441e-15
3.100000	0.000102831826202984	-1.23643366708223e-15
3.000000	0.000101671354638586	-1.23819069775402e-15
2.900000	0.000100370082245968	-1.24009908383179e-15
2.800000	9.89166376398503e-05	-1.24217904419247e-15
2.700000	9.72988932844521e-05	-1.24445461136295e-15
2.600000	9.55039568198016e-05	-1.24695456774457e-15
2.500000	9.3518175238995e-05	-1.24971366756711e-15
2.400000	9.13271559565959e-05	-1.25277425005882e-15
2.300000	8.89158096852735e-05	-1.25618839559713e-15
2.200000	8.62684210547775e-05	-1.26002084671538e-15
2.100000	8.33687540802062e-05	-1.26435302405962e-15
2.000000	8.02002009414518e-05	-1.26928863786894e-15
1.900000	7.67459841300842e-05	-1.27496167015724e-15
1.800000	7.29894239935539e-05	-1.28154795600633e-15
1.700000	6.89142864097651e-05	-1.28928236065365e-15
1.600000	6.45052296412595e-05	-1.29848488989922e-15
1.500000	5.97483776126083e-05	-1.30960148694006e-15
1.400000	5.46320649249439e-05	-1.32326977154928e-15
1.300000	4.91478435825781e-05	-1.3404286750276e-15
1.200000	4.32919623998454e-05	-1.36250830892367e-15
1.100000	3.70678871330223e-05	-1.39177202537724e-15
1.000000	3.04915786576429e-05	-1.43195494399345e-15
0.900000	2.36052666077545e-05	-1.48947100843164e-15
0.800000	1.65202853321069e-05	-1.57551564136398e-15
0.700000	9.56073716566518e-06	-1.70791288744525e-15
0.600000	3.67125710597e-06	-1.89923336361812e-15
0.500000	6.00021904261974e-07	-2.08381565027337e-15
0.400000	4.27864345038415e-08	-2.14973379503184e-15
0.300000	2.5741570279509e-09	-2.15852923041729e-15
0.200000	1.60325700603365e-10	-2.15762110254924e-15
0.100000	1.10181009347061e-11	-2.15430351925385e-15
0.000000	9.18460199298261e-13	-2.14607756126421e-15
-0.100000	8.2907448480307e-14	-2.13154544128925e-15
-0.200000	9.49291906644266e-15	-2.09562596113738e-15
-0.300000	2.57398712712903e-15	-1.89144055818718e-15
-0.400000	1.23896929747012e-15	-1.18482371296596e-15
-0.500000	4.77088843470797e-16	-4.74259070979461e-16
3.300000	0.000725333230235404	-1.60279744215745e-14
3.200000	0.000698989627849489	-1.57983897758426e-14
3.100000	0.000672395787137216	-1.55721529060957e-14
3.000000	0.000645566845212758	-1.53549883971193e-14
2.900000	0.000618516906916818	-1.51624220311135e-14
2.800000	0.000591259277466284	-1.50347782956977e-14
2.700000	0.000563806714724985	-1.5069525306854e-14
2.600000	0.000536171704020601	-1.54848062262748e-14
2.500000	0.000508366761845922	-1.67334737461837e-14
2.400000	0.000480404778779427	-1.96904798125589e-14
2.300000	0.00045229941701671	-2.59347024715496e-14
2.200000	0.000424065584744255	-3.81354821168744e-14
2.100000	0.000395720019338978	-6.05316531752639e-14
2.000000	0.000367282025836478	-9.9457021513997e-14
1.900000	0.000338774439198852	-1.63825993533288e-13
1.800000	0.000310224913488982	-2.65456611717139e-13
1.700000	0.000281667696431468	-4.19089961445906e-13
1.600000	0.000253146138686846	-6.4197984099406e-13
1.500000	0.000224716340367884	-9.52983499747302e-13
1.400000	0.00019645260393449	-1.37117106753005e-12
1.300000	0.000168455842857815	-1.9140171376089e-12
1.200000	0.000140866992561325	-2.5949957749272e-12
1.100000	0.000113889209694637	-3.419066099784e-12
1.000000	8.78261401150504e-05	-4.36958009251635e-12
0.900000	6.31506490822963e-05	-5.36461118003355e-12
0.800000	4.06312963119592e-05	-6.12577475587495e-12
0.700000	2.15481889941145e-05	-5.92418822150058e-12
0.600000	7.87604367966821e-06	-3.80859906972703e-12
0.500000	1.3904896761789e-06	-9.79870732426348e-13
0.400000	1.06064890626322e-07	-9.39992702457847e-14
0.300000	6.34950130197645e-09	-1.65503941397823e-14
0.200000	3.88292805625561e-10	-1.16204226732226e-14
0.100000	2.57865399432747e-11	-1.11870703136006e-14
0.000000	2.05458930149398e-12	-1.09482596289954e-14
-0.100000	1.85578779234532e-13	-1.06729449780495e-14
-0.200000	2.5577583052963e-14	-1.02232392679007e-14
-0.300000	1.05769385343133e-14	-9.2322860676878e-15
-0.400000	8.00273522170935e-15	-7.88228414475344e-15
-0.500000	6.51965630664677e-15	-6.50815076902941e-15
3.300000	0.000778073989265561	-1.65574096734398e-07
3.200000	0.00074963150963251	-1.92244746339178e-07
3.100000	0.000721015586364691	-2.21197891556889e-07
3.000000	0.000692226507232058	-2.52254070463242e-07
2.900000	0.000663264988754168	-2.85152554002688e-07
2.800000	0.000634132321079485	-3.19546222567145e-07
2.700000	0.000604830546549725	-3.54998299569146e-07
2.600000	0.000575362679604795	-3.90981285317844e-07
2.500000	0.000545732977654778	-4.26878409205096e-07
2.400000	0.000515947275272665	-4.61987879332959e-07
2.300000	0.000486013397947319	-4.95530155074015e-07
2.200000	0.000455941677304999	-5.26658398699649e-07
2.100000	0.000425745598153737	-5.54472176489517e-07
2.000000	0.000395442620520435	-5.78034377120716e-07
1.900000	0.000365055239615154	-5.96391194651538e-07
1.800000	0.000334612377612625	-6.0859488246625e-07
1.700000	0.000304151250425071	-6.13728816719563e-07
1.600000	0.000273719932661724	-6.1093419812057e-07
1.500000	0.000243380977243086	-5.99437433988553e-07
1.400000	0.000213216675616044	-5.78576796961394e-07
1.300000	0.000183336956663227	-5.47826196051382e-07
1.200000	0.000153891700661593	-5.06812695554088e-07
1.100000	0.000125090796710056	-4.55323667088038e-07
1.000000	9.7238530664174e-05	-3.9330616509577e-07
0.900000	7.07959411929754e-05	-3.20910962327376e-07
0.800000	4.64992533700793e-05	-2.38877973057319e-07
0.700000	2.55795422135307e-05	-1.50458199069334e-07
0.600000	1.00314893206752e-05	-6.74343626580743e-08
0.500000	2.00947524041218e-06	-1.48839482947924e-08
0.400000	1.67232105200131e-07	-1.2816627677716e-09
0.300000	1.00809637284154e-08	-7.82708572696571e-11
0.200000	6.12196843592758e-10	-4.83619605089934e-12
0.100000	4.0027953235145e-11	-3.39466185939354e-13
0.000000	3.1163322565507e-12	-4.38427713973686e-14
-0.100000	2.82036148373174e-13	-2.01235539818538e-14
-0.200000	4.04726306794353e-14	-1.75747562532315e-14
-0.300000	1.83397331593843e-14	-1.63366924660679e-14
-0.400000	1.50709750319906e-14	-1.48901998089388e-14
-0.500000	1.34240392889815e-14	-1.34063683071726e-14
3.300000	0.000104772187944365	-1.23330767339032e-15
3.200000	0.000103862130408037	-1.23481086168441e-15
3.100000	0.000102831826202984	-1.23643366708223e-15
3.000000	0.000101671354638586	-1.23819069775402e-15
2.900000	0.000100370082245968	-1.24009908383179e-15
2.800000	9.89166376398503e-05	-1.24217904419247e-15
2.700000	9.72988932844521e-05	-1.24445461136295e-15
2.600000	9.55039568198016e-05	-1.24695456774457e-15
2.500000	9.3518175238995e-05	-1.24971366756711e-15
2.400000	9.13271559565959e-05	-1.25277425005882e-15
2.300000	8.89158096852735e-05	-1.25618839559713e-15
2.200000	8.62684210547775e-05	-1.26002084671538e-15
2.100000	8.33687540802062e-05	-1.26435302405962e-15
2.000000	8.02002009414518e-05	-1.26928863786894e-15
1.900000	7.67459841300842e-05	-1.27496167015724e-15
1.800000	7.29894239935539e-05	-1.28154795600633e-15
1.700000	6.89142864097651e-05	-1.28928236065365e-15
1.600000	6.45052296412595e-05	-1.29848488989922e-15
1.500000	5.97483776126083e-05	-1.30960148694006e-15
1.400000	5.46320649249439e-05	-1.32326977154928e-15
1.300000	4.91478435825781e-05	-1.3404286750276e-15
1.200000	4.32919623998454e-05	-1.36250830892367e-15
1.100000	3.70678871330223e-05	-1.39177202537724e-15
1.000000	3.04915786576429e-05	-1.43195494399345e-15
0.900000	2.36052666077545e-05	-1.48947100843164e-15
0.800000	1.65202853321069e-05	-1.57551564136398e-15
0.700000	9.56073716566518e-06	-1.70791288744525e-15
0.600000	3.67125710597e-06	-1.89923336361812e-15
0.500000	6.00021904261974e-07	-2.08381565027337e-15
0.400000	4.27864345038415e-08	-2.14973379503184e-15
0.300000	2.5741570279509e-09	-2.15852923041729e-15
0.200000	1.60325700603365e-10	-2.15762110254924e-15
0.100000	1.10181009347061e-11	-2.15430351925385e-15
0.000000	9.18460199298261e-13	-2.14607756126421e-15
-0.100000	8.2907448480307e-14	-2.13154544128925e-15
-0.200000	9.49291906644266e-15	-2.09562596113738e-15
-0.300000	2.57398712712903e-15	-1.89144055818718e-15
-0.400000	1.23896929747012e-15	-1.18482371296596e-15
-0.500000	4.77088843470797e-16	-4.74259070979461e-16
3.300000	0.000725333230235404	-1.60279744215745e-14
3.200000	0.000698989627849489	-1.57983897758426e-14
3.100000	0.000672395787137216	-1.55721529060957e-14
3.000000	0.000645566845212758	-1.53549883971193e-14
2.900000	0.000618516906916818	-1.51624220311135e-14
2.800000	0.000591259277466284	-1.50347782956977e-14
2.700000	0.000563806714724985	-1.5069525306854e-14
2.600000	0.000536171704020601	-1.54848062262748e-14
2.500000	0.000508366761845922	-1.67334737461837e-14
2.400000	0.000480404778779427	-1.96904798125589e-14
2.300000	0.00045229941701671	-2.59347024715496e-14
2.200000	0.000424065584744255	-3.81354821168744e-14
2.100000	0.000395720019338978	-6.05316531752639e-14
2.000000	0.000367282025836478	-9.9457021513997e-14
1.900000	0.000338774439198852	-1.63825993533288e-13
1.800000	0.000310224913488982	-2.65456611717139e-13
1.700000	0.000281667696431468	-4.19089961445906e-13
1.600000	0.000253146138686846	-6.4197984099406e-13
1.500000	0.000224716340367884	-9.52983499747302e-13
1.400000	0.00019645260393449	-1.37117106753005e-12
1.300000	0.000168455842857815	-1.9140171376089e-12
1.200000	0.000140866992561325	-2.5949957749272e-12
1.100000	0.000113889209694637	-3.419066099784e-12
1.000000	8.78261401150504e-05	-4.36958009251635e-12
0.900000	6.31506490822963e-05	-5.36461118003355e-12
0.800000	4.06312963119592e-05	-6.12577475587495e-12
0.700000	2.15481889941145e-05	-5.92418822150058e-12
0.600000	7.87604367966821e-06	-3.80859906972703e-12
0.500000	1.3904896761789e-06	-9.79870732426348e-13
0.400000	1.06064890626322e-07	-9.39992702457847e-14
0.300000	6.34950130197645e-09	-1.65503941397823e-14
0.200000	3.88292805625561e-10	-1.16204226732226e-14
0.100000	2.57865399432747e-11	-1.11870703136006e-14
0.000000	2.05458930149398e-12	-1.09482596289954e-14
-0.100000	1.85578779234532e-13	-1.06729449780495e-14
-0.200000	2.5577583052963e-14	-1.02232392679007e-14
-0.300000	1.05769385343133e-14	-9.2322860676878e-15
-0.400000	8.00273522170935e-15	-7.88228414475344e-15
-0.500000	6.51965630664677e-15	-6.50815076902941e-15
"""

re.search("== Data Table ==\n(.*?)\n(.*?)\s*$", output, re.S)


-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115696&group_id=5470


From noreply@sourceforge.net  Mon Oct 23 21:06:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Oct 2000 13:06:54 -0700
Subject: [Python-bugs-list] [Bug #117524] The unicodedata db does not know about the special ranges.
Message-ID: <200010232006.NAA24740@sf-web1.i.sourceforge.net>

Bug #117524, was updated on 2000-Oct-23 13:06
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: The unicodedata db does not know about the special ranges.

Details: There seems to a bug in the unicodedata. The special ranges described under "Field Formats" are not handled correctly.

   ftp://ftp.unicode.org/Public/3.0-Update/UnicodeData-3.0.0.html

The two characters should have identical properties:

Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import unicodedata
>>> unicodedata.category(u"\u3400")
'Lo'
>>> unicodedata.category(u"\u3401")
'Cn'
>>> u"\u3400".isalpha()
1
>>> u"\u3401".isalpha()
0
>>>

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117524&group_id=5470


From noreply@sourceforge.net  Tue Oct 24 02:13:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Oct 2000 18:13:52 -0700
Subject: [Python-bugs-list] [Bug #117464] clash with BSD db when building
Message-ID: <200010240113.SAA25295@sf-web2.i.sourceforge.net>

Bug #117464, was updated on 2000-Oct-23 00:29
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: clash with BSD db when building

Details: On RH7.0, beside the LONG_BIT issue, I came across a db.h missmatch. 
The preprocessor directive values used in bsddbmodule.c correspond to the /usr/include/db1/db.h file, but on my system, /usr/include/db.h points to db3/db.h which does not define the same set of values, and does not compile.

Compiling with the old file works, but obviously it does not link...

configure (with no options) ran trouble free.

The system is:
RedHat 7.0
gcc version 2.96 20000731 (yes with the LONG_BIT problem) 
Python 2.0 final release

Regards,
Pascal    

Follow-Ups:

Date: 2000-Oct-23 18:13
By: fleury

Comment:
Well, I also tried at home, where I have a vanilla RH7.0 and it compiles perfectly.
The reported bug was on a RH6.2->RH7.0 upgraded machine.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117464&group_id=5470


From noreply@sourceforge.net  Tue Oct 24 02:18:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Oct 2000 18:18:47 -0700
Subject: [Python-bugs-list] [Bug #117556] Python 2.0 regression fails on test_pyexpat.
Message-ID: <200010240118.SAA26082@sf-web3.vaspecialprojects.com>

Bug #117556, was updated on 2000-Oct-23 18:18
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Python 2.0 regression fails on test_pyexpat.

Details: Regression fails on test_pyexpat with the following message:

test test_pyexpat failed -- Writing: "('xml=http://www.w3.org/XML/1998/namespace\\014external_entity', None, 'entity.file', None)", expected: "('http://www.python.org/namespace=http://www.w3.org/XML/1998/namespace\\014external_entity'"

This is on Python 2.0 final with expat 1.2 both compiled on Solaris 7 x86 with SunPro 4.2.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117556&group_id=5470


From noreply@sourceforge.net  Tue Oct 24 04:34:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 23 Oct 2000 20:34:00 -0700
Subject: [Python-bugs-list] [Bug #117556] Python 2.0 regression fails on test_pyexpat.
Message-ID: <200010240334.UAA31694@sf-web1.i.sourceforge.net>

Bug #117556, was updated on 2000-Oct-23 18:18
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Python 2.0 regression fails on test_pyexpat.

Details: Regression fails on test_pyexpat with the following message:

test test_pyexpat failed -- Writing: "('xml=http://www.w3.org/XML/1998/namespace\\014external_entity', None, 'entity.file', None)", expected: "('http://www.python.org/namespace=http://www.w3.org/XML/1998/namespace\\014external_entity'"

This is on Python 2.0 final with expat 1.2 both compiled on Solaris 7 x86 with SunPro 4.2.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117556&group_id=5470


From noreply@sourceforge.net  Tue Oct 24 16:15:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 24 Oct 2000 08:15:42 -0700
Subject: [Python-bugs-list] [Bug #117606] *.so creation in solaris+GCC
Message-ID: <200010241515.IAA06058@sf-web1.i.sourceforge.net>

Bug #117606, was updated on 2000-Oct-24 08:15
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: *.so creation in solaris+GCC

Details: Python 2.0 (dinamic modules)
Mod_Python 2.6.2 (dinamic module)
GCC 2.95.2
Apache 1.3.14 (dinamic modules)
SunOS5 (Solaris 2.x)

I send the email also to "mod_python" mailing list since I detect the problem using this package. Other developers could see the very same problem!.


Mod_python runs smoothly until I do a "import zlib", for example, in a handler. In this case, the request is aborted with the following log:

>>>>>
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache: Traceback (most recent call last):
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache:   File "/usr/local/lib/python2.0/site-packages/mod_python/apache.py", line 185, in Dispatch
    result = object(self.req)
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache:   File "/export/home/webmaster/www.argo.es/servicios/cache.py", line 47, in handler
    exec(cache[f][1])
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache:   File "/export/home/webmaster/www.argo.es/servicios/borra_email", line 183, in ?
    req2=wrap(req)
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache:   File "/export/home/webmaster/www.argo.es/servicios/borra_email", line 159, in __init__
    import zlib
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache: ImportError: ld.so.1: /opt/local/apache/bin/httpd: fatal: relocation error: file /usr/local/lib/python2.0/lib-dynload/zlibmodule.so: symbol main: referenced symbol not found
<<<<<

That is, "zlibmodule.so" tries to link to a function called "main".

Doing a "nm object|grep main", I see the unresolved reference in "zlibmodule.so", but not in "zlibmodule.o". So, the problem seems to be the creation of the shared library.

I tracked down the problem to the "configure" script: "cc -G" is (I think) the right thing to do to create a shared library if you are using the Sun compiler, but if you are using GCC (like me), the right command is "gcc -shared".

Patch for Python 2.0:

>>>>>
Index: configure
===================================================================
RCS file: /opt/src/cvsroot/python/configure,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.2.1
diff -c -r1.1.1.2 -r1.1.1.2.2.1
*** configure   2000/10/18 19:06:44     1.1.1.2
--- configure   2000/10/24 14:19:01     1.1.1.2.2.1
***************
*** 2650,2656 ****
        SunOS/4*) LDSHARED="ld";;
        SunOS/5*) 
                if test "$GCC" = "yes"
!               then LDSHARED='$(CC) -G'
                else LDSHARED="ld -G";
                fi ;;
        hp*|HP*) LDSHARED="ld -b";;
--- 2650,2656 ----
        SunOS/4*) LDSHARED="ld";;
        SunOS/5*) 
                if test "$GCC" = "yes"
!               then LDSHARED='$(CC) -shared'
                else LDSHARED="ld -G";
                fi ;;
        hp*|HP*) LDSHARED="ld -b";;
Index: configure.in
===================================================================
RCS file: /opt/src/cvsroot/python/configure.in,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.2.1
diff -c -r1.1.1.2 -r1.1.1.2.2.1
*** configure.in        2000/10/18 19:06:45     1.1.1.2
--- configure.in        2000/10/24 14:19:03     1.1.1.2.2.1
***************
*** 564,570 ****
        SunOS/4*) LDSHARED="ld";;
        SunOS/5*) 
                if test "$GCC" = "yes"
!               then LDSHARED='$(CC) -G'
                else LDSHARED="ld -G";
                fi ;;
        hp*|HP*) LDSHARED="ld -b";;
--- 564,570 ----
        SunOS/4*) LDSHARED="ld";;
        SunOS/5*) 
                if test "$GCC" = "yes"
!               then LDSHARED='$(CC) -shared'
                else LDSHARED="ld -G";
                fi ;;
        hp*|HP*) LDSHARED="ld -b";;
<<<<<


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117606&group_id=5470


From noreply@sourceforge.net  Tue Oct 24 16:51:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 24 Oct 2000 08:51:26 -0700
Subject: [Python-bugs-list] [Bug #117608]  test_largefile crashes
Message-ID: <200010241551.IAA02975@sf-web3.vaspecialprojects.com>

Bug #117608, was updated on 2000-Oct-24 08:51
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary:  test_largefile crashes

Details: During "make test",  test_largefile caused an error.

Here's the result in python:

% python python2.0/test/test_largefile.py
create large file via seek (may be sparse file) ...
Traceback (most recent call last):
  File "python2.0/test/test_largefile.py", line 60, in ?
    f.flush()
IOError: [Errno 22] Invalid argument

Here's the version I'm running:

Python 2.0 (#5, Oct 24 2000, 09:51:57) [C] on irix6


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117608&group_id=5470


From noreply@sourceforge.net  Tue Oct 24 18:17:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 24 Oct 2000 10:17:38 -0700
Subject: [Python-bugs-list] [Bug #117524] The unicodedata db does not know about the special ranges.
Message-ID: <200010241717.KAA07442@sf-web1.i.sourceforge.net>

Bug #117524, was updated on 2000-Oct-23 13:06
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: The unicodedata db does not know about the special ranges.

Details: There seems to a bug in the unicodedata. The special ranges described under "Field Formats" are not handled correctly.

   ftp://ftp.unicode.org/Public/3.0-Update/UnicodeData-3.0.0.html

The two characters should have identical properties:

Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import unicodedata
>>> unicodedata.category(u"\u3400")
'Lo'
>>> unicodedata.category(u"\u3401")
'Cn'
>>> u"\u3400".isalpha()
1
>>> u"\u3401".isalpha()
0
>>>

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117524&group_id=5470


From noreply@sourceforge.net  Tue Oct 24 18:25:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 24 Oct 2000 10:25:25 -0700
Subject: [Python-bugs-list] [Bug #117556] Python 2.0 regression fails on test_pyexpat.
Message-ID: <200010241725.KAA01398@sf-web2.i.sourceforge.net>

Bug #117556, was updated on 2000-Oct-23 18:18
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Python 2.0 regression fails on test_pyexpat.

Details: Regression fails on test_pyexpat with the following message:

test test_pyexpat failed -- Writing: "('xml=http://www.w3.org/XML/1998/namespace\\014external_entity', None, 'entity.file', None)", expected: "('http://www.python.org/namespace=http://www.w3.org/XML/1998/namespace\\014external_entity'"

This is on Python 2.0 final with expat 1.2 both compiled on Solaris 7 x86 with SunPro 4.2.

Follow-Ups:

Date: 2000-Oct-24 10:25
By: garthc

Comment:
Submitted by garthc (was not registered at the time).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117556&group_id=5470


From noreply@sourceforge.net  Tue Oct 24 19:01:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 24 Oct 2000 11:01:31 -0700
Subject: [Python-bugs-list] [Bug #117612] sre gives wrong groups with findall and empty groups
Message-ID: <200010241801.LAA02077@sf-web2.i.sourceforge.net>

Bug #117612, was updated on 2000-Oct-24 11:01
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: sre gives wrong groups with findall and empty groups

Details: the following:

r = re.compile (r'(a|(b))')
print r.findall (r'aba')

produces with sre

[('a', ''), ('b', 'b'), ('a', 'b')]

instead of the correct behaviour of pre (and Python 1.5.2)

[('a', ''), ('b', 'b'), ('a', '')]

(Note the wrong 'b' in the last tuple. It seems like groups are not initialized and keep the value of the previous match).

Tested with BeOpen Python 2.0 final (Oct. 16th) under Linux 2.2.14 (S.u.S.E 6.4)

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117612&group_id=5470


From noreply@sourceforge.net  Tue Oct 24 20:21:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 24 Oct 2000 12:21:40 -0700
Subject: [Python-bugs-list] [Bug #117612] sre gives wrong groups with findall and empty groups
Message-ID: <200010241921.MAA09849@sf-web1.i.sourceforge.net>

Bug #117612, was updated on 2000-Oct-24 11:01
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: sre gives wrong groups with findall and empty groups

Details: the following:

r = re.compile (r'(a|(b))')
print r.findall (r'aba')

produces with sre

[('a', ''), ('b', 'b'), ('a', 'b')]

instead of the correct behaviour of pre (and Python 1.5.2)

[('a', ''), ('b', 'b'), ('a', '')]

(Note the wrong 'b' in the last tuple. It seems like groups are not initialized and keep the value of the previous match).

Tested with BeOpen Python 2.0 final (Oct. 16th) under Linux 2.2.14 (S.u.S.E 6.4)

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117612&group_id=5470


From noreply@sourceforge.net  Tue Oct 24 20:22:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 24 Oct 2000 12:22:54 -0700
Subject: [Python-bugs-list] [Bug #117608]  test_largefile crashes
Message-ID: <200010241922.MAA09891@sf-web1.i.sourceforge.net>

Bug #117608, was updated on 2000-Oct-24 08:51
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary:  test_largefile crashes

Details: During "make test",  test_largefile caused an error.

Here's the result in python:

% python python2.0/test/test_largefile.py
create large file via seek (may be sparse file) ...
Traceback (most recent call last):
  File "python2.0/test/test_largefile.py", line 60, in ?
    f.flush()
IOError: [Errno 22] Invalid argument

Here's the version I'm running:

Python 2.0 (#5, Oct 24 2000, 09:51:57) [C] on irix6


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117608&group_id=5470


From noreply@sourceforge.net  Tue Oct 24 21:00:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 24 Oct 2000 13:00:05 -0700
Subject: [Python-bugs-list] [Bug #117329] Compile Python 2.0 on BSDI BSD/OS 4.0.1 fails
Message-ID: <200010242000.NAA04283@sf-web2.i.sourceforge.net>

Bug #117329, was updated on 2000-Oct-20 10:08
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Compile Python 2.0 on BSDI BSD/OS 4.0.1 fails

Details: When compiling Python 2.0. on BSDI BSD/OS 4.0.1

Configure
     ./configure --prefix=/usr/home/sud2000/python --with-                  threads=no
     no problem

make

     After a lot of warnings like :

        .........
   /usr/include/math.h:177: warning: function declaration
             isn't a prototype
   /usr/include/math.h:257: warning: function declaration
             isn't a prototype
        ........

The compile failed with this message :

   /usr/home/......./Python-2.0/Objects/fileobject.c:274:
                      undefined reference to `TELL64'
   *** Error code 1

        Stop.
   *** Error code 1


Follow-Ups:

Date: 2000-Oct-24 13:00
By: dkwolfe

Comment:
The warnings also appear under Darwin as the BSD header files have issues with prototypes.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117329&group_id=5470


From noreply@sourceforge.net  Tue Oct 24 21:38:41 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 24 Oct 2000 13:38:41 -0700
Subject: [Python-bugs-list] [Bug #117070] README instructions for configuring Setup are not helpful
Message-ID: <200010242038.NAA04996@sf-web2.i.sourceforge.net>

Bug #117070, was updated on 2000-Oct-17 02:54
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 6
Summary: README instructions for configuring Setup are not helpful

Details: The instructions in the README file for configuring the Setup file are not useful. There is no indication of when you are supposed to edit the file. So far as I can tell the only way to configure python is either:

  ./configure
  make
  vim Modules/Setup
  make

or:

  ./configure
  vim Modules/Setup.in
  make

neither of which are particularly satisfactory.

The README file simply says "if [the Setup file] does not exist yet, make a copy yourself", without any indication of how you actually do this. 'make Setup' in the Modules directory does not work because there is no Makefile in the Modules directory yet.

Follow-Ups:

Date: 2000-Oct-18 16:28
By: none

Comment:
in my copy of the README file, there's a section called
"Build instructions", which tells you to build a basic interpreter (configure, make), and then tells you to see the sections on "testing", "configuring additional modules", and "installation"...

sounds like you only read the "configuring additional modules" section...

(satisfactory or not, it's a good idea to make sure the interpreter builds cleanly on your platform *before* you start fiddling with the extension modules...)

</F>
-------------------------------------------------------

Date: 2000-Oct-18 17:28
By: jribbens

Comment:
Your README must be different to mine, mine says "Before you can build Python, you must first configure it."

The method that you are proposing is completely counter-intuitive and is precisely what you *must not* do when compiling most other programs.

If this is what you are supposed to do then it needs to say so in BIG LETTERS.
-------------------------------------------------------

Date: 2000-Oct-24 13:37
By: fdrake

Comment:
This is a case of "RTFM, from the top".  There's no need to change the content of the README.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117070&group_id=5470


From noreply@sourceforge.net  Tue Oct 24 21:37:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 24 Oct 2000 13:37:59 -0700
Subject: [Python-bugs-list] [Bug #117070] README instructions for configuring Setup are not helpful
Message-ID: <200010242037.NAA04972@sf-web2.i.sourceforge.net>

Bug #117070, was updated on 2000-Oct-17 02:54
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: Invalid
Bug Group: Not a Bug
Priority: 6
Summary: README instructions for configuring Setup are not helpful

Details: The instructions in the README file for configuring the Setup file are not useful. There is no indication of when you are supposed to edit the file. So far as I can tell the only way to configure python is either:

  ./configure
  make
  vim Modules/Setup
  make

or:

  ./configure
  vim Modules/Setup.in
  make

neither of which are particularly satisfactory.

The README file simply says "if [the Setup file] does not exist yet, make a copy yourself", without any indication of how you actually do this. 'make Setup' in the Modules directory does not work because there is no Makefile in the Modules directory yet.

Follow-Ups:

Date: 2000-Oct-18 16:28
By: none

Comment:
in my copy of the README file, there's a section called
"Build instructions", which tells you to build a basic interpreter (configure, make), and then tells you to see the sections on "testing", "configuring additional modules", and "installation"...

sounds like you only read the "configuring additional modules" section...

(satisfactory or not, it's a good idea to make sure the interpreter builds cleanly on your platform *before* you start fiddling with the extension modules...)

</F>
-------------------------------------------------------

Date: 2000-Oct-18 17:28
By: jribbens

Comment:
Your README must be different to mine, mine says "Before you can build Python, you must first configure it."

The method that you are proposing is completely counter-intuitive and is precisely what you *must not* do when compiling most other programs.

If this is what you are supposed to do then it needs to say so in BIG LETTERS.
-------------------------------------------------------

Date: 2000-Oct-24 13:37
By: fdrake

Comment:
This is a case of "RTFM, from the top".  There's no need to change the content of the README.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117070&group_id=5470


From noreply@sourceforge.net  Tue Oct 24 22:01:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 24 Oct 2000 14:01:58 -0700
Subject: [Python-bugs-list] [Bug #114027] Compiling on alpha-osf1v4: libpthreads is called libpthread
Message-ID: <200010242101.OAA11752@sf-web1.i.sourceforge.net>

Bug #114027, was updated on 2000-Sep-10 22:43
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 1
Summary: Compiling on alpha-osf1v4: libpthreads is called libpthread

Details: change -lpthreads into -lpthread

Follow-Ups:

Date: 2000-Sep-16 09:59
By: gvanrossum

Comment:
I don't have enough information to resolve this problem.
What Python version were you using?

Did you use the configure script? It should automtically select -lpthreads or -lpthread depending on which one is present. Did this fail for you? Please check the config.log file to find out more about this.

Since I don't have an Alpha OSF1v1 system, I can't debug this for you!
-------------------------------------------------------

Date: 2000-Sep-18 08:01
By: janw

Comment:
Python-2.0b1, with configure. And it looks like configure doesn't get this right.

I asked a colleague to look a bit more into this. He found the following:
1) You can use either pthreads? or decthreads. If you call configure with decthreads it compiles and runs fine, but the manpage says that decthreads are only there for backwards compatibility.
2) In the pthreads? case there are different possibilities:
- You can include the phtread.h file or not.
- You can call pthread_create with arguments or not.
- You can link with -lpthread or with -lpthreads
The manpage for pthread(2) suggests to use the compiler option -pthread, which boils down to cc -D_REENTRANT and ld -lpthread -lexc (modulo other options).
It looks like configure tries with a testfile without including pthread.h, thusly -lpthreads gets used. The sources *do* include pthread.h, but then you have to link against -lpthread.
Suggested fix: Change configure test file so that pthread.h gets included and call pthread_create(0,0,0,0) (eg. give four dummy arguments).
This works for OSF1, but we did not test if it breaks anything on other platforms.

Hope you can understand the description.
-------------------------------------------------------

Date: 2000-Oct-06 10:23
By: gvanrossum

Comment:
I'm afraid I can't quite decypher what you meant by your (clearly well-intended!) diagnosis. Do you think you could whip up a patch for configure.in? (Your suggestion to change the configure test is not specific enough for me to figure oput what needs to be done.)
-------------------------------------------------------

Date: 2000-Oct-17 15:35
By: gvanrossum

Comment:
Can you check that this is fixed in the final release of Python 2.0 (on pythonlabs.com now)? We changed something for the OSF1 platform that should take care of this.

If you confirm it's fixed I'll close the bug report.
-------------------------------------------------------

Date: 2000-Oct-24 14:01
By: gvanrossum

Comment:
I haven't heard back from the submitter, but I'm closing this anyway, since according to Charles Waldman Python 2.0 (final) builds and runs fine on OSF1/Alpha.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114027&group_id=5470


From jon+sourceforge@unequivocal.co.uk  Tue Oct 24 22:16:44 2000
From: jon+sourceforge@unequivocal.co.uk (Jon Ribbens)
Date: Tue, 24 Oct 2000 22:16:44 +0100
Subject: [Python-bugs-list] Re: [Bug #117070] README instructions for configuring Setup are not helpful
In-Reply-To: <200010242038.NAA04996@sf-web2.i.sourceforge.net>; from noreply@sourceforge.net on Tue, Oct 24, 2000 at 01:38:41PM -0700
References: <200010242038.NAA04996@sf-web2.i.sourceforge.net>
Message-ID: <20001024221644.D24383@snowy.squish.net>

noreply@sourceforge.net wrote:
> This is a case of "RTFM, from the top".  There's no need to change
> the content of the README.

Thankyou for your patronising and incorrect remarks. You have clearly
not read what I actually put in my report. Should I re-submit the bug?
The instructions on the Setup procedure deserve more explanation about
what you're supposed to do, and my bug report deserves a better
response.


From noreply@sourceforge.net  Tue Oct 24 22:26:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 24 Oct 2000 14:26:56 -0700
Subject: [Python-bugs-list] [Bug #117070] README instructions for configuring Setup are not helpful
Message-ID: <200010242126.OAA12141@sf-web1.i.sourceforge.net>

Bug #117070, was updated on 2000-Oct-17 02:54
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: README instructions for configuring Setup are not helpful

Details: The instructions in the README file for configuring the Setup file are not useful. There is no indication of when you are supposed to edit the file. So far as I can tell the only way to configure python is either:

  ./configure
  make
  vim Modules/Setup
  make

or:

  ./configure
  vim Modules/Setup.in
  make

neither of which are particularly satisfactory.

The README file simply says "if [the Setup file] does not exist yet, make a copy yourself", without any indication of how you actually do this. 'make Setup' in the Modules directory does not work because there is no Makefile in the Modules directory yet.

Follow-Ups:

Date: 2000-Oct-18 16:28
By: none

Comment:
in my copy of the README file, there's a section called
"Build instructions", which tells you to build a basic interpreter (configure, make), and then tells you to see the sections on "testing", "configuring additional modules", and "installation"...

sounds like you only read the "configuring additional modules" section...

(satisfactory or not, it's a good idea to make sure the interpreter builds cleanly on your platform *before* you start fiddling with the extension modules...)

</F>
-------------------------------------------------------

Date: 2000-Oct-18 17:28
By: jribbens

Comment:
Your README must be different to mine, mine says "Before you can build Python, you must first configure it."

The method that you are proposing is completely counter-intuitive and is precisely what you *must not* do when compiling most other programs.

If this is what you are supposed to do then it needs to say so in BIG LETTERS.
-------------------------------------------------------

Date: 2000-Oct-24 13:37
By: fdrake

Comment:
This is a case of "RTFM, from the top".  There's no need to change the content of the README.
-------------------------------------------------------

Date: 2000-Oct-24 14:26
By: fdrake

Comment:
Jon insists that I'm wrong about this one, and another look leads me to think he's probably right.  (Sorry, Jon!)

I don't have time to revise the file now, but should be able to do so later tonight or in the morning.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117070&group_id=5470


From jon+sourceforge@unequivocal.co.uk  Tue Oct 24 22:29:18 2000
From: jon+sourceforge@unequivocal.co.uk (Jon Ribbens)
Date: Tue, 24 Oct 2000 22:29:18 +0100
Subject: [Python-bugs-list] Re: [Bug #117070] README instructions for configuring Setup are not helpful
In-Reply-To: <200010242126.OAA12141@sf-web1.i.sourceforge.net>; from noreply@sourceforge.net on Tue, Oct 24, 2000 at 02:26:56PM -0700
References: <200010242126.OAA12141@sf-web1.i.sourceforge.net>
Message-ID: <20001024222918.E24383@snowy.squish.net>

noreply@sourceforge.net wrote:
> Jon insists that I'm wrong about this one, and another look leads me to
> think he's probably right.  (Sorry, Jon!)

Thanks ;-)

Cheers


Jon (who doesn't like being called "invalid" ;-) )


From fdrake@acm.org  Tue Oct 24 22:27:42 2000
From: fdrake@acm.org (Fred L. Drake, Jr.)
Date: Tue, 24 Oct 2000 17:27:42 -0400 (EDT)
Subject: [Python-bugs-list] Re: [Bug #117070] README instructions for configuring Setup are not helpful
In-Reply-To: <20001024221644.D24383@snowy.squish.net>
References: <200010242038.NAA04996@sf-web2.i.sourceforge.net>
 <20001024221644.D24383@snowy.squish.net>
Message-ID: <14837.65230.977574.69777@cj42289-a.reston1.va.home.com>

Jon Ribbens writes:
 > Thankyou for your patronising and incorrect remarks. You have clearly
 > not read what I actually put in my report. Should I re-submit the bug?

Jon,
  I had no intention of being patronizing, and apologize if I sounded
that way.

 > The instructions on the Setup procedure deserve more explanation about
 > what you're supposed to do, and my bug report deserves a better
 > response.

  I've taken another look, reading a little slower, and think that
while the instructions are there, they're not very clear on some
points and can be improved.  I'll take a stab at that tonight or in
the morning.
  Again, I don't mean to give insufficient consideration to your bug
report (or any other bug report); please accept my apology if I've
been hasty.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs Team Member



From noreply@sourceforge.net  Wed Oct 25 15:10:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Oct 2000 07:10:24 -0700
Subject: [Python-bugs-list] [Bug #117684] IDLE stack browser display problem
Message-ID: <200010251410.HAA28606@sf-web1.i.sourceforge.net>

Bug #117684, was updated on 2000-Oct-25 07:10
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: IDLE stack browser display problem

Details: IDLE doesn't properly display variables whose string
representation contains a newline.

The second line of those variables gets overwritten
by the next variable in the stack display.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117684&group_id=5470


From noreply@sourceforge.net  Wed Oct 25 15:25:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Oct 2000 07:25:37 -0700
Subject: [Python-bugs-list] [Bug #117686] IDLE doesn't display long arrays well
Message-ID: <200010251425.HAA28971@sf-web1.i.sourceforge.net>

Bug #117686, was updated on 2000-Oct-25 07:25
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: IDLE doesn't display long arrays well

Details: A long array, such as from Numeric Python is displayed
as
<array 3434 343421 4324234 .... 324234 34234>,
with part of the array replaced with elipses.

Often, this is enough information,
but unfortunately not always.  IDLE cannot tell you
how many items the array had (even approximately),
and it is impossible to see the complete output
or repr().  This is a bug, as a stack viewer ought to
let you see what is on the stack.

I'd suggest that long reprs() that get truncated this way
ought to be viewable in their entirety, perhaps by clicking
on them.

A fancier option would be to have IDLE look for a getitem()
attribute, and allow anything that has getitem() (or perhaps
getitem() and len()) to be displayed in the same format
that build-in python arrays are displayed in.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117686&group_id=5470


From noreply@sourceforge.net  Wed Oct 25 15:28:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Oct 2000 07:28:00 -0700
Subject: [Python-bugs-list] [Bug #114923] ToolTip not showing text on AIX 4.3
Message-ID: <200010251428.HAA29031@sf-web1.i.sourceforge.net>

Bug #114923, was updated on 2000-Sep-20 14:27
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: ToolTip not showing text on AIX 4.3

Details: IDLE0.6 runs nicely on AIX except that the tip text itself does not show when the pop up box appears. The box seems to be sized properly but is blank.

-Robin Friedrich

Follow-Ups:

Date: 2000-Sep-20 16:54
By: gvanrossum

Comment:
Could it be a Tcl version problem? It's hard to debug this... :-(
-------------------------------------------------------

Date: 2000-Sep-21 14:17
By: none

Comment:
Yes I imagine it will be hard to debug. The tclTk version is 8.3.2. I am unaware of problems with that on the X windows platforms. Has this been noticed on other unices with 2.0b1?  --Robin F.
-------------------------------------------------------

Date: 2000-Sep-21 14:23
By: gvanrossum

Comment:
BTW, where do you expect to see tooltips? The only place I can think of is when you type a function name followed by a left paren. Is that it? What function name did you use?

(And yes, this works fine for me on Linux.)

Could it have to do with font? color? Perhaps your window manager?
Source is in CallTipWindow.py if you want to play.
-------------------------------------------------------

Date: 2000-Sep-25 11:39
By: none

Comment:
The open paren binding yes. Any function like those in the string module.
OK I've played with CallTipWindow.py and the main() test routine exhibits the bug nicely. The code looks dead simple and should work. I can only blame Tk 8.3.2. I tried linking in our old Tk 8.0 libraries/headers (hoping Tkinter was still compatible with it) and the tooltip call now raises the following. We are using X/Motif with the CDE window manager.

>>> idle.CallTipWindow.main()
>>> Exception in Tkinter callback
Traceback (most recent call last):
  File "./Lib/lib-tk/Tkinter.py", line 1283, in __call__
    args = apply(self.subst, args)
  File "./Lib/lib-tk/Tkinter.py", line 1053, in _substitute
    e.delta = getint(D)
ValueError: invalid literal for int(): D




-------------------------------------------------------

Date: 2000-Sep-25 12:41
By: gvanrossum

Comment:
The getint(D) problem is because earlier versions of Tkinter don't support the mousewheel delta value.

Try again with the current CVS version (or wait 1.5 days for Python 2.0b2 to be released). The getint(D) problem should be solved in the CVS version (a try/except is put around it).
-------------------------------------------------------

Date: 2000-Sep-25 13:37
By: none

Comment:
I tried to trap the error and go on but then the test still fails to show text in the tooltip window with 8.0 Tk. I'm kinda stumped at this point.   Do you know of any other AIX users which I could pester instead of you?

-Robin F.
-------------------------------------------------------

Date: 2000-Oct-13 07:49
By: gvanrossum

Comment:
Hi Robin, I don't know of any other AIX users -- Vladimir Marangozov is in the middle of a move and hasn't resurfaced yet. (You can always try python-list@python.org of course.)

You could try to upgrade to Tcl/tk 8.3 -- I'm suspecting a Tcl or Tk error at this point and AIX is a minority platform for them too...

Also, try the CVS version of _tkinter.c (or wait for 2.0final) -- yesterday I checked in a change that avoids using interp->result, which is deprecated and caused (different) problems on Windows. Who knows. Just a lark.
-------------------------------------------------------

Date: 2000-Oct-25 07:28
By: gpk

Comment:
I see the same problem on Solaris 2.6, python 1.6 final,
TCL  8.3 .
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114923&group_id=5470


From noreply@sourceforge.net  Wed Oct 25 16:24:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Oct 2000 08:24:57 -0700
Subject: [Python-bugs-list] [Bug #117691] Unable to run windows installer in windows 2000
Message-ID: <200010251524.IAA30249@sf-web1.i.sourceforge.net>

Bug #117691, was updated on 2000-Oct-25 08:24
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Unable to run windows installer in windows 2000

Details: Keep getting messagebox title 'Application Error' with text 'WOWEXEC caused a General Protection Fault in module KRNL386.EXE at 0001:8D7A.     Choose Close. WOWEXEC will close.'

Assume this is somehow to do with my setup, but at a loss to explain it.

File opens OK in WinZip, and Test gives no errors. Single warning was...

warning [D:/Documents and Settings/sh/My Documents/Shared/Programming/python20.exe]:  extra 159 bytes at beginning or within Zip file (attempting to process anyway)

Assume this is just because it's a self-extracting file.

Source forge new account thing seems broken, but my email is sh@ttsoftware.co.uk

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117691&group_id=5470


From guido@python.org  Wed Oct 25 17:52:31 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 11:52:31 -0500
Subject: [Python-bugs-list] Re: Unable to run windows installer in windows 2000
Message-ID: <200010251652.LAA29679@cj20424-a.reston1.va.home.com>

I'm unclear on how you tried to run the installer.  The proper
way is to make sure that the file has an ".exe" extension and then to
double-click ("open" or "run") it.  Using Winzip to extract the files
does not do you any good.

If you did do the right thing, make sure that the .exe file is 
exactly 5811039 bytes long.  If not (and even if it is!) try to
download again from www.python.org/2.0/.

--Guido van Rossum (home page: http://www.python.org/~guido/)

> Subject: [Python-bugs-list] [Bug #117691] Unable to run windows installer in windows 2000
> From: noreply@sourceforge.net
> To: noreply@sourceforge.net, noreply@sourceforge.net,
>     python-bugs-list@python.org
> Date: Wed, 25 Oct 2000 08:24:57 -0700
> 
> Bug #117691, was updated on 2000-Oct-25 08:24
> Here is a current snapshot of the bug.
> 
> Project: Python
> Category: None
> Status: Open
> Resolution: None
> Bug Group: Platform-specific
> Priority: 5
> Summary: Unable to run windows installer in windows 2000
> 
> Details: Keep getting messagebox title 'Application Error' with text 'WOWEXEC caused a General Protection Fault in module KRNL386.EXE at 0001:8D7A.     Choose Close. WOWEXEC will close.'
> 
> Assume this is somehow to do with my setup, but at a loss to explain it.
> 
> File opens OK in WinZip, and Test gives no errors. Single warning was...
> 
> warning [D:/Documents and Settings/sh/My Documents/Shared/Programming/python20.exe]:  extra 159 bytes at beginning or within Zip file (attempting to process anyway)
> 
> Assume this is just because it's a self-extracting file.
> 
> Source forge new account thing seems broken, but my email is sh@ttsoftware.co.uk
> 
> For detailed info, follow this link:
> http://sourceforge.net/bugs/?func=detailbug&bug_id=117691&group_id=5470
> 
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list



From noreply@sourceforge.net  Wed Oct 25 17:33:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Oct 2000 09:33:58 -0700
Subject: [Python-bugs-list] [Bug #117691] Unable to run windows installer in windows 2000
Message-ID: <200010251633.JAA31766@sf-web1.i.sourceforge.net>

Bug #117691, was updated on 2000-Oct-25 08:24
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Closed
Resolution: Invalid
Bug Group: Platform-specific
Priority: 5
Summary: Unable to run windows installer in windows 2000

Details: Keep getting messagebox title 'Application Error' with text 'WOWEXEC caused a General Protection Fault in module KRNL386.EXE at 0001:8D7A.     Choose Close. WOWEXEC will close.'

Assume this is somehow to do with my setup, but at a loss to explain it.

File opens OK in WinZip, and Test gives no errors. Single warning was...

warning [D:/Documents and Settings/sh/My Documents/Shared/Programming/python20.exe]:  extra 159 bytes at beginning or within Zip file (attempting to process anyway)

Assume this is just because it's a self-extracting file.

Source forge new account thing seems broken, but my email is sh@ttsoftware.co.uk

Follow-Ups:

Date: 2000-Oct-25 09:33
By: gvanrossum

Comment:
Was an ftp download error according to personal mail. The file was too big, so probably CRLF translation problem.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117691&group_id=5470


From noreply@sourceforge.net  Wed Oct 25 18:32:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Oct 2000 10:32:01 -0700
Subject: [Python-bugs-list] [Bug #117508] Building 2.0 under Solaris 8 with GCC 2.95.2 fails to link
Message-ID: <200010251732.KAA02027@sf-web2.i.sourceforge.net>

Bug #117508, was updated on 2000-Oct-23 10:16
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: Building 2.0 under Solaris 8 with GCC 2.95.2 fails to link

Details: With no special options to 'configure' the final link step results in

   cd Modules;  make OPT="-g -O2 -Wall -Wstrict-prototypes" VERSION="2.0" \
                   prefix="/usr/local" exec_prefix="/usr/local" \
                   LIBRARY=../libpython2.0.a link
   make[1]: Entering directory `/tmp/pedwards/newbuild/Python-2.0/Modules'
   gcc   python.o \
             ../libpython2.0.a -ldb                                 -lpthread -lsocket -lnsl -ldl  -lthread -lm  -o python 
   Undefined                       first referenced
    symbol                             in file
   dbopen                              ../libpython2.0.a(bsddbmodule.o)
   ld: fatal: Symbol referencing errors. No output written to python
   collect2: ld returned 1 exit status
   make[1]: *** [link] Error 1

This is using GNU make, and GCC with the native linker.  Using the native
compiler works fine.  



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117508&group_id=5470


From noreply@sourceforge.net  Wed Oct 25 18:32:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Oct 2000 10:32:48 -0700
Subject: [Python-bugs-list] [Bug #117606] *.so creation in solaris+GCC
Message-ID: <200010251732.KAA02045@sf-web2.i.sourceforge.net>

Bug #117606, was updated on 2000-Oct-24 08:15
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: *.so creation in solaris+GCC

Details: Python 2.0 (dinamic modules)
Mod_Python 2.6.2 (dinamic module)
GCC 2.95.2
Apache 1.3.14 (dinamic modules)
SunOS5 (Solaris 2.x)

I send the email also to "mod_python" mailing list since I detect the problem using this package. Other developers could see the very same problem!.


Mod_python runs smoothly until I do a "import zlib", for example, in a handler. In this case, the request is aborted with the following log:

>>>>>
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache: Traceback (most recent call last):
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache:   File "/usr/local/lib/python2.0/site-packages/mod_python/apache.py", line 185, in Dispatch
    result = object(self.req)
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache:   File "/export/home/webmaster/www.argo.es/servicios/cache.py", line 47, in handler
    exec(cache[f][1])
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache:   File "/export/home/webmaster/www.argo.es/servicios/borra_email", line 183, in ?
    req2=wrap(req)
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache:   File "/export/home/webmaster/www.argo.es/servicios/borra_email", line 159, in __init__
    import zlib
[Tue Oct 24 16:27:40 2000] [error] PythonHandler cache: ImportError: ld.so.1: /opt/local/apache/bin/httpd: fatal: relocation error: file /usr/local/lib/python2.0/lib-dynload/zlibmodule.so: symbol main: referenced symbol not found
<<<<<

That is, "zlibmodule.so" tries to link to a function called "main".

Doing a "nm object|grep main", I see the unresolved reference in "zlibmodule.so", but not in "zlibmodule.o". So, the problem seems to be the creation of the shared library.

I tracked down the problem to the "configure" script: "cc -G" is (I think) the right thing to do to create a shared library if you are using the Sun compiler, but if you are using GCC (like me), the right command is "gcc -shared".

Patch for Python 2.0:

>>>>>
Index: configure
===================================================================
RCS file: /opt/src/cvsroot/python/configure,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.2.1
diff -c -r1.1.1.2 -r1.1.1.2.2.1
*** configure   2000/10/18 19:06:44     1.1.1.2
--- configure   2000/10/24 14:19:01     1.1.1.2.2.1
***************
*** 2650,2656 ****
        SunOS/4*) LDSHARED="ld";;
        SunOS/5*) 
                if test "$GCC" = "yes"
!               then LDSHARED='$(CC) -G'
                else LDSHARED="ld -G";
                fi ;;
        hp*|HP*) LDSHARED="ld -b";;
--- 2650,2656 ----
        SunOS/4*) LDSHARED="ld";;
        SunOS/5*) 
                if test "$GCC" = "yes"
!               then LDSHARED='$(CC) -shared'
                else LDSHARED="ld -G";
                fi ;;
        hp*|HP*) LDSHARED="ld -b";;
Index: configure.in
===================================================================
RCS file: /opt/src/cvsroot/python/configure.in,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.2.1
diff -c -r1.1.1.2 -r1.1.1.2.2.1
*** configure.in        2000/10/18 19:06:45     1.1.1.2
--- configure.in        2000/10/24 14:19:03     1.1.1.2.2.1
***************
*** 564,570 ****
        SunOS/4*) LDSHARED="ld";;
        SunOS/5*) 
                if test "$GCC" = "yes"
!               then LDSHARED='$(CC) -G'
                else LDSHARED="ld -G";
                fi ;;
        hp*|HP*) LDSHARED="ld -b";;
--- 564,570 ----
        SunOS/4*) LDSHARED="ld";;
        SunOS/5*) 
                if test "$GCC" = "yes"
!               then LDSHARED='$(CC) -shared'
                else LDSHARED="ld -G";
                fi ;;
        hp*|HP*) LDSHARED="ld -b";;
<<<<<


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117606&group_id=5470


From noreply@sourceforge.net  Wed Oct 25 18:49:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Oct 2000 10:49:57 -0700
Subject: [Python-bugs-list] [Bug #117706] Typo in the tutorial: shorted -> shorter
Message-ID: <200010251749.KAA02396@sf-web2.i.sourceforge.net>

Bug #117706, was updated on 2000-Oct-25 10:49
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Typo in the tutorial: shorted -> shorter

Details: In the tutorial:

5.6 Comparing Sequences and Other Types 

[...] If one sequence is an initial
subsequence of the other, the shorted sequence is the smaller one. 

"shorted" should be "shorter".

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117706&group_id=5470


From noreply@sourceforge.net  Wed Oct 25 18:52:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Oct 2000 10:52:35 -0700
Subject: [Python-bugs-list] [Bug #117070] README instructions for configuring Setup are not helpful
Message-ID: <200010251752.KAA02444@sf-web2.i.sourceforge.net>

Bug #117070, was updated on 2000-Oct-17 02:54
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 6
Summary: README instructions for configuring Setup are not helpful

Details: The instructions in the README file for configuring the Setup file are not useful. There is no indication of when you are supposed to edit the file. So far as I can tell the only way to configure python is either:

  ./configure
  make
  vim Modules/Setup
  make

or:

  ./configure
  vim Modules/Setup.in
  make

neither of which are particularly satisfactory.

The README file simply says "if [the Setup file] does not exist yet, make a copy yourself", without any indication of how you actually do this. 'make Setup' in the Modules directory does not work because there is no Makefile in the Modules directory yet.

Follow-Ups:

Date: 2000-Oct-18 16:28
By: none

Comment:
in my copy of the README file, there's a section called
"Build instructions", which tells you to build a basic interpreter (configure, make), and then tells you to see the sections on "testing", "configuring additional modules", and "installation"...

sounds like you only read the "configuring additional modules" section...

(satisfactory or not, it's a good idea to make sure the interpreter builds cleanly on your platform *before* you start fiddling with the extension modules...)

</F>
-------------------------------------------------------

Date: 2000-Oct-18 17:28
By: jribbens

Comment:
Your README must be different to mine, mine says "Before you can build Python, you must first configure it."

The method that you are proposing is completely counter-intuitive and is precisely what you *must not* do when compiling most other programs.

If this is what you are supposed to do then it needs to say so in BIG LETTERS.
-------------------------------------------------------

Date: 2000-Oct-24 13:37
By: fdrake

Comment:
This is a case of "RTFM, from the top".  There's no need to change the content of the README.
-------------------------------------------------------

Date: 2000-Oct-24 14:26
By: fdrake

Comment:
Jon insists that I'm wrong about this one, and another look leads me to think he's probably right.  (Sorry, Jon!)

I don't have time to revise the file now, but should be able to do so later tonight or in the morning.
-------------------------------------------------------

Date: 2000-Oct-25 10:52
By: fdrake

Comment:
Adjusted instructions in README revision 1.105, along with a few other small additions.

Jon, please let me know if you feel the changes are insufficient!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117070&group_id=5470


From noreply@sourceforge.net  Wed Oct 25 22:04:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Oct 2000 14:04:55 -0700
Subject: [Python-bugs-list] [Bug #117245] Python shared-library modules do not work on OpenBSD 2.7
Message-ID: <200010252104.OAA01696@sf-web2.i.sourceforge.net>

Bug #117245, was updated on 2000-Oct-18 17:42
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Python shared-library modules do not work on OpenBSD 2.7

Details: Python 2.0 compiles and works 100% fine with static modules. However, if I uncomment the '*shared*' line in Modules/Setup, then 'make test' will fail as follows:

cd Modules;  make OPT="-g -O2 -Wall -Wstrict-prototypes" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  sharedmods
rm -f ./Lib/test/*.py[co]
PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 39, in ?
    import random
  File "/tmp/Python-2.0/Lib/random.py", line 23, in ?
    import whrandom
  File "/tmp/Python-2.0/Lib/whrandom.py", line 134, in ?
    _inst = whrandom()
  File "/tmp/Python-2.0/Lib/whrandom.py", line 45, in __init__
    self.seed(x, y, z)
  File "/tmp/Python-2.0/Lib/whrandom.py", line 56, in seed
    import time
ImportError: dynamic module does not define init function (inittime)

But the symbol does exist:

$ nm timemodule.so | fgrep init
000009d0 T _inittime

(I noticed this bug while trying to install third-party modules, specifically the MySQLdb one, and, after testing, found the problem was more generic.)

Follow-Ups:

Date: 2000-Oct-25 14:04
By: gvanrossum

Comment:
I think I may have a patch for this:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102114&group_id=5470

Can you please test this patch and see if it solves the problem?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117245&group_id=5470


From noreply@sourceforge.net  Wed Oct 25 22:06:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Oct 2000 14:06:54 -0700
Subject: [Python-bugs-list] [Bug #117328] .py and .pyc icons confusing.
Message-ID: <200010252106.OAA01738@sf-web2.i.sourceforge.net>

Bug #117328, was updated on 2000-Oct-20 09:03
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Closed
Resolution: Wont Fix
Bug Group: Not a Bug
Priority: 1
Summary: .py and .pyc icons confusing.

Details: A very minor usability problem is that on Windows both the .py and .pyc icons look similar at a glance.  It'd be nice if you could change the colour of the .pyc icon to make it easy to idnetify the differences.

Thanks.

Follow-Ups:

Date: 2000-Oct-25 14:06
By: gvanrossum

Comment:
To me, the icons look different enough (closed eyes and missing tail).  If you want this fixed, please help: submit a new icon to the patch manager.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117328&group_id=5470


From noreply@sourceforge.net  Wed Oct 25 22:07:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Oct 2000 14:07:09 -0700
Subject: [Python-bugs-list] [Bug #117706] Typo in the tutorial: shorted -> shorter
Message-ID: <200010252107.OAA01741@sf-web2.i.sourceforge.net>

Bug #117706, was updated on 2000-Oct-25 10:49
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Typo in the tutorial: shorted -> shorter

Details: In the tutorial:

5.6 Comparing Sequences and Other Types 

[...] If one sequence is an initial
subsequence of the other, the shorted sequence is the smaller one. 

"shorted" should be "shorter".

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117706&group_id=5470


From noreply@sourceforge.net  Wed Oct 25 22:11:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Oct 2000 14:11:09 -0700
Subject: [Python-bugs-list] [Bug #117329] Compile Python 2.0 on BSDI BSD/OS 4.0.1 fails
Message-ID: <200010252111.OAA01825@sf-web2.i.sourceforge.net>

Bug #117329, was updated on 2000-Oct-20 10:08
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: Compile Python 2.0 on BSDI BSD/OS 4.0.1 fails

Details: When compiling Python 2.0. on BSDI BSD/OS 4.0.1

Configure
     ./configure --prefix=/usr/home/sud2000/python --with-                  threads=no
     no problem

make

     After a lot of warnings like :

        .........
   /usr/include/math.h:177: warning: function declaration
             isn't a prototype
   /usr/include/math.h:257: warning: function declaration
             isn't a prototype
        ........

The compile failed with this message :

   /usr/home/......./Python-2.0/Objects/fileobject.c:274:
                      undefined reference to `TELL64'
   *** Error code 1

        Stop.
   *** Error code 1


Follow-Ups:

Date: 2000-Oct-24 13:00
By: dkwolfe

Comment:
The warnings also appear under Darwin as the BSD header files have issues with prototypes.
-------------------------------------------------------

Date: 2000-Oct-25 14:11
By: gvanrossum

Comment:
If you search for TELL64 in fileobject.c, you'll notice some code bracketed with #elif defined(__NetBSD__) || defined(__OpenBSD__). Try adding || defined(_HAVE_BSDI) to that line to see if that fixes it. If so, please let me know so we can apply the patch!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117329&group_id=5470


From noreply@sourceforge.net  Wed Oct 25 22:14:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Oct 2000 14:14:31 -0700
Subject: [Python-bugs-list] [Bug #117686] IDLE doesn't display long arrays well
Message-ID: <200010252114.OAA01901@sf-web2.i.sourceforge.net>

Bug #117686, was updated on 2000-Oct-25 07:25
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 3
Summary: IDLE doesn't display long arrays well

Details: A long array, such as from Numeric Python is displayed
as
<array 3434 343421 4324234 .... 324234 34234>,
with part of the array replaced with elipses.

Often, this is enough information,
but unfortunately not always.  IDLE cannot tell you
how many items the array had (even approximately),
and it is impossible to see the complete output
or repr().  This is a bug, as a stack viewer ought to
let you see what is on the stack.

I'd suggest that long reprs() that get truncated this way
ought to be viewable in their entirety, perhaps by clicking
on them.

A fancier option would be to have IDLE look for a getitem()
attribute, and allow anything that has getitem() (or perhaps
getitem() and len()) to be displayed in the same format
that build-in python arrays are displayed in.

Follow-Ups:

Date: 2000-Oct-25 14:14
By: gvanrossum

Comment:
Good idea. I'll add this to IDLE's TODO list, and close the bug report.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117686&group_id=5470


From noreply@sourceforge.net  Wed Oct 25 22:17:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Oct 2000 14:17:48 -0700
Subject: [Python-bugs-list] [Bug #117684] IDLE stack browser display problem
Message-ID: <200010252117.OAA01980@sf-web2.i.sourceforge.net>

Bug #117684, was updated on 2000-Oct-25 07:10
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Closed
Resolution: Invalid
Bug Group: Irreproducible
Priority: 5
Summary: IDLE stack browser display problem

Details: IDLE doesn't properly display variables whose string
representation contains a newline.

The second line of those variables gets overwritten
by the next variable in the stack display.

Follow-Ups:

Date: 2000-Oct-25 14:17
By: gvanrossum

Comment:
Sorry, I can't reproduce this problem. When I try this, variables like that are displayed with '\n' instead of the newline (same as repr() does).

I'm closing the bug report; if you have additional information, add it here and I'll reopen it.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117684&group_id=5470


From jon+sourceforge@unequivocal.co.uk  Wed Oct 25 22:24:06 2000
From: jon+sourceforge@unequivocal.co.uk (Jon Ribbens)
Date: Wed, 25 Oct 2000 22:24:06 +0100
Subject: [Python-bugs-list] Re: [Bug #117070] README instructions for configuring Setup are not helpful
In-Reply-To: <200010251752.KAA02444@sf-web2.i.sourceforge.net>; from noreply@sourceforge.net on Wed, Oct 25, 2000 at 10:52:35AM -0700
References: <200010251752.KAA02444@sf-web2.i.sourceforge.net>
Message-ID: <20001025222406.A8389@snowy.squish.net>

> Adjusted instructions in README revision 1.105, along with a few
> other small additions.
> 
> Jon, please let me know if you feel the changes are insufficient!

I think the two main points are:

  Modules/Setup will not exist at the point of doing ./configure, so this
  needs mentioning around line 165 or so.

  Why the Setup.in/Setup thing at all? Just copying Setup.in to Setup without
  changes is unexpected enough to warrant mentioning in a paragraph of its
  own, completely explicitly. The '.in' suffix is usually used for files which
  autoconf is going to use to create a new file from - you cannot usually
  simply copy the file yourself. An experienced admin installing Python is
  more likely to believe the README is wrong than what it tells them to do
  is correct. Why does the Setup.in file exist in the first place? Surely it
  should be named 'Setup.dist' (and an identical file 'Setup' exist right from
  the start).

Cheers


Jon


From guido@python.org  Wed Oct 25 23:33:09 2000
From: guido@python.org (Guido van Rossum)
Date: Wed, 25 Oct 2000 17:33:09 -0500
Subject: [Python-bugs-list] Re: [Bug #117070] README instructions for configuring Setup are not helpful
In-Reply-To: Your message of "Wed, 25 Oct 2000 22:24:06 +0100."
 <20001025222406.A8389@snowy.squish.net>
References: <200010251752.KAA02444@sf-web2.i.sourceforge.net>
 <20001025222406.A8389@snowy.squish.net>
Message-ID: <200010252233.RAA01858@cj20424-a.reston1.va.home.com>

>   Why the Setup.in/Setup thing at all? Just copying Setup.in to
>   Setup without changes is unexpected enough to warrant mentioning
>   in a paragraph of its own, completely explicitly. The '.in' suffix
>   is usually used for files which autoconf is going to use to create
>   a new file from - you cannot usually simply copy the file
>   yourself. An experienced admin installing Python is more likely to
>   believe the README is wrong than what it tells them to do is
>   correct. Why does the Setup.in file exist in the first place?
>   Surely it should be named 'Setup.dist' (and an identical file
>   'Setup' exist right from the start).

This is actually a good suggestion.  I think this convention is newer
than Python's Setup.in file -- that's my only excuse for why this
wasn't always so.  Thanks!

--Guido van Rossum (home page: http://www.python.org/~guido/)


From noreply@sourceforge.net  Wed Oct 25 22:50:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Oct 2000 14:50:54 -0700
Subject: [Python-bugs-list] [Bug #117745] Two Compensating bugs in UserString.__imul__
Message-ID: <200010252150.OAA05390@sf-web1.i.sourceforge.net>

Bug #117745, was updated on 2000-Oct-25 14:50
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Two Compensating bugs in UserString.__imul__

Details: In UserString.py from the library, the method "__imul__"
is mis-spelled as "__imull__" (extra L).  This turns out
to be a good thing, since the method uses "+=" on the data
member, a string, where what is intended is apparently "*=".
The class seems to work, I presume, because, since the
interpreter can't find a method __imul__, it does the
multiplication and re-assignment itself.  But:
  import UserString
  a=UserString.UserString("foo")
  a.__imull__(3)
produces a suitable error.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117745&group_id=5470


From noreply@sourceforge.net  Wed Oct 25 22:59:22 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Oct 2000 14:59:22 -0700
Subject: [Python-bugs-list] [Bug #117745] Two Compensating bugs in UserString.__imul__
Message-ID: <200010252159.OAA01984@sf-web3.vaspecialprojects.com>

Bug #117745, was updated on 2000-Oct-25 14:50
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: Two Compensating bugs in UserString.__imul__

Details: In UserString.py from the library, the method "__imul__"
is mis-spelled as "__imull__" (extra L).  This turns out
to be a good thing, since the method uses "+=" on the data
member, a string, where what is intended is apparently "*=".
The class seems to work, I presume, because, since the
interpreter can't find a method __imul__, it does the
multiplication and re-assignment itself.  But:
  import UserString
  a=UserString.UserString("foo")
  a.__imull__(3)
produces a suitable error.


Follow-Ups:

Date: 2000-Oct-25 14:59
By: gvanrossum

Comment:
Thanks! Fixed now.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117745&group_id=5470


From noreply@sourceforge.net  Wed Oct 25 23:02:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Oct 2000 15:02:18 -0700
Subject: [Python-bugs-list] [Bug #117245] Python shared-library modules do not work on OpenBSD 2.7
Message-ID: <200010252202.PAA02789@sf-web2.i.sourceforge.net>

Bug #117245, was updated on 2000-Oct-18 17:42
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Python shared-library modules do not work on OpenBSD 2.7

Details: Python 2.0 compiles and works 100% fine with static modules. However, if I uncomment the '*shared*' line in Modules/Setup, then 'make test' will fail as follows:

cd Modules;  make OPT="-g -O2 -Wall -Wstrict-prototypes" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  sharedmods
rm -f ./Lib/test/*.py[co]
PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 39, in ?
    import random
  File "/tmp/Python-2.0/Lib/random.py", line 23, in ?
    import whrandom
  File "/tmp/Python-2.0/Lib/whrandom.py", line 134, in ?
    _inst = whrandom()
  File "/tmp/Python-2.0/Lib/whrandom.py", line 45, in __init__
    self.seed(x, y, z)
  File "/tmp/Python-2.0/Lib/whrandom.py", line 56, in seed
    import time
ImportError: dynamic module does not define init function (inittime)

But the symbol does exist:

$ nm timemodule.so | fgrep init
000009d0 T _inittime

(I noticed this bug while trying to install third-party modules, specifically the MySQLdb one, and, after testing, found the problem was more generic.)

Follow-Ups:

Date: 2000-Oct-25 14:04
By: gvanrossum

Comment:
I think I may have a patch for this:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102114&group_id=5470

Can you please test this patch and see if it solves the problem?
-------------------------------------------------------

Date: 2000-Oct-25 15:02
By: jribbens

Comment:
The patch worked, problem all solved - after I added the '#endif' that it's missing ;-)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117245&group_id=5470


From noreply@sourceforge.net  Wed Oct 25 23:09:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Oct 2000 15:09:57 -0700
Subject: [Python-bugs-list] [Bug #117245] Python shared-library modules do not work on OpenBSD 2.7
Message-ID: <200010252209.PAA02165@sf-web3.vaspecialprojects.com>

Bug #117245, was updated on 2000-Oct-18 17:42
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Summary: Python shared-library modules do not work on OpenBSD 2.7

Details: Python 2.0 compiles and works 100% fine with static modules. However, if I uncomment the '*shared*' line in Modules/Setup, then 'make test' will fail as follows:

cd Modules;  make OPT="-g -O2 -Wall -Wstrict-prototypes" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  sharedmods
rm -f ./Lib/test/*.py[co]
PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 39, in ?
    import random
  File "/tmp/Python-2.0/Lib/random.py", line 23, in ?
    import whrandom
  File "/tmp/Python-2.0/Lib/whrandom.py", line 134, in ?
    _inst = whrandom()
  File "/tmp/Python-2.0/Lib/whrandom.py", line 45, in __init__
    self.seed(x, y, z)
  File "/tmp/Python-2.0/Lib/whrandom.py", line 56, in seed
    import time
ImportError: dynamic module does not define init function (inittime)

But the symbol does exist:

$ nm timemodule.so | fgrep init
000009d0 T _inittime

(I noticed this bug while trying to install third-party modules, specifically the MySQLdb one, and, after testing, found the problem was more generic.)

Follow-Ups:

Date: 2000-Oct-25 14:04
By: gvanrossum

Comment:
I think I may have a patch for this:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102114&group_id=5470

Can you please test this patch and see if it solves the problem?
-------------------------------------------------------

Date: 2000-Oct-25 15:02
By: jribbens

Comment:
The patch worked, problem all solved - after I added the '#endif' that it's missing ;-)
-------------------------------------------------------

Date: 2000-Oct-25 15:09
By: gvanrossum

Comment:
Fixed by adding a leading underscore to the dlsym() lookup argument.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117245&group_id=5470


From noreply@sourceforge.net  Thu Oct 26 00:23:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Oct 2000 16:23:25 -0700
Subject: [Python-bugs-list] [Bug #117706] Typo in the tutorial: shorted -> shorter
Message-ID: <200010252323.QAA04077@sf-web2.i.sourceforge.net>

Bug #117706, was updated on 2000-Oct-25 10:49
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: Typo in the tutorial: shorted -> shorter

Details: In the tutorial:

5.6 Comparing Sequences and Other Types 

[...] If one sequence is an initial
subsequence of the other, the shorted sequence is the smaller one. 

"shorted" should be "shorter".

Follow-Ups:

Date: 2000-Oct-25 16:23
By: fdrake

Comment:
Typo corrected in Doc/tut/tut.tex revision 1.120.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117706&group_id=5470


From noreply@sourceforge.net  Thu Oct 26 01:37:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Oct 2000 17:37:11 -0700
Subject: [Python-bugs-list] [Bug #117706] Typo in the tutorial: shorted -> shorter
Message-ID: <200010260037.RAA04729@sf-web3.vaspecialprojects.com>

Bug #117706, was updated on 2000-Oct-25 10:49
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: Typo in the tutorial: shorted -> shorter

Details: In the tutorial:

5.6 Comparing Sequences and Other Types 

[...] If one sequence is an initial
subsequence of the other, the shorted sequence is the smaller one. 

"shorted" should be "shorter".

Follow-Ups:

Date: 2000-Oct-25 16:23
By: fdrake

Comment:
Typo corrected in Doc/tut/tut.tex revision 1.120.
-------------------------------------------------------

Date: 2000-Oct-25 17:37
By: fdrake

Comment:
Typo corrected in Doc/tut/tut.tex revision 1.120.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117706&group_id=5470


From noreply@sourceforge.net  Thu Oct 26 02:30:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Oct 2000 18:30:25 -0700
Subject: [Python-bugs-list] [Bug #119123] Use of ftplib or urllib causes page fault on exit
Message-ID: <200010260130.SAA09101@sf-web1.i.sourceforge.net>

Bug #119123, was updated on 2000-Oct-25 18:30
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Use of ftplib or urllib causes page fault on exit

Details: I work at a government office and have been using Python for over a year. Our office upgraded all the PC with the latest version of Netscape, IE Explorer, and security patches to Windows. After this upgrade, all scripts that use either ftplib or urllib cause a page fault in KERNEL32.DLL whenever Python exits. This page fault happens on every machine (Win95 & Win98) using Python, Pythonw, IDLE, or scripts; with version 1.5.2 and 2.0. The fault does not pop up until the script exits or interactive Python exits.

Because of this development, all Python work has stopped and my supervisors are re-evaluating the use Python for production work. I have been an avid promoter of Python, but now I am completely stuck. Other programs on the machines still work, only Python seems to be affected. Please help!

Below is the page fault message:
PYTHONW caused an invalid page fault in
module KERNEL32.DLL at 0167:bff7b9a6.
Registers:
EAX=00000000 CS=0167 EIP=bff7b9a6 EFLGS=00000246
EBX=0087b650 SS=016f ESP=0062fbdc EBP=0084d73c
ECX=00000000 DS=016f ESI=020325f0 FS=4207
EDX=00000000 ES=016f EDI=00671d68 GS=0000
Bytes at CS:EIP:
ff 76 04 e8 13 89 ff ff 5e c2 04 00 56 8b 74 24
Stack dump:
0087b650 02020b13 020325f0 0062fbf8 76003481
0062fbf8 0084d730 0087b650 7600265e 00000000
0084d730 0084d6d0 0084d6dc 76003283 0084d6d0 7600e420

Please contact mike.callahan@noaa.gov or call 800-292-5588 if you have any answers. I want to keep Python in our office, but right now, I am fighting a losing battle.

Mike Callahan
National Weather Service
Louisville KY



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119123&group_id=5470


From noreply@sourceforge.net  Thu Oct 26 06:03:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 25 Oct 2000 22:03:47 -0700
Subject: [Python-bugs-list] [Bug #119221] Include/graminit.h and Parser/graminit.c erroneously in dist
Message-ID: <200010260503.WAA12390@sf-web1.i.sourceforge.net>

Bug #119221, was updated on 2000-Oct-25 22:03
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Include/graminit.h and Parser/graminit.c erroneously in dist

Details: I install for multiple architectures by first unpacking the tar file into a read-only directory, then symlinking the files into a shadow tree, via X11 'lndir'.  Worked fine on Python 1.*.  With 2.0, however, the files Include/graminit.h and Parser/graminit.c are supplied in the tar file, and also generated by the build process.  Of course, they cannot be copied into their respective directories, because the files they are overwriting are in a read-only volume.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119221&group_id=5470


From noreply@sourceforge.net  Thu Oct 26 11:38:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Oct 2000 03:38:00 -0700
Subject: [Python-bugs-list] [Bug #119221] Include/graminit.h and Parser/graminit.c erroneously in dist
Message-ID: <200010261038.DAA17522@sf-web3.vaspecialprojects.com>

Bug #119221, was updated on 2000-Oct-25 22:03
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Include/graminit.h and Parser/graminit.c erroneously in dist

Details: I install for multiple architectures by first unpacking the tar file into a read-only directory, then symlinking the files into a shadow tree, via X11 'lndir'.  Worked fine on Python 1.*.  With 2.0, however, the files Include/graminit.h and Parser/graminit.c are supplied in the tar file, and also generated by the build process.  Of course, they cannot be copied into their respective directories, because the files they are overwriting are in a read-only volume.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119221&group_id=5470


From noreply@sourceforge.net  Thu Oct 26 16:20:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Oct 2000 08:20:48 -0700
Subject: [Python-bugs-list] [Bug #119450] dictionary values returns pointers when the value is a list
Message-ID: <200010261520.IAA21450@sf-web1.i.sourceforge.net>

Bug #119450, was updated on 2000-Oct-26 08:20
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: dictionary values returns pointers when the value is a list

Details: >>> dictio = {}
>>> dictio['a'] = ['a',[],""]
>>> temp = dictio['a']
>>> temp
['a', [], '']
>>> temp[-1] = 'c'
>>> temp
['a', [], 'c']
>>> dictio['a']
['a', [], 'c']

This is not documented. A simple way to fix it, is to copy the list when
the value is returned:


>>> dictio['a']
['a', [], 'd']
>>> temp = []+dictio['a']
>>> temp
['a', [], 'd']
>>> temp[-1] = 'e'
>>> dictio['a']
['a', [], 'd']


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119450&group_id=5470


From noreply@sourceforge.net  Thu Oct 26 17:02:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Oct 2000 09:02:05 -0700
Subject: [Python-bugs-list] [Bug #117524] The unicodedata db does not know about the special ranges.
Message-ID: <200010261602.JAA22342@sf-web1.i.sourceforge.net>

Bug #117524, was updated on 2000-Oct-23 13:06
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: The unicodedata db does not know about the special ranges.

Details: There seems to a bug in the unicodedata. The special ranges described under "Field Formats" are not handled correctly.

   ftp://ftp.unicode.org/Public/3.0-Update/UnicodeData-3.0.0.html

The two characters should have identical properties:

Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import unicodedata
>>> unicodedata.category(u"\u3400")
'Lo'
>>> unicodedata.category(u"\u3401")
'Cn'
>>> u"\u3400".isalpha()
1
>>> u"\u3401".isalpha()
0
>>>

Follow-Ups:

Date: 2000-Oct-26 09:02
By: lemburg

Comment:
Looks like we'll have to add a few special if()s to the various APIs.

I hadn't realized that the Unicode database defines properties for
char points which do not appear in the listed UnicodeData.txt file...
one little sentence in the webpage you mention makes the difference - sigh.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117524&group_id=5470


From noreply@sourceforge.net  Thu Oct 26 17:34:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Oct 2000 09:34:56 -0700
Subject: [Python-bugs-list] [Bug #119450] dictionary values returns pointers when the value is a list
Message-ID: <200010261634.JAA24694@sf-web2.i.sourceforge.net>

Bug #119450, was updated on 2000-Oct-26 08:20
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: Wont Fix
Bug Group: Not a Bug
Priority: 5
Summary: dictionary values returns pointers when the value is a list

Details: >>> dictio = {}
>>> dictio['a'] = ['a',[],""]
>>> temp = dictio['a']
>>> temp
['a', [], '']
>>> temp[-1] = 'c'
>>> temp
['a', [], 'c']
>>> dictio['a']
['a', [], 'c']

This is not documented. A simple way to fix it, is to copy the list when
the value is returned:


>>> dictio['a']
['a', [], 'd']
>>> temp = []+dictio['a']
>>> temp
['a', [], 'd']
>>> temp[-1] = 'e'
>>> dictio['a']
['a', [], 'd']


Follow-Ups:

Date: 2000-Oct-26 09:34
By: jhylton

Comment:
Python's reference semantics are documented.  This is not a bug.  If you want to copy a list when you extract it from a dictionary, then do it in your code.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119450&group_id=5470


From noreply@sourceforge.net  Thu Oct 26 22:11:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Oct 2000 14:11:00 -0700
Subject: [Python-bugs-list] [Bug #119483] OpenBSD can't dynamically load modules
Message-ID: <200010262111.OAA27752@sf-web3.vaspecialprojects.com>

Bug #119483, was updated on 2000-Oct-26 14:11
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: OpenBSD can't dynamically load modules

Details: 
On OpenBSD, one always gets a traceback trying to import a '.so' module (replacing blahblahblah with module name):

ImportError: dynamic module does not define init function (initblahblahblah)

The problem is that dynload_shlib.c doesn't prepend an underscore to the symbol name (the C standard for naming function exports). Some OS's will try both the name with and without the underscore, some try only the literal symbol name when calling dlsym. OpenBSD requires the literal symbol. Hence, the following patch is in order:

--- dynload_shlib.c    Thu Oct 26 11:10:36 2000
+++ dynload_shlib.c     Thu Oct 26 11:10:51 2000
@@ -55,7 +55,7 @@
        }
 
        /* ### should there be a leading underscore for some platforms? */
-       sprintf(funcname, "init%.200s", shortname);
+       sprintf(funcname, "_init%.200s", shortname);
 
        if (fp != NULL) {
                int i;


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119483&group_id=5470


From noreply@sourceforge.net  Thu Oct 26 22:15:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Oct 2000 14:15:55 -0700
Subject: [Python-bugs-list] [Bug #119483] OpenBSD can't dynamically load modules
Message-ID: <200010262115.OAA30262@sf-web2.i.sourceforge.net>

Bug #119483, was updated on 2000-Oct-26 14:11
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Duplicate
Bug Group: Platform-specific
Priority: 5
Summary: OpenBSD can't dynamically load modules

Details: 
On OpenBSD, one always gets a traceback trying to import a '.so' module (replacing blahblahblah with module name):

ImportError: dynamic module does not define init function (initblahblahblah)

The problem is that dynload_shlib.c doesn't prepend an underscore to the symbol name (the C standard for naming function exports). Some OS's will try both the name with and without the underscore, some try only the literal symbol name when calling dlsym. OpenBSD requires the literal symbol. Hence, the following patch is in order:

--- dynload_shlib.c    Thu Oct 26 11:10:36 2000
+++ dynload_shlib.c     Thu Oct 26 11:10:51 2000
@@ -55,7 +55,7 @@
        }
 
        /* ### should there be a leading underscore for some platforms? */
-       sprintf(funcname, "init%.200s", shortname);
+       sprintf(funcname, "_init%.200s", shortname);
 
        if (fp != NULL) {
                int i;


Follow-Ups:

Date: 2000-Oct-26 14:15
By: gvanrossum

Comment:
This was reported before. I just fixed this 1-2 days ago in the CvS tree.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119483&group_id=5470


From noreply@sourceforge.net  Thu Oct 26 22:16:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Oct 2000 14:16:53 -0700
Subject: [Python-bugs-list] [Bug #119485] os.path.basename behaves different from Unix basename
Message-ID: <200010262116.OAA29141@sf-web1.i.sourceforge.net>

Bug #119485, was updated on 2000-Oct-26 14:16
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: os.path.basename behaves different from Unix basename

Details: James Troup <troup@debian.org> filed a report about an inconsistency
between os.path.basename() and the Unix basename utility 
(registered in the Debian Bug Tracking System as bug #75605,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=75605).

os.path.basename('/org/ftp.debian.org/') returns an empty string "", 
while the Unix command "basename /org/ftp.debian.org/" returns 
"ftp.debian.org" (at least that's the case with GNU basename).


os.path.basename() works consistent with its documentation.

I consider this a misbehavior of the basename command, but I guess it's
consistent across all implementations of basename.


I'd suggest that the documentation to os.path.basename mentions that the
result of the function is not necessarily identical to the result of the
basename command. The same applies for os.path.dirname().

    Gregor



02:02:44@auric| ~ $python
Python 1.5.2 (#0, Apr  5 2000, 04:40:10)  [GCC 2.95.2 20000313 (Debian GNU/Linux)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import os
>>> print os.path.basename('/org/ftp.debian.org/')

>>> print os.path.basename('/org/ftp.debian.org')
ftp.debian.org
>>>

02:03:24@auric| ~ $basename /org/ftp.debian.org/
ftp.debian.org
02:03:43@auric| ~ $basename /org/ftp.debian.org 
ftp.debian.org
02:03:44@auric| ~ $


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119485&group_id=5470


From noreply@sourceforge.net  Thu Oct 26 22:18:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Oct 2000 14:18:50 -0700
Subject: [Python-bugs-list] [Bug #119486] fcntl.lockf() is broken
Message-ID: <200010262118.OAA29186@sf-web1.i.sourceforge.net>

Bug #119486, was updated on 2000-Oct-26 14:18
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: fcntl.lockf() is broken

Details: Another observation by James Troup <troup@debian.org>: fcntl.lockf()
seems to be severly `broken': it's acting like flock, not like lockf, 
and the code seems to be a copy/paste of flock.
(registered in the Debian Bug Tracking System as bug #74777,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=74777).

James includes a first start at filling in a correct lockf function.
Looks like it needs some more work, therefore I don't submit it as
patch. The patch is against 1.5.2, though there seem to be no changes in 2.0.

These are James' words:


fcntl.lockf() doesn't work as expected.  

        fcntl.lockf(fd, FCNTL.F_TLOCK);

will block.. looking at the source is exteremly confusing.
fcntl.lockf() appears to want flock() style arguments?!  It almost
looks like someone cut'n'wasted from the fcntl_flock() function just
above...

Anyway, here is a patch which is IMO the Right Thing,
i.e. fcnt.lockf() acting like libc lockf() and like it's documented to
do...

--- python-1.5.2/Modules/fcntlmodule.c.orig     Sat Oct 14 15:46:40 2000
+++ python-1.5.2/Modules/fcntlmodule.c  Sat Oct 14 18:31:44 2000
@@ -233,30 +233,12 @@
 {
        int fd, code, ret, whence = 0;
        PyObject *lenobj = NULL, *startobj = NULL;
+       struct flock l;
 
        if (!PyArg_ParseTuple(args, "ii|OOi", &fd, &code,
                              &lenobj, &startobj, &whence))
            return NULL;
 
-#ifndef LOCK_SH
-#define LOCK_SH                1       /* shared lock */
-#define LOCK_EX                2       /* exclusive lock */
-#define LOCK_NB                4       /* don't block when locking */
-#define LOCK_UN                8       /* unlock */
-#endif
-       {
-               struct flock l;
-               if (code == LOCK_UN)
-                       l.l_type = F_UNLCK;
-               else if (code & LOCK_SH)
-                       l.l_type = F_RDLCK;
-               else if (code & LOCK_EX)
-                       l.l_type = F_WRLCK;
-               else {
-                       PyErr_SetString(PyExc_ValueError,
-                                       "unrecognized flock argument");
-                       return NULL;
-               }
                l.l_start = l.l_len = 0;
                if (startobj != NULL) {
 #if !defined(HAVE_LARGEFILE_SUPPORT)
@@ -281,10 +263,48 @@
                                return NULL;
                }
                l.l_whence = whence;
+       switch (code)
+         {
+         case F_TEST:
+           /* Test the lock: return 0 if FD is unlocked or locked by this process;
+              return -1, set errno to EACCES, if another process holds the lock.  */
+           if (fcntl (fd, F_GETLK, &l) < 0) {
+             fprintf(stderr, "andrea: 1");
+             PyErr_SetFromErrno(PyExc_IOError);
+             return NULL;
+           }
+           if (l.l_type == F_UNLCK || l.l_pid == getpid ()) {
+             fprintf(stderr, "andrea: 2");
+             Py_INCREF(Py_None);
+             return Py_None;
+           }
+           fprintf(stderr, "andrea: 3");
+           errno = EACCES;
+           PyErr_SetFromErrno(PyExc_IOError);
+           return NULL;
+
+         case F_ULOCK:
+           l.l_type = F_UNLCK;
+           code = F_SETLK;
+           break;
+         case F_LOCK:
+           l.l_type = F_WRLCK;
+           code = F_SETLKW;
+           break;
+         case F_TLOCK:
+           l.l_type = F_WRLCK;
+           code = F_SETLK;
+           break;
+           
+         default:
+           PyErr_SetString(PyExc_ValueError,
+                           "unrecognized flock argument");
+           return NULL;
+         }
                Py_BEGIN_ALLOW_THREADS
-               ret = fcntl(fd, (code & LOCK_NB) ? F_SETLK : F_SETLKW, &l);
+         ret = fcntl(fd, code, &l);
                Py_END_ALLOW_THREADS
-       }
+
        if (ret < 0) {
                PyErr_SetFromErrno(PyExc_IOError);
                return NULL;



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119486&group_id=5470


From noreply@sourceforge.net  Thu Oct 26 22:23:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Oct 2000 14:23:29 -0700
Subject: [Python-bugs-list] [Bug #119485] os.path.basename behaves different from Unix basename
Message-ID: <200010262123.OAA30418@sf-web2.i.sourceforge.net>

Bug #119485, was updated on 2000-Oct-26 14:16
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 2
Summary: os.path.basename behaves different from Unix basename

Details: James Troup <troup@debian.org> filed a report about an inconsistency
between os.path.basename() and the Unix basename utility 
(registered in the Debian Bug Tracking System as bug #75605,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=75605).

os.path.basename('/org/ftp.debian.org/') returns an empty string "", 
while the Unix command "basename /org/ftp.debian.org/" returns 
"ftp.debian.org" (at least that's the case with GNU basename).


os.path.basename() works consistent with its documentation.

I consider this a misbehavior of the basename command, but I guess it's
consistent across all implementations of basename.


I'd suggest that the documentation to os.path.basename mentions that the
result of the function is not necessarily identical to the result of the
basename command. The same applies for os.path.dirname().

    Gregor



02:02:44@auric| ~ $python
Python 1.5.2 (#0, Apr  5 2000, 04:40:10)  [GCC 2.95.2 20000313 (Debian GNU/Linux)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import os
>>> print os.path.basename('/org/ftp.debian.org/')

>>> print os.path.basename('/org/ftp.debian.org')
ftp.debian.org
>>>

02:03:24@auric| ~ $basename /org/ftp.debian.org/
ftp.debian.org
02:03:43@auric| ~ $basename /org/ftp.debian.org 
ftp.debian.org
02:03:44@auric| ~ $


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119485&group_id=5470


From noreply@sourceforge.net  Thu Oct 26 22:29:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Oct 2000 14:29:13 -0700
Subject: [Python-bugs-list] [Bug #119486] fcntl.lockf() is broken
Message-ID: <200010262129.OAA30496@sf-web2.i.sourceforge.net>

Bug #119486, was updated on 2000-Oct-26 14:18
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: fcntl.lockf() is broken

Details: Another observation by James Troup <troup@debian.org>: fcntl.lockf()
seems to be severly `broken': it's acting like flock, not like lockf, 
and the code seems to be a copy/paste of flock.
(registered in the Debian Bug Tracking System as bug #74777,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=74777).

James includes a first start at filling in a correct lockf function.
Looks like it needs some more work, therefore I don't submit it as
patch. The patch is against 1.5.2, though there seem to be no changes in 2.0.

These are James' words:


fcntl.lockf() doesn't work as expected.  

        fcntl.lockf(fd, FCNTL.F_TLOCK);

will block.. looking at the source is exteremly confusing.
fcntl.lockf() appears to want flock() style arguments?!  It almost
looks like someone cut'n'wasted from the fcntl_flock() function just
above...

Anyway, here is a patch which is IMO the Right Thing,
i.e. fcnt.lockf() acting like libc lockf() and like it's documented to
do...

--- python-1.5.2/Modules/fcntlmodule.c.orig     Sat Oct 14 15:46:40 2000
+++ python-1.5.2/Modules/fcntlmodule.c  Sat Oct 14 18:31:44 2000
@@ -233,30 +233,12 @@
 {
        int fd, code, ret, whence = 0;
        PyObject *lenobj = NULL, *startobj = NULL;
+       struct flock l;
 
        if (!PyArg_ParseTuple(args, "ii|OOi", &fd, &code,
                              &lenobj, &startobj, &whence))
            return NULL;
 
-#ifndef LOCK_SH
-#define LOCK_SH                1       /* shared lock */
-#define LOCK_EX                2       /* exclusive lock */
-#define LOCK_NB                4       /* don't block when locking */
-#define LOCK_UN                8       /* unlock */
-#endif
-       {
-               struct flock l;
-               if (code == LOCK_UN)
-                       l.l_type = F_UNLCK;
-               else if (code & LOCK_SH)
-                       l.l_type = F_RDLCK;
-               else if (code & LOCK_EX)
-                       l.l_type = F_WRLCK;
-               else {
-                       PyErr_SetString(PyExc_ValueError,
-                                       "unrecognized flock argument");
-                       return NULL;
-               }
                l.l_start = l.l_len = 0;
                if (startobj != NULL) {
 #if !defined(HAVE_LARGEFILE_SUPPORT)
@@ -281,10 +263,48 @@
                                return NULL;
                }
                l.l_whence = whence;
+       switch (code)
+         {
+         case F_TEST:
+           /* Test the lock: return 0 if FD is unlocked or locked by this process;
+              return -1, set errno to EACCES, if another process holds the lock.  */
+           if (fcntl (fd, F_GETLK, &l) < 0) {
+             fprintf(stderr, "andrea: 1");
+             PyErr_SetFromErrno(PyExc_IOError);
+             return NULL;
+           }
+           if (l.l_type == F_UNLCK || l.l_pid == getpid ()) {
+             fprintf(stderr, "andrea: 2");
+             Py_INCREF(Py_None);
+             return Py_None;
+           }
+           fprintf(stderr, "andrea: 3");
+           errno = EACCES;
+           PyErr_SetFromErrno(PyExc_IOError);
+           return NULL;
+
+         case F_ULOCK:
+           l.l_type = F_UNLCK;
+           code = F_SETLK;
+           break;
+         case F_LOCK:
+           l.l_type = F_WRLCK;
+           code = F_SETLKW;
+           break;
+         case F_TLOCK:
+           l.l_type = F_WRLCK;
+           code = F_SETLK;
+           break;
+           
+         default:
+           PyErr_SetString(PyExc_ValueError,
+                           "unrecognized flock argument");
+           return NULL;
+         }
                Py_BEGIN_ALLOW_THREADS
-               ret = fcntl(fd, (code & LOCK_NB) ? F_SETLK : F_SETLKW, &l);
+         ret = fcntl(fd, code, &l);
                Py_END_ALLOW_THREADS
-       }
+
        if (ret < 0) {
                PyErr_SetFromErrno(PyExc_IOError);
                return NULL;



Follow-Ups:

Date: 2000-Oct-26 14:29
By: gvanrossum

Comment:
Sjoerd, you once looked at this code. Can you comment on this? If you don't have time, please assign back to me.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119486&group_id=5470


From noreply@sourceforge.net  Thu Oct 26 22:38:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 26 Oct 2000 14:38:56 -0700
Subject: [Python-bugs-list] [Bug #119485] os.path.basename behaves different from Unix basename
Message-ID: <200010262138.OAA30663@sf-web2.i.sourceforge.net>

Bug #119485, was updated on 2000-Oct-26 14:16
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 2
Summary: os.path.basename behaves different from Unix basename

Details: James Troup <troup@debian.org> filed a report about an inconsistency
between os.path.basename() and the Unix basename utility 
(registered in the Debian Bug Tracking System as bug #75605,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=75605).

os.path.basename('/org/ftp.debian.org/') returns an empty string "", 
while the Unix command "basename /org/ftp.debian.org/" returns 
"ftp.debian.org" (at least that's the case with GNU basename).


os.path.basename() works consistent with its documentation.

I consider this a misbehavior of the basename command, but I guess it's
consistent across all implementations of basename.


I'd suggest that the documentation to os.path.basename mentions that the
result of the function is not necessarily identical to the result of the
basename command. The same applies for os.path.dirname().

    Gregor



02:02:44@auric| ~ $python
Python 1.5.2 (#0, Apr  5 2000, 04:40:10)  [GCC 2.95.2 20000313 (Debian GNU/Linux)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import os
>>> print os.path.basename('/org/ftp.debian.org/')

>>> print os.path.basename('/org/ftp.debian.org')
ftp.debian.org
>>>

02:03:24@auric| ~ $basename /org/ftp.debian.org/
ftp.debian.org
02:03:43@auric| ~ $basename /org/ftp.debian.org 
ftp.debian.org
02:03:44@auric| ~ $


Follow-Ups:

Date: 2000-Oct-26 14:38
By: fdrake

Comment:
Added an explanation in Doc/lib/libposixpath.tex revision 1.17.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119485&group_id=5470


From noreply@sourceforge.net  Fri Oct 27 12:56:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 27 Oct 2000 04:56:58 -0700
Subject: [Python-bugs-list] [Bug #117278] re-opening of bug #117167
Message-ID: <200010271156.EAA12123@sf-web2.i.sourceforge.net>

Bug #117278, was updated on 2000-Oct-19 09:12
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: re-opening of bug #117167

Details: As directed, I'm reopening the bug #117167 (_tkinter segfaults on "syntax error"), because it was closed on incorrect assumptions:
- I believe I am using Python 2.0 final ( python -V says
'python 2.0'; the file I downloaded is named BeOpen-Python-2.0.tar.bz2 ).
- tkinter is a static module, therefore there is no possibility of still using the old one.

----
Additional info :

I verified the same behaviour on Solaris 2.0, with tcl/tk 8.3.1 and gcc 2.8.1. Hereaftter there is the output of gdb 'where' command, obtained from thye dumped core.

---------- output of where ---------------------------

#0  0x94464 in Tkapp_Call (self=0x1b80c0, args=0x18c67c) at ./_tkinter.c:644
#1  0x26fac in call_builtin (func=0x1b80a8, arg=0x18c67c, kw=0x0)
    at ceval.c:2650
#2  0x26e78 in PyEval_CallObjectWithKeywords (func=0x1b80a8, arg=0x229134,
    kw=0x0) at ceval.c:2618
#3  0x2579c in eval_code2 (co=0x1e9ff8, globals=0x0, locals=0x0,
    args=0x18c67c, argcount=0, kws=0xffffffff, kwcount=0, defs=0x22e810,
    defcount=3, owner=0x22e864) at ceval.c:1951
#4  0x253d8 in eval_code2 (co=0x1fae00, globals=0x0, locals=0x18c67c,
    args=0x17a160, argcount=2, kws=0x5, kwcount=1, defs=0x22cba8, defcount=2,
    owner=0x23102c) at ceval.c:1850
#5  0x273bc in call_function (func=0x230ffc, arg=0x2037c4, kw=0x1)
    at ceval.c:2772
#6  0x26e64 in PyEval_CallObjectWithKeywords (func=0x1b4efc, arg=0x1e33e4,
    kw=0x1a07d4) at ceval.c:2616
#7  0x45484 in PyInstance_New (class=0x23102c, arg=0x1e33e4, kw=0x1a07d4)
    at classobject.c:463
#8  0x26fd4 in call_builtin (func=0x23102c, arg=0x1e33e4, kw=0x1a07d4)
    at ceval.c:2653
#9  0x26e78 in PyEval_CallObjectWithKeywords (func=0x23102c, arg=0x1e33e4,
    kw=0x1a07d4) at ceval.c:2618
#10 0x2579c in eval_code2 (co=0x1b42c0, globals=0x1a07d4, locals=0x0,
    args=0x1b55dc, argcount=1705940, kws=0xffffffff, kwcount=0, defs=0x0,
---Type <return> to continue, or q <return> to quit---
    defcount=0, owner=0x187d3c) at ceval.c:1951
#11 0x273bc in call_function (func=0x1bb714, arg=0x1b40ec, kw=0x0)
    at ceval.c:2772
#12 0x26e64 in PyEval_CallObjectWithKeywords (func=0x1b53fc, arg=0x1c8654,
    kw=0x0) at ceval.c:2616
#13 0x45484 in PyInstance_New (class=0x187d3c, arg=0x1c8654, kw=0x0)
    at classobject.c:463
#14 0x26fd4 in call_builtin (func=0x187d3c, arg=0x1c8654, kw=0x0)
    at ceval.c:2653
#15 0x26e78 in PyEval_CallObjectWithKeywords (func=0x187d3c, arg=0x1c8654,
    kw=0x0) at ceval.c:2618
#16 0x2579c in eval_code2 (co=0x1b39b8, globals=0x0, locals=0x0,
    args=0x1b571c, argcount=0, kws=0xffffffff, kwcount=0, defs=0x0,
    defcount=0, owner=0x21b8a4) at ceval.c:1951
#17 0x273bc in call_function (func=0x222474, arg=0x184de4, kw=0x0)
    at ceval.c:2772
#18 0x26e64 in PyEval_CallObjectWithKeywords (func=0x1b5744, arg=0x175364,
    kw=0x0) at ceval.c:2616
#19 0x45484 in PyInstance_New (class=0x21b8a4, arg=0x175364, kw=0x0)
    at classobject.c:463
#20 0x26fd4 in call_builtin (func=0x21b8a4, arg=0x175364, kw=0x0)
    at ceval.c:2653
#21 0x26e78 in PyEval_CallObjectWithKeywords (func=0x21b8a4, arg=0x175364,
---Type <return> to continue, or q <return> to quit---
    kw=0x0) at ceval.c:2618
#22 0x2579c in eval_code2 (co=0x1b4148, globals=0x0, locals=0x0,
    args=0x1b6dc8, argcount=0, kws=0xffffffff, kwcount=0, defs=0x0,
    defcount=0, owner=0x0) at ceval.c:1951
#23 0x22584 in PyEval_EvalCode (co=0x1b4148, globals=0x180b54, locals=0x180b54)
    at ceval.c:319
#24 0x3a39c in run_node (n=0x175658, filename=0x1b4148 "", globals=0x180b54,
    locals=0x180b54) at pythonrun.c:886
#25 0x3a34c in run_err_node (n=0x175658, filename=0x1b4148 "",
    globals=0x180b54, locals=0x180b54) at pythonrun.c:874
#26 0x3a320 in PyRun_FileEx (fp=0x174f20, filename=0xffbef26b "problem.py",
    start=1529432, globals=0x180b54, locals=0x180b54, closeit=1)
    at pythonrun.c:866
#27 0x397e8 in PyRun_SimpleFileEx (fp=0x174f20,
    filename=0xffbef26b "problem.py", closeit=1) at pythonrun.c:579
#28 0x39390 in PyRun_AnyFileEx (fp=0x174f20, filename=0xffbef26b "problem.py",
    closeit=1) at pythonrun.c:459
#29 0x1ee08 in Py_Main (argc=2, argv=0xffbef144) at main.c:289
#30 0x1e74c in main (argc=2, argv=0xffbef144) at python.c:10


Follow-Ups:

Date: 2000-Oct-19 14:06
By: loewis

Comment:
A fix for that is in http://sourceforge.net/patch/?func=detailpatch&patch_id=101980&group_id=5470
-------------------------------------------------------

Date: 2000-Oct-27 04:56
By: gvanrossum

Comment:
Thanks for the fix, Martin. I'll have a look.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117278&group_id=5470


From noreply@sourceforge.net  Fri Oct 27 13:01:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 27 Oct 2000 05:01:25 -0700
Subject: [Python-bugs-list] [Bug #117241] class.method(*([self]+args)) gave me a 'unbound method must be called with class instance 1st argument" error message.
Message-ID: <200010271201.FAA12213@sf-web2.i.sourceforge.net>

Bug #117241, was updated on 2000-Oct-18 15:28
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: class.method(*([self]+args)) gave me a 'unbound method must be called with class instance 1st argument" error message.

Details: I have some 1.5 code like this:

apply(BaseMsgTemplate.__call__,[self]+args)

This works great and does what I want, calls the base class call method
with the current instance as self.  I thought I'd convert it to the
new calling syntax:

BaseMsgTemplate.__call__(*([self]+args))

But this gave me the error message:

'unbound method must be called with class instance 1st argument'

I *think* the * argument method is supposed to be functionally
equivalent to apply, so I think this is a bug. 


Follow-Ups:

Date: 2000-Oct-27 05:01
By: gvanrossum

Comment:
Definitely a bug! A simpler example would be Base.__init__(*(self, arg)).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117241&group_id=5470


From noreply@sourceforge.net  Fri Oct 27 13:12:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 27 Oct 2000 05:12:12 -0700
Subject: [Python-bugs-list] [Bug #117004] Tools/compiler does not create doc strings
Message-ID: <200010271212.FAA12364@sf-web2.i.sourceforge.net>

Bug #117004, was updated on 2000-Oct-16 08:11
Here is a current snapshot of the bug.

Project: Python
Category: demos and tools
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: Tools/compiler does not create doc strings

Details: Transformer.get_docstring() seems to be working fine but the __doc__ attributes are always None in the compiled code.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117004&group_id=5470


From noreply@sourceforge.net  Fri Oct 27 13:17:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 27 Oct 2000 05:17:37 -0700
Subject: [Python-bugs-list] [Bug #117278] re-opening of bug #117167
Message-ID: <200010271217.FAA09681@sf-web1.i.sourceforge.net>

Bug #117278, was updated on 2000-Oct-19 09:12
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: re-opening of bug #117167

Details: As directed, I'm reopening the bug #117167 (_tkinter segfaults on "syntax error"), because it was closed on incorrect assumptions:
- I believe I am using Python 2.0 final ( python -V says
'python 2.0'; the file I downloaded is named BeOpen-Python-2.0.tar.bz2 ).
- tkinter is a static module, therefore there is no possibility of still using the old one.

----
Additional info :

I verified the same behaviour on Solaris 2.0, with tcl/tk 8.3.1 and gcc 2.8.1. Hereaftter there is the output of gdb 'where' command, obtained from thye dumped core.

---------- output of where ---------------------------

#0  0x94464 in Tkapp_Call (self=0x1b80c0, args=0x18c67c) at ./_tkinter.c:644
#1  0x26fac in call_builtin (func=0x1b80a8, arg=0x18c67c, kw=0x0)
    at ceval.c:2650
#2  0x26e78 in PyEval_CallObjectWithKeywords (func=0x1b80a8, arg=0x229134,
    kw=0x0) at ceval.c:2618
#3  0x2579c in eval_code2 (co=0x1e9ff8, globals=0x0, locals=0x0,
    args=0x18c67c, argcount=0, kws=0xffffffff, kwcount=0, defs=0x22e810,
    defcount=3, owner=0x22e864) at ceval.c:1951
#4  0x253d8 in eval_code2 (co=0x1fae00, globals=0x0, locals=0x18c67c,
    args=0x17a160, argcount=2, kws=0x5, kwcount=1, defs=0x22cba8, defcount=2,
    owner=0x23102c) at ceval.c:1850
#5  0x273bc in call_function (func=0x230ffc, arg=0x2037c4, kw=0x1)
    at ceval.c:2772
#6  0x26e64 in PyEval_CallObjectWithKeywords (func=0x1b4efc, arg=0x1e33e4,
    kw=0x1a07d4) at ceval.c:2616
#7  0x45484 in PyInstance_New (class=0x23102c, arg=0x1e33e4, kw=0x1a07d4)
    at classobject.c:463
#8  0x26fd4 in call_builtin (func=0x23102c, arg=0x1e33e4, kw=0x1a07d4)
    at ceval.c:2653
#9  0x26e78 in PyEval_CallObjectWithKeywords (func=0x23102c, arg=0x1e33e4,
    kw=0x1a07d4) at ceval.c:2618
#10 0x2579c in eval_code2 (co=0x1b42c0, globals=0x1a07d4, locals=0x0,
    args=0x1b55dc, argcount=1705940, kws=0xffffffff, kwcount=0, defs=0x0,
---Type <return> to continue, or q <return> to quit---
    defcount=0, owner=0x187d3c) at ceval.c:1951
#11 0x273bc in call_function (func=0x1bb714, arg=0x1b40ec, kw=0x0)
    at ceval.c:2772
#12 0x26e64 in PyEval_CallObjectWithKeywords (func=0x1b53fc, arg=0x1c8654,
    kw=0x0) at ceval.c:2616
#13 0x45484 in PyInstance_New (class=0x187d3c, arg=0x1c8654, kw=0x0)
    at classobject.c:463
#14 0x26fd4 in call_builtin (func=0x187d3c, arg=0x1c8654, kw=0x0)
    at ceval.c:2653
#15 0x26e78 in PyEval_CallObjectWithKeywords (func=0x187d3c, arg=0x1c8654,
    kw=0x0) at ceval.c:2618
#16 0x2579c in eval_code2 (co=0x1b39b8, globals=0x0, locals=0x0,
    args=0x1b571c, argcount=0, kws=0xffffffff, kwcount=0, defs=0x0,
    defcount=0, owner=0x21b8a4) at ceval.c:1951
#17 0x273bc in call_function (func=0x222474, arg=0x184de4, kw=0x0)
    at ceval.c:2772
#18 0x26e64 in PyEval_CallObjectWithKeywords (func=0x1b5744, arg=0x175364,
    kw=0x0) at ceval.c:2616
#19 0x45484 in PyInstance_New (class=0x21b8a4, arg=0x175364, kw=0x0)
    at classobject.c:463
#20 0x26fd4 in call_builtin (func=0x21b8a4, arg=0x175364, kw=0x0)
    at ceval.c:2653
#21 0x26e78 in PyEval_CallObjectWithKeywords (func=0x21b8a4, arg=0x175364,
---Type <return> to continue, or q <return> to quit---
    kw=0x0) at ceval.c:2618
#22 0x2579c in eval_code2 (co=0x1b4148, globals=0x0, locals=0x0,
    args=0x1b6dc8, argcount=0, kws=0xffffffff, kwcount=0, defs=0x0,
    defcount=0, owner=0x0) at ceval.c:1951
#23 0x22584 in PyEval_EvalCode (co=0x1b4148, globals=0x180b54, locals=0x180b54)
    at ceval.c:319
#24 0x3a39c in run_node (n=0x175658, filename=0x1b4148 "", globals=0x180b54,
    locals=0x180b54) at pythonrun.c:886
#25 0x3a34c in run_err_node (n=0x175658, filename=0x1b4148 "",
    globals=0x180b54, locals=0x180b54) at pythonrun.c:874
#26 0x3a320 in PyRun_FileEx (fp=0x174f20, filename=0xffbef26b "problem.py",
    start=1529432, globals=0x180b54, locals=0x180b54, closeit=1)
    at pythonrun.c:866
#27 0x397e8 in PyRun_SimpleFileEx (fp=0x174f20,
    filename=0xffbef26b "problem.py", closeit=1) at pythonrun.c:579
#28 0x39390 in PyRun_AnyFileEx (fp=0x174f20, filename=0xffbef26b "problem.py",
    closeit=1) at pythonrun.c:459
#29 0x1ee08 in Py_Main (argc=2, argv=0xffbef144) at main.c:289
#30 0x1e74c in main (argc=2, argv=0xffbef144) at python.c:10


Follow-Ups:

Date: 2000-Oct-19 14:06
By: loewis

Comment:
A fix for that is in http://sourceforge.net/patch/?func=detailpatch&patch_id=101980&group_id=5470
-------------------------------------------------------

Date: 2000-Oct-27 04:56
By: gvanrossum

Comment:
Thanks for the fix, Martin. I'll have a look.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117278&group_id=5470


From noreply@sourceforge.net  Fri Oct 27 18:24:07 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 27 Oct 2000 10:24:07 -0700
Subject: [Python-bugs-list] [Bug #119556] Python 2.0 httplib doesn't like ICY status lines
Message-ID: <200010271724.KAA15224@sf-web1.i.sourceforge.net>

Bug #119556, was updated on 2000-Oct-27 10:24
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Python 2.0 httplib doesn't like ICY status lines

Details: 
I have a Python script that captures streaming audio on the Internet.
The homepage is at http://beam-back.sourceforge.net  It works fine
with Python 1.5.2 and Python 1.6.  One of my users noticed the script
is broken under Python 2.0.

In the getreply function of httplib.py in Python 1.5.2, even if 
ver[:5] != 'HTTP/', the connection is left open.  I depend on this 
behavior because streaming audio links found at 
http://www.shoutcast.com/ return a status line like this:

ICY 200 OK

Under Python 1.6 and 1.5.2, I can happily go on and use getfile() to
obtain the data on the connection.

In the getreply function of httplib.py in Python 2.0, the BadStatusLine
exception (raised by ver[:5] != 'HTTP/' in begin) causes the connection
to be closed.

I'm writing to find out how I could go about discussing a possible
return to the previous behavior in future releases of Python.  If
that is not feasible, I would be appreciative of any advice on how
I should go about porting the script to Python 2.0.

Regards,
--Kal




For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119556&group_id=5470


From noreply@sourceforge.net  Fri Oct 27 18:46:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 27 Oct 2000 10:46:59 -0700
Subject: [Python-bugs-list] [Bug #119558] bsddb module doesn't check return value of malloc()
Message-ID: <200010271746.KAA19079@sf-web2.i.sourceforge.net>

Bug #119558, was updated on 2000-Oct-27 10:46
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: bsddb module doesn't check return value of malloc()

Details: The bsddbmodule often uses code like this:

if (krec.size > sizeof(buf)) data = malloc(krec.size);
else data = buf;
memcpy(data,krec.data,krec.size);

If malloc() returns NULL, this will do a memcpy() using
NULL as the dest point.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119558&group_id=5470


From noreply@sourceforge.net  Sat Oct 28 11:50:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 28 Oct 2000 03:50:40 -0700
Subject: [Python-bugs-list] [Bug #117508] Building 2.0 under Solaris 8 with GCC 2.95.2 fails to link
Message-ID: <200010281050.DAA02924@sf-web2.i.sourceforge.net>

Bug #117508, was updated on 2000-Oct-23 10:16
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: Building 2.0 under Solaris 8 with GCC 2.95.2 fails to link

Details: With no special options to 'configure' the final link step results in

   cd Modules;  make OPT="-g -O2 -Wall -Wstrict-prototypes" VERSION="2.0" \
                   prefix="/usr/local" exec_prefix="/usr/local" \
                   LIBRARY=../libpython2.0.a link
   make[1]: Entering directory `/tmp/pedwards/newbuild/Python-2.0/Modules'
   gcc   python.o \
             ../libpython2.0.a -ldb                                 -lpthread -lsocket -lnsl -ldl  -lthread -lm  -o python 
   Undefined                       first referenced
    symbol                             in file
   dbopen                              ../libpython2.0.a(bsddbmodule.o)
   ld: fatal: Symbol referencing errors. No output written to python
   collect2: ld returned 1 exit status
   make[1]: *** [link] Error 1

This is using GNU make, and GCC with the native linker.  Using the native
compiler works fine.  



Follow-Ups:

Date: 2000-Oct-28 03:50
By: loewis

Comment:
It appears that configure detected the presence of db.h on your system, perhaps in /usr/local. Do you have a BSDDB installation there? Could it be that this installation is somehow corrupted (e.g. that the db.h header does not match the libdb.a library?). That would explain why the native compiler has no problems - it simply doesn't see the db.h header in /usr/local, so it doesn't even attempt to build bsddbmodule.o.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117508&group_id=5470


From noreply@sourceforge.net  Sat Oct 28 12:42:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 28 Oct 2000 04:42:25 -0700
Subject: [Python-bugs-list] [Bug #119622] Python 2.0 compile errors ...
Message-ID: <200010281142.EAA29629@sf-web1.i.sourceforge.net>

Bug #119622, was updated on 2000-Oct-28 04:42
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Python 2.0 compile errors ...

Details: 
Hi,

the modules marshal.c and compile.c causes compilation errors because of several 
'extern double atof()' declarations when Python 2.0 will be compiled with gcc or Watcom 10.6.

IMHO ... these statements are misplaced and useless because the extern declaration of atof() is allready
included in the standard header.

Regards

 

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119622&group_id=5470


From noreply@sourceforge.net  Sat Oct 28 13:11:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 28 Oct 2000 05:11:44 -0700
Subject: [Python-bugs-list] [Bug #110631] Debugger (win and idle) (PR#283)
Message-ID: <200010281211.FAA28343@sf-web3.vaspecialprojects.com>

Bug #110631, was updated on 2000-Jul-31 14:09
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: Debugger (win and idle) (PR#283)

Details: Jitterbug-Id: 283
Submitted-By: musingattheruins@yahoo.com
Date: Mon, 10 Apr 2000 12:30:44 -0400 (EDT)
Version: 1.5.2
OS: Win32


The python debugger (both Idle and PythonWin) does not undertand packages.  Can
run scripts from the command line that cannot be run in the debugger...

Create package 'Test' in the directory "My Modules", add an __init__.py (empty)
to the directory "My modules\Test", create file testfile.py with the
contents...

class TheTest:
   def __init__(self):
      self.i = 1

   def go(self):
      return self.i

Add the path to the Python path with the following file (test.reg)...

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\1.5\PythonPath\TheTest]
@="C:\\My modules"

then try the following at the python prompt:

import Test.testfile
j = Test.testfile.TheTest() 
k = j.go

runs fine right? Yes it does, now step through it in the debugger and you
get...

import Test.testfile
j = Test.testfile.TheTest() #exception: attribute 'TheTest'
k = j.go

Does not appear to be realted to the class (you can change it to a 'function in
a module' instead of a 'method in a class in a module' and you get the a similar
result.)

Debugger does not understand packages.



====================================================================
Audit trail:
Tue Jul 11 08:29:15 2000	guido	moved from incoming to open

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110631&group_id=5470


From noreply@sourceforge.net  Sat Oct 28 13:23:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 28 Oct 2000 05:23:08 -0700
Subject: [Python-bugs-list] [Bug #119622] Python 2.0 compile errors ...
Message-ID: <200010281223.FAA28504@sf-web3.vaspecialprojects.com>

Bug #119622, was updated on 2000-Oct-28 04:42
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Python 2.0 compile errors ...

Details: 
Hi,

the modules marshal.c and compile.c causes compilation errors because of several 
'extern double atof()' declarations when Python 2.0 will be compiled with gcc or Watcom 10.6.

IMHO ... these statements are misplaced and useless because the extern declaration of atof() is allready
included in the standard header.

Regards

 

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119622&group_id=5470


From noreply@sourceforge.net  Sat Oct 28 14:37:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 28 Oct 2000 06:37:54 -0700
Subject: [Python-bugs-list] [Bug #117242] Negative lookbehind fails
Message-ID: <200010281337.GAA31148@sf-web1.i.sourceforge.net>

Bug #117242, was updated on 2000-Oct-18 15:47
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Negative lookbehind fails

Details: Found by Robin Becker and reported on comp.lang.python...
The following example program doesn't match, and it seems like it 
should.

import re
wpat = re.compile(r'(?<!self\.)\b([A-Za-z_]\w*)\s*\(')
m = wpat.search('   a(')


Follow-Ups:

Date: 2000-Oct-20 09:26
By: akuchling

Comment:
Patch #101972 is a proposed fix for this bug.
-------------------------------------------------------

Date: 2000-Oct-28 06:37
By: effbot

Comment:
fixed in my local copy.  I'll update the CVS version as
soon as I've updated the regression suite.

thanks /F

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117242&group_id=5470


From noreply@sourceforge.net  Sat Oct 28 14:39:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 28 Oct 2000 06:39:46 -0700
Subject: [Python-bugs-list] [Bug #117612] sre gives wrong groups with findall and empty groups
Message-ID: <200010281339.GAA31171@sf-web1.i.sourceforge.net>

Bug #117612, was updated on 2000-Oct-24 11:01
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: sre gives wrong groups with findall and empty groups

Details: the following:

r = re.compile (r'(a|(b))')
print r.findall (r'aba')

produces with sre

[('a', ''), ('b', 'b'), ('a', 'b')]

instead of the correct behaviour of pre (and Python 1.5.2)

[('a', ''), ('b', 'b'), ('a', '')]

(Note the wrong 'b' in the last tuple. It seems like groups are not initialized and keep the value of the previous match).

Tested with BeOpen Python 2.0 final (Oct. 16th) under Linux 2.2.14 (S.u.S.E 6.4)

Follow-Ups:

Date: 2000-Oct-28 06:39
By: effbot

Comment:
the local match state isn't properly reset between items.

fixed in my local copy.  I'll update the CVS version as
soon as I've fixed the regression suite.

thanks /F
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117612&group_id=5470


From noreply@sourceforge.net  Sat Oct 28 19:53:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 28 Oct 2000 11:53:50 -0700
Subject: [Python-bugs-list] [Bug #117242] Negative lookbehind fails
Message-ID: <200010281853.LAA01847@sf-web3.vaspecialprojects.com>

Bug #117242, was updated on 2000-Oct-18 15:47
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: Negative lookbehind fails

Details: Found by Robin Becker and reported on comp.lang.python...
The following example program doesn't match, and it seems like it 
should.

import re
wpat = re.compile(r'(?<!self\.)\b([A-Za-z_]\w*)\s*\(')
m = wpat.search('   a(')


Follow-Ups:

Date: 2000-Oct-20 09:26
By: akuchling

Comment:
Patch #101972 is a proposed fix for this bug.
-------------------------------------------------------

Date: 2000-Oct-28 06:37
By: effbot

Comment:
fixed in my local copy.  I'll update the CVS version as
soon as I've updated the regression suite.

thanks /F

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117242&group_id=5470


From noreply@sourceforge.net  Sat Oct 28 19:58:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 28 Oct 2000 11:58:29 -0700
Subject: [Python-bugs-list] [Bug #119221] Include/graminit.h and Parser/graminit.c erroneously in dist
Message-ID: <200010281858.LAA01931@sf-web3.vaspecialprojects.com>

Bug #119221, was updated on 2000-Oct-25 22:03
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Include/graminit.h and Parser/graminit.c erroneously in dist

Details: I install for multiple architectures by first unpacking the tar file into a read-only directory, then symlinking the files into a shadow tree, via X11 'lndir'.  Worked fine on Python 1.*.  With 2.0, however, the files Include/graminit.h and Parser/graminit.c are supplied in the tar file, and also generated by the build process.  Of course, they cannot be copied into their respective directories, because the files they are overwriting are in a read-only volume.

Follow-Ups:

Date: 2000-Oct-28 11:58
By: effbot

Comment:
Note that these files are not generated on all platforms; if you remove them, you'll break all non-Unix builds.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119221&group_id=5470


From noreply@sourceforge.net  Sat Oct 28 19:59:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 28 Oct 2000 11:59:12 -0700
Subject: [Python-bugs-list] [Bug #117612] sre gives wrong groups with findall and empty groups
Message-ID: <200010281859.LAA01950@sf-web3.vaspecialprojects.com>

Bug #117612, was updated on 2000-Oct-24 11:01
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Summary: sre gives wrong groups with findall and empty groups

Details: the following:

r = re.compile (r'(a|(b))')
print r.findall (r'aba')

produces with sre

[('a', ''), ('b', 'b'), ('a', 'b')]

instead of the correct behaviour of pre (and Python 1.5.2)

[('a', ''), ('b', 'b'), ('a', '')]

(Note the wrong 'b' in the last tuple. It seems like groups are not initialized and keep the value of the previous match).

Tested with BeOpen Python 2.0 final (Oct. 16th) under Linux 2.2.14 (S.u.S.E 6.4)

Follow-Ups:

Date: 2000-Oct-28 06:39
By: effbot

Comment:
the local match state isn't properly reset between items.

fixed in my local copy.  I'll update the CVS version as
soon as I've fixed the regression suite.

thanks /F
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117612&group_id=5470


From noreply@sourceforge.net  Sat Oct 28 20:32:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 28 Oct 2000 12:32:27 -0700
Subject: [Python-bugs-list] [Bug #110866] re group self-reference weird behavior (PR#2)
Message-ID: <200010281932.MAA02396@sf-web3.vaspecialprojects.com>

Bug #110866, was updated on 2000-Aug-01 14:41
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: re group self-reference weird behavior (PR#2)

Details: Jitterbug-Id: 2
Submitted-By: guido@python.org
Date: Mon, 12 Jul 1999 15:03:24 -0400 (EDT)
Version: 1.5.2
OS: Unix, Windows


Try the following:

import re
re.search("((.)\\1+)","a")

This isn't proper syntax (you shouldn't reference a group
inside itself), but it seems to hang -- in fact it takes
several minutes to execute.

Possibly it runs out of some resource on its path to infinite
recursion and then backtracks?


====================================================================
Audit trail:
Mon Jul 12 15:33:07 1999	guido	moved from incoming to open
Mon Jul 12 19:02:35 1999	guido	changed notes
Thu Jul 13 20:28:48 2000	fdrake	changed notes
Thu Jul 13 20:28:48 2000	fdrake	changed notification
Thu Jul 13 20:28:48 2000	fdrake	moved from open to 3rdpartybug

Follow-Ups:

Date: 2000-Aug-01 14:41
By: none

Comment:
AMK: pcre bug that's been fixed in more recent releases, but that's no longer
relevant with SRE in the picture.
-------------------------------------------------------

Date: 2000-Aug-09 02:27
By: effbot

Comment:
on the other hand, SRE says "nothing to repeat" -- which isn't really what it should do.  Looks like the width calculation messes up on GROUPREF's...

I've reassigned it to myself!
-------------------------------------------------------

Date: 2000-Sep-30 21:31
By: gvanrossum

Comment:
Fredrik, this is almost 2 months old now. Did you ever fix this?
-------------------------------------------------------

Date: 2000-Oct-08 03:03
By: effbot

Comment:
PRE still hangs, SRE always fails (an undefined group
simply cannot match anything...)
-------------------------------------------------------

Date: 2000-Oct-08 10:49
By: tim_one

Comment:
Sorry, I opened this again:  that, e.g., r"(a\1)" can never match is better than the earlier behavior, but it *should* be treated as Guido originally characterized it:  as an ill-formed regexp.  That is, it should raise an exception at regexp compile time, same as r"[a" or r"(a" etc.  A reference to group N before group N has been closed simply doesn't make sense, and is certainly a user error.
-------------------------------------------------------

Date: 2000-Oct-08 13:46
By: none

Comment:
Fair enough.  I can fix this.  But not in time for 2.0 final...

</F>
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110866&group_id=5470


From noreply@sourceforge.net  Sun Oct 29 01:24:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 28 Oct 2000 17:24:06 -0700
Subject: [Python-bugs-list] [Bug #119645] distutils.sysconfig.LINKFORSHARED is undefined
Message-ID: <200010290024.RAA07594@sf-web1.i.sourceforge.net>

Bug #119645, was updated on 2000-Oct-28 17:24
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: distutils.sysconfig.LINKFORSHARED is undefined

Details: The current documentation (in http://www.python.org/doc/current/ext/link-reqs.html) says to check the value of distutils.sysconfig.LINKFORSHARED in order to get compiler options for embedding Python.  However, this value is undefined in Python 2.0, installed on a RedHat Linux system from the RPMs on www.python.org:

>>> import distutils.sysconfig
>>> distutils.sysconfig.LINKFORSHARED 
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: LINKFORSHARED


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119645&group_id=5470


From noreply@sourceforge.net  Sun Oct 29 01:46:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 28 Oct 2000 17:46:30 -0700
Subject: [Python-bugs-list] [Bug #117278] re-opening of bug #117167
Message-ID: <200010290046.RAA17373@sf-web2.i.sourceforge.net>

Bug #117278, was updated on 2000-Oct-19 09:12
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: re-opening of bug #117167

Details: As directed, I'm reopening the bug #117167 (_tkinter segfaults on "syntax error"), because it was closed on incorrect assumptions:
- I believe I am using Python 2.0 final ( python -V says
'python 2.0'; the file I downloaded is named BeOpen-Python-2.0.tar.bz2 ).
- tkinter is a static module, therefore there is no possibility of still using the old one.

----
Additional info :

I verified the same behaviour on Solaris 2.0, with tcl/tk 8.3.1 and gcc 2.8.1. Hereaftter there is the output of gdb 'where' command, obtained from thye dumped core.

---------- output of where ---------------------------

#0  0x94464 in Tkapp_Call (self=0x1b80c0, args=0x18c67c) at ./_tkinter.c:644
#1  0x26fac in call_builtin (func=0x1b80a8, arg=0x18c67c, kw=0x0)
    at ceval.c:2650
#2  0x26e78 in PyEval_CallObjectWithKeywords (func=0x1b80a8, arg=0x229134,
    kw=0x0) at ceval.c:2618
#3  0x2579c in eval_code2 (co=0x1e9ff8, globals=0x0, locals=0x0,
    args=0x18c67c, argcount=0, kws=0xffffffff, kwcount=0, defs=0x22e810,
    defcount=3, owner=0x22e864) at ceval.c:1951
#4  0x253d8 in eval_code2 (co=0x1fae00, globals=0x0, locals=0x18c67c,
    args=0x17a160, argcount=2, kws=0x5, kwcount=1, defs=0x22cba8, defcount=2,
    owner=0x23102c) at ceval.c:1850
#5  0x273bc in call_function (func=0x230ffc, arg=0x2037c4, kw=0x1)
    at ceval.c:2772
#6  0x26e64 in PyEval_CallObjectWithKeywords (func=0x1b4efc, arg=0x1e33e4,
    kw=0x1a07d4) at ceval.c:2616
#7  0x45484 in PyInstance_New (class=0x23102c, arg=0x1e33e4, kw=0x1a07d4)
    at classobject.c:463
#8  0x26fd4 in call_builtin (func=0x23102c, arg=0x1e33e4, kw=0x1a07d4)
    at ceval.c:2653
#9  0x26e78 in PyEval_CallObjectWithKeywords (func=0x23102c, arg=0x1e33e4,
    kw=0x1a07d4) at ceval.c:2618
#10 0x2579c in eval_code2 (co=0x1b42c0, globals=0x1a07d4, locals=0x0,
    args=0x1b55dc, argcount=1705940, kws=0xffffffff, kwcount=0, defs=0x0,
---Type <return> to continue, or q <return> to quit---
    defcount=0, owner=0x187d3c) at ceval.c:1951
#11 0x273bc in call_function (func=0x1bb714, arg=0x1b40ec, kw=0x0)
    at ceval.c:2772
#12 0x26e64 in PyEval_CallObjectWithKeywords (func=0x1b53fc, arg=0x1c8654,
    kw=0x0) at ceval.c:2616
#13 0x45484 in PyInstance_New (class=0x187d3c, arg=0x1c8654, kw=0x0)
    at classobject.c:463
#14 0x26fd4 in call_builtin (func=0x187d3c, arg=0x1c8654, kw=0x0)
    at ceval.c:2653
#15 0x26e78 in PyEval_CallObjectWithKeywords (func=0x187d3c, arg=0x1c8654,
    kw=0x0) at ceval.c:2618
#16 0x2579c in eval_code2 (co=0x1b39b8, globals=0x0, locals=0x0,
    args=0x1b571c, argcount=0, kws=0xffffffff, kwcount=0, defs=0x0,
    defcount=0, owner=0x21b8a4) at ceval.c:1951
#17 0x273bc in call_function (func=0x222474, arg=0x184de4, kw=0x0)
    at ceval.c:2772
#18 0x26e64 in PyEval_CallObjectWithKeywords (func=0x1b5744, arg=0x175364,
    kw=0x0) at ceval.c:2616
#19 0x45484 in PyInstance_New (class=0x21b8a4, arg=0x175364, kw=0x0)
    at classobject.c:463
#20 0x26fd4 in call_builtin (func=0x21b8a4, arg=0x175364, kw=0x0)
    at ceval.c:2653
#21 0x26e78 in PyEval_CallObjectWithKeywords (func=0x21b8a4, arg=0x175364,
---Type <return> to continue, or q <return> to quit---
    kw=0x0) at ceval.c:2618
#22 0x2579c in eval_code2 (co=0x1b4148, globals=0x0, locals=0x0,
    args=0x1b6dc8, argcount=0, kws=0xffffffff, kwcount=0, defs=0x0,
    defcount=0, owner=0x0) at ceval.c:1951
#23 0x22584 in PyEval_EvalCode (co=0x1b4148, globals=0x180b54, locals=0x180b54)
    at ceval.c:319
#24 0x3a39c in run_node (n=0x175658, filename=0x1b4148 "", globals=0x180b54,
    locals=0x180b54) at pythonrun.c:886
#25 0x3a34c in run_err_node (n=0x175658, filename=0x1b4148 "",
    globals=0x180b54, locals=0x180b54) at pythonrun.c:874
#26 0x3a320 in PyRun_FileEx (fp=0x174f20, filename=0xffbef26b "problem.py",
    start=1529432, globals=0x180b54, locals=0x180b54, closeit=1)
    at pythonrun.c:866
#27 0x397e8 in PyRun_SimpleFileEx (fp=0x174f20,
    filename=0xffbef26b "problem.py", closeit=1) at pythonrun.c:579
#28 0x39390 in PyRun_AnyFileEx (fp=0x174f20, filename=0xffbef26b "problem.py",
    closeit=1) at pythonrun.c:459
#29 0x1ee08 in Py_Main (argc=2, argv=0xffbef144) at main.c:289
#30 0x1e74c in main (argc=2, argv=0xffbef144) at python.c:10


Follow-Ups:

Date: 2000-Oct-19 14:06
By: loewis

Comment:
A fix for that is in http://sourceforge.net/patch/?func=detailpatch&patch_id=101980&group_id=5470
-------------------------------------------------------

Date: 2000-Oct-27 04:56
By: gvanrossum

Comment:
Thanks for the fix, Martin. I'll have a look.
-------------------------------------------------------

Date: 2000-Oct-28 17:46
By: loewis

Comment:
Fixed in _tkinter.c 1.115.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117278&group_id=5470


From noreply@sourceforge.net  Sun Oct 29 01:47:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 28 Oct 2000 17:47:04 -0700
Subject: [Python-bugs-list] [Bug #117167] _tkinter module segfaults on "syntax error"
Message-ID: <200010290047.RAA17395@sf-web2.i.sourceforge.net>

Bug #117167, was updated on 2000-Oct-18 04:52
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: _tkinter module segfaults on "syntax error"

Details: The following listing contains a syntax error (remarked by
a comment ) which causes the python interpreter to segfault
inside _tkinter module.
the problem has been verified on Python 2.0 compiled from source on Debian GNU/Linux 2.2. It was also present on Python 1.6, on the same platform as well as on SUN/Solaris 7.0 (still compiled with gcc).
#
# --- begin listing
#
from Tkinter import *
from string import *



    
# ============================================================================
class DemoWindow( Toplevel ):
    """
    <snip>
    """
    instance = None
    
    def __init__( self,  introduction, code_file ):
        Toplevel.__init__(self)
        
        DemoWindow.instance = self

        # store object attributes
        self.code_file = code_file

        # create and pack the introduction label
        intro_label=Label(self, text=introduction)
        intro_label.pack(side=TOP)

        # this is the frame which contains the two buttons at the end
        button_frame = Frame( self )
        button_frame.pack( side=BOTTOM, pady='2m', fill=X )
        


# --- button.py
# This module demonstrates simple buttons
# It is meant to be called by the demo widget main module
# but it can also run stand-alone
#

class ButtonsDemoWindow( DemoWindow ):
    """
    A demo window with some buttons which changes the demo
    window behaviour
    """
    def __init__( self ):
        intro="""If you click on any of the four buttons below, the background
        <SNIP>
        invoke the current button."""

        # BUG ! This is the syntax error which triggers the bug.        
        DemoWindow(self, intro )
        # It should have been DemoWindow.__init__(self, intro, 'problem.py')

        frame=Frame()
        frame.pack(expand=YES, fill=BOTH )
        for c in ('Peach Puff', 'Light Blue1',
                  'Sea Green2', 'Yellow1' ):
            b = Button(self, text=c)
            b['command'] = callit( self.callback, c );
            
            b.pack( side=top, expand=yes, pady=2,
                    command=callit(self.callback, color) )

    def callback(self, color):
        self.frame['background']=color
            



if __name__ == '__main__':
    ButtonsDemoWindow() 
    mainloop()
 

Follow-Ups:

Date: 2000-Oct-18 08:04
By: gvanrossum

Comment:
I get a core dump with 2.0b2 but the expected exception with 2.0. Several significant bugs in _tkinter were present in 2.0b2 that were fixed in 2.0final. I'm closing this report assuming that you were using 2.0b2 or earlier. if you still have this with 2.0, first check that you don't have an older version of _tkinter.so lying around; if it persists, please resubmit the bug report.

(It's not technically a syntax error, it's a call with bogus arguments. :-)
-------------------------------------------------------

Date: 2000-Oct-19 14:08
By: loewis

Comment:
A fix for that bug is in http://sourceforge.net/patch/?func=detailpatch&patch_id=101980&group_id=5470
-------------------------------------------------------

Date: 2000-Oct-28 17:47
By: loewis

Comment:
Fixed with _tkinter 1.115.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117167&group_id=5470


From noreply@sourceforge.net  Sun Oct 29 01:49:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 28 Oct 2000 17:49:25 -0700
Subject: [Python-bugs-list] [Bug #117556] Python 2.0 regression fails on test_pyexpat.
Message-ID: <200010290049.RAA17461@sf-web2.i.sourceforge.net>

Bug #117556, was updated on 2000-Oct-23 18:18
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Python 2.0 regression fails on test_pyexpat.

Details: Regression fails on test_pyexpat with the following message:

test test_pyexpat failed -- Writing: "('xml=http://www.w3.org/XML/1998/namespace\\014external_entity', None, 'entity.file', None)", expected: "('http://www.python.org/namespace=http://www.w3.org/XML/1998/namespace\\014external_entity'"

This is on Python 2.0 final with expat 1.2 both compiled on Solaris 7 x86 with SunPro 4.2.

Follow-Ups:

Date: 2000-Oct-24 10:25
By: garthc

Comment:
Submitted by garthc (was not registered at the time).
-------------------------------------------------------

Date: 2000-Oct-28 17:49
By: loewis

Comment:
This appears to be an incompatibility between expat 1.1 and expat 1.2. I don't know which one is correct, though.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117556&group_id=5470


From noreply@sourceforge.net  Sun Oct 29 01:12:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 28 Oct 2000 18:12:16 -0700
Subject: [Python-bugs-list] [Bug #119556] Python 2.0 httplib doesn't like ICY status lines
Message-ID: <200010290112.SAA17959@sf-web2.i.sourceforge.net>

Bug #119556, was updated on 2000-Oct-27 10:24
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Python 2.0 httplib doesn't like ICY status lines

Details: 
I have a Python script that captures streaming audio on the Internet.
The homepage is at http://beam-back.sourceforge.net  It works fine
with Python 1.5.2 and Python 1.6.  One of my users noticed the script
is broken under Python 2.0.

In the getreply function of httplib.py in Python 1.5.2, even if 
ver[:5] != 'HTTP/', the connection is left open.  I depend on this 
behavior because streaming audio links found at 
http://www.shoutcast.com/ return a status line like this:

ICY 200 OK

Under Python 1.6 and 1.5.2, I can happily go on and use getfile() to
obtain the data on the connection.

In the getreply function of httplib.py in Python 2.0, the BadStatusLine
exception (raised by ver[:5] != 'HTTP/' in begin) causes the connection
to be closed.

I'm writing to find out how I could go about discussing a possible
return to the previous behavior in future releases of Python.  If
that is not feasible, I would be appreciative of any advice on how
I should go about porting the script to Python 2.0.

Regards,
--Kal




Follow-Ups:

Date: 2000-Oct-28 18:12
By: loewis

Comment:
The response of the server clearly violates RFC 2616, section 6.1. Where is the documentation for the protocol that this server implements? If you need to support this protocol (which clearly is not HTTP), you need to implement your own response class (perhaps inheriting from HTTPResponse if possible).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119556&group_id=5470


From noreply@sourceforge.net  Sun Oct 29 02:17:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 28 Oct 2000 19:17:57 -0700
Subject: [Python-bugs-list] [Bug #117508] Building 2.0 under Solaris 8 with GCC 2.95.2 fails to link
Message-ID: <200010290217.TAA18872@sf-web2.i.sourceforge.net>

Bug #117508, was updated on 2000-Oct-23 10:16
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: Building 2.0 under Solaris 8 with GCC 2.95.2 fails to link

Details: With no special options to 'configure' the final link step results in

   cd Modules;  make OPT="-g -O2 -Wall -Wstrict-prototypes" VERSION="2.0" \
                   prefix="/usr/local" exec_prefix="/usr/local" \
                   LIBRARY=../libpython2.0.a link
   make[1]: Entering directory `/tmp/pedwards/newbuild/Python-2.0/Modules'
   gcc   python.o \
             ../libpython2.0.a -ldb                                 -lpthread -lsocket -lnsl -ldl  -lthread -lm  -o python 
   Undefined                       first referenced
    symbol                             in file
   dbopen                              ../libpython2.0.a(bsddbmodule.o)
   ld: fatal: Symbol referencing errors. No output written to python
   collect2: ld returned 1 exit status
   make[1]: *** [link] Error 1

This is using GNU make, and GCC with the native linker.  Using the native
compiler works fine.  



Follow-Ups:

Date: 2000-Oct-28 03:50
By: loewis

Comment:
It appears that configure detected the presence of db.h on your system, perhaps in /usr/local. Do you have a BSDDB installation there? Could it be that this installation is somehow corrupted (e.g. that the db.h header does not match the libdb.a library?). That would explain why the native compiler has no problems - it simply doesn't see the db.h header in /usr/local, so it doesn't even attempt to build bsddbmodule.o.
-------------------------------------------------------

Date: 2000-Oct-28 19:17
By: devphil

Comment:
Incredible.  I file a bug on Python, and end up discovering a bug in BSDDB.

There is a BSDDB locally installed...

    % ls -l /usr/local/include/db.h
    lrwxrwxrwx   1     38 Dec  7  1999 /usr/local/include/db.h -> xxx/db-2.7.7/BerkeleyDB/include/db.h
    % ls -l /usr/local/lib/libdb.a 
    lrwxrwxrwx   1     37 Dec  7  1999 /usr/local/lib/libdb.a -> xxx/db-2.7.7/BerkeleyDB/lib/libdb.a

...but they do match up, and -ldb is passed on the link line.  There is no dbopen()
in db.h, only db_open(), and that function is in the library.  The dbopen() function is
in db_185.h, but BSDDB 1.85 compatability has to be specifically enabled when building
BSDDB.  We didn't request it, because we don't need it.  So it didn't get built, and
that is correct behavior.

However, BSDDB installs db_185.h unconditionally, even if the actual implemantion is
left out of the library.  And bsddbmodule looks for db_185.h before db.h.  (This might
have been corrected; I'm looking through source from 2.7.7 which is 14 months old.)

Guess I need to tell BSDDB folks to actually *check* to see if 1.85 support was
requested by the user before installing the header.  Grrrrr...

Thanks for pointing that out.  I try to stay away from databases when possible,
and would never think on my own to look for this.


-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117508&group_id=5470


From noreply@sourceforge.net  Sun Oct 29 09:28:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 29 Oct 2000 01:28:31 -0800
Subject: [Python-bugs-list] [Bug #119662] python2.0 fails to build on RedHat7.0
Message-ID: <200010290928.BAA24857@sf-web2.i.sourceforge.net>

Bug #119662, was updated on 2000-Oct-29 01:28
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: python2.0 fails to build on RedHat7.0

Details: Probably because of the change in RH7 to gcc2.96 
the compilation bombs out in Include/pyport.h 
this can be circumvented by uncommenting the if endif 
pair immmediately before the line in pyport.h where
the error is reported

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119662&group_id=5470


From noreply@sourceforge.net  Sun Oct 29 17:54:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 29 Oct 2000 09:54:46 -0800
Subject: [Python-bugs-list] [Bug #119662] python2.0 fails to build on RedHat7.0
Message-ID: <200010291754.JAA23536@sf-web1.i.sourceforge.net>

Bug #119662, was updated on 2000-Oct-29 01:28
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Wont Fix
Bug Group: Not a Bug
Priority: 5
Summary: python2.0 fails to build on RedHat7.0

Details: Probably because of the change in RH7 to gcc2.96 
the compilation bombs out in Include/pyport.h 
this can be circumvented by uncommenting the if endif 
pair immmediately before the line in pyport.h where
the error is reported

Follow-Ups:

Date: 2000-Oct-29 09:54
By: jhylton

Comment:
We will not make a change in the Python source tree to work around a broken Linux distro.  It is straightforward to fix this yourself.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119662&group_id=5470


From noreply@sourceforge.net  Sun Oct 29 17:55:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 29 Oct 2000 09:55:56 -0800
Subject: [Python-bugs-list] [Bug #119558] bsddb module doesn't check return value of malloc()
Message-ID: <200010291755.JAA23581@sf-web1.i.sourceforge.net>

Bug #119558, was updated on 2000-Oct-27 10:46
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: bsddb module doesn't check return value of malloc()

Details: The bsddbmodule often uses code like this:

if (krec.size > sizeof(buf)) data = malloc(krec.size);
else data = buf;
memcpy(data,krec.data,krec.size);

If malloc() returns NULL, this will do a memcpy() using
NULL as the dest point.


Follow-Ups:

Date: 2000-Oct-29 09:55
By: jhylton

Comment:
Do you want to fix it?  Or should we wait for your new module?

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119558&group_id=5470


From noreply@sourceforge.net  Sun Oct 29 17:56:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 29 Oct 2000 09:56:54 -0800
Subject: [Python-bugs-list] [Bug #119645] distutils.sysconfig.LINKFORSHARED is undefined
Message-ID: <200010291756.JAA23589@sf-web1.i.sourceforge.net>

Bug #119645, was updated on 2000-Oct-28 17:24
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: distutils.sysconfig.LINKFORSHARED is undefined

Details: The current documentation (in http://www.python.org/doc/current/ext/link-reqs.html) says to check the value of distutils.sysconfig.LINKFORSHARED in order to get compiler options for embedding Python.  However, this value is undefined in Python 2.0, installed on a RedHat Linux system from the RPMs on www.python.org:

>>> import distutils.sysconfig
>>> distutils.sysconfig.LINKFORSHARED 
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: LINKFORSHARED


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119645&group_id=5470


From noreply@sourceforge.net  Sun Oct 29 17:57:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 29 Oct 2000 09:57:18 -0800
Subject: [Python-bugs-list] [Bug #119556] Python 2.0 httplib doesn't like ICY status lines
Message-ID: <200010291757.JAA23594@sf-web1.i.sourceforge.net>

Bug #119556, was updated on 2000-Oct-27 10:24
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Python 2.0 httplib doesn't like ICY status lines

Details: 
I have a Python script that captures streaming audio on the Internet.
The homepage is at http://beam-back.sourceforge.net  It works fine
with Python 1.5.2 and Python 1.6.  One of my users noticed the script
is broken under Python 2.0.

In the getreply function of httplib.py in Python 1.5.2, even if 
ver[:5] != 'HTTP/', the connection is left open.  I depend on this 
behavior because streaming audio links found at 
http://www.shoutcast.com/ return a status line like this:

ICY 200 OK

Under Python 1.6 and 1.5.2, I can happily go on and use getfile() to
obtain the data on the connection.

In the getreply function of httplib.py in Python 2.0, the BadStatusLine
exception (raised by ver[:5] != 'HTTP/' in begin) causes the connection
to be closed.

I'm writing to find out how I could go about discussing a possible
return to the previous behavior in future releases of Python.  If
that is not feasible, I would be appreciative of any advice on how
I should go about porting the script to Python 2.0.

Regards,
--Kal




Follow-Ups:

Date: 2000-Oct-28 18:12
By: loewis

Comment:
The response of the server clearly violates RFC 2616, section 6.1. Where is the documentation for the protocol that this server implements? If you need to support this protocol (which clearly is not HTTP), you need to implement your own response class (perhaps inheriting from HTTPResponse if possible).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119556&group_id=5470


From noreply@sourceforge.net  Mon Oct 30 00:11:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 29 Oct 2000 16:11:43 -0800
Subject: [Python-bugs-list] [Bug #119707] urllib failure when return code not 200
Message-ID: <200010300011.QAA29110@sf-web1.i.sourceforge.net>

Bug #119707, was updated on 2000-Oct-29 16:11
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: urllib failure when return code not 200

Details: urllib fails sometimes.

A traceback follows but the problem is that, on line 286, fp is used as a parameter when it has a value of None. Not sure why; HTTP.getreply seems like it always returns a file. Not time right now to look further into it...

brian@sweetapp.com

Traceback (most recent call last):
  File "/usr/home/sweetapp/public_html/zonewatcher/Rating", line 83, in ?
    UpdatePlayerRatings( database, zonePlayer )
  File "/usr/home/sweetapp/public_html/zonewatcher/Rating", line 59, in UpdatePlayerRatings
    mainRatings = GetMainRatings( zonePlayer.GetZoneName( ), AOEIImainRating, AOEIIexpansionMainRating )
  File "/usr/home/sweetapp/public_html/zonewatcher/Rating", line 20, in GetMainRatings
    ratingsPage = GetRatingsPage( zoneID )
  File "/usr/home/sweetapp/public_html/zonewatcher/Rating", line 14, in GetRatingsPage
    url = urllib.urlopen( 'http://www.zone.com/Profile/RatingsPlayer.asp?PlayerID=' + zoneID )
  File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 61, in urlopen
    return _urlopener.open(url)
  File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 166, in open
    return getattr(self, name)(url)
  File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 286, in open_http
    return self.http_error(url, fp, errcode, errmsg, headers)
  File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 303, in http_error
    return self.http_error_default(url, fp, errcode, errmsg, headers)
  File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 518, in http_error_default
    return addinfourl(fp, headers, "http:" + url)
  File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 772, in __init__
    addbase.__init__(self, fp)
  File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 726, in __init__
    self.read = self.fp.read
AttributeError: 'None' object has no attribute 'read'

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119707&group_id=5470


From noreply@sourceforge.net  Mon Oct 30 00:20:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 29 Oct 2000 16:20:47 -0800
Subject: [Python-bugs-list] [Bug #119709] A make error
Message-ID: <200010300020.QAA28810@sf-web3.vaspecialprojects.com>

Bug #119709, was updated on 2000-Oct-29 16:20
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: A make error

Details: I use:

Slackware96
Linux 2.0.0
gcc 2.7.2
glibc2
PC/i486

And I try to install Python-2.0.tar.gz package.
I use default Modules/Setup.

When run:

#./configure
#make

gcc tells me in Modules/selectmodule.c, begins from the 345 line,

POLLIN undeclared,...

Every POLL* name follows are all undeclared.

Which header file lost? poll.h? Or something wrong?

Thanks.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119709&group_id=5470


From noreply@sourceforge.net  Mon Oct 30 07:04:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 29 Oct 2000 23:04:01 -0800
Subject: [Python-bugs-list] [Bug #119729] copy/past error in Extending&Embedding
Message-ID: <200010300704.XAA19046@sf-web2.i.sourceforge.net>

Bug #119729, was updated on 2000-Oct-29 23:04
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: copy/past error in Extending&Embedding

Details: On page 9 of "extending and embedding" release 2.0,
I found a copy/past error for item 'es':

\item[\samp{es} (string, Unicode object or character buffer
compatible object) {[const char *encoding, char **buffer]}]
=> 2 parameters

But :
The variant [...] and the third one a pointer to an integer
(\var{*buffer_length}, the buffer length).



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119729&group_id=5470


From noreply@sourceforge.net  Mon Oct 30 13:03:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 30 Oct 2000 05:03:39 -0800
Subject: [Python-bugs-list] [Bug #117178] Documentation missing for __iadd__, __isub__, etc.
Message-ID: <200010301303.FAA06941@sf-web1.i.sourceforge.net>

Bug #117178, was updated on 2000-Oct-18 06:48
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Documentation missing for __iadd__, __isub__, etc.

Details: I understand that __iadd__, __isub__, etc. are the
functions you have to implement in a class for it to
support augmented assignment, but there is no documentation
for them under the 3.3 Special Method Names section. I
searched under the Doc directory for __isub__ and found
nothing at all.


Follow-Ups:

Date: 2000-Oct-30 05:03
By: twouters

Comment:
Sorry, my fault. I wasn't thorough enough in my attempts to write documentation and finding the right place to add it in the current layout. I've submitted a patch, #110216, to fix this.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117178&group_id=5470


From noreply@sourceforge.net  Mon Oct 30 14:05:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 30 Oct 2000 06:05:05 -0800
Subject: [Python-bugs-list] [Bug #119755] sys.getdefaultencoding undocumented
Message-ID: <200010301405.GAA07824@sf-web1.i.sourceforge.net>

Bug #119755, was updated on 2000-Oct-30 06:05
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: sys.getdefaultencoding undocumented

Details: I can't find any documentation of the getdefaultencoding function of module sys (though I can guess what it does...), nor any explanation about how to set/change the default encoding (or assertion that it cannot be changed).


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119755&group_id=5470


From noreply@sourceforge.net  Mon Oct 30 14:44:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 30 Oct 2000 06:44:00 -0800
Subject: [Python-bugs-list] [Bug #119755] sys.getdefaultencoding undocumented
Message-ID: <200010301444.GAA28404@sf-web2.i.sourceforge.net>

Bug #119755, was updated on 2000-Oct-30 06:05
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: sys.getdefaultencoding undocumented

Details: I can't find any documentation of the getdefaultencoding function of module sys (though I can guess what it does...), nor any explanation about how to set/change the default encoding (or assertion that it cannot be changed).


Follow-Ups:

Date: 2000-Oct-30 06:44
By: lemburg

Comment:
Since the default encoding is 'ascii' unless one edits site.py or
sitecustomize.py to use something else, there is not much to document
here ;-)

Anyway, documentation was already written and will show up with
the next documentation release, I guess.... Fred ?

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119755&group_id=5470


From noreply@sourceforge.net  Mon Oct 30 15:01:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 30 Oct 2000 07:01:31 -0800
Subject: [Python-bugs-list] [Bug #119707] urllib failure when return code not 200
Message-ID: <200010301501.HAA28838@sf-web2.i.sourceforge.net>

Bug #119707, was updated on 2000-Oct-29 16:11
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: urllib failure when return code not 200

Details: urllib fails sometimes.

A traceback follows but the problem is that, on line 286, fp is used as a parameter when it has a value of None. Not sure why; HTTP.getreply seems like it always returns a file. Not time right now to look further into it...

brian@sweetapp.com

Traceback (most recent call last):
  File "/usr/home/sweetapp/public_html/zonewatcher/Rating", line 83, in ?
    UpdatePlayerRatings( database, zonePlayer )
  File "/usr/home/sweetapp/public_html/zonewatcher/Rating", line 59, in UpdatePlayerRatings
    mainRatings = GetMainRatings( zonePlayer.GetZoneName( ), AOEIImainRating, AOEIIexpansionMainRating )
  File "/usr/home/sweetapp/public_html/zonewatcher/Rating", line 20, in GetMainRatings
    ratingsPage = GetRatingsPage( zoneID )
  File "/usr/home/sweetapp/public_html/zonewatcher/Rating", line 14, in GetRatingsPage
    url = urllib.urlopen( 'http://www.zone.com/Profile/RatingsPlayer.asp?PlayerID=' + zoneID )
  File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 61, in urlopen
    return _urlopener.open(url)
  File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 166, in open
    return getattr(self, name)(url)
  File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 286, in open_http
    return self.http_error(url, fp, errcode, errmsg, headers)
  File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 303, in http_error
    return self.http_error_default(url, fp, errcode, errmsg, headers)
  File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 518, in http_error_default
    return addinfourl(fp, headers, "http:" + url)
  File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 772, in __init__
    addbase.__init__(self, fp)
  File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 726, in __init__
    self.read = self.fp.read
AttributeError: 'None' object has no attribute 'read'

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119707&group_id=5470


From aleaxit@yahoo.com  Mon Oct 30 15:59:21 2000
From: aleaxit@yahoo.com (Alex Martelli)
Date: Mon, 30 Oct 2000 16:59:21 +0100
Subject: [Python-bugs-list] Re: [Bug #119755] sys.getdefaultencoding undocumented
References: <200010301444.GAA28404@sf-web2.i.sourceforge.net>
Message-ID: <053701c0428a$5e68cb20$102b2bc1@cadlab.it>

> Summary: sys.getdefaultencoding undocumented
>
> Details: I can't find any documentation of the getdefaultencoding function
of module sys (though I can guess what it does...), nor any explanation
about how to set/change the default encoding (or assertion that it cannot be
changed).
    [snip]
> Since the default encoding is 'ascii' unless one edits site.py or
> sitecustomize.py to use something else, there is not much to document

But what should be placed in site.py or sitecustomize.py to
use a different default-encoding rather than 'ascii'...?  I
can't see that documented anywhere, either (myopia...?)

> here ;-)
>
> Anyway, documentation was already written and will show up with
> the next documentation release, I guess.... Fred ?

I, personally, can wait, but there's some guy over in c.l.p
who's dying to get latin1 as the default, it seems.


Alex




From noreply@sourceforge.net  Mon Oct 30 16:28:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 30 Oct 2000 08:28:09 -0800
Subject: [Python-bugs-list] [Bug #119772] Interactive InterPreter+ Thread -> core dump at exit
Message-ID: <200010301628.IAA30939@sf-web2.i.sourceforge.net>

Bug #119772, was updated on 2000-Oct-30 08:28
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Interactive InterPreter+ Thread -> core dump at exit

Details: The following code executes a thread that prints a message every second while the main thread shows a python shell. 
It will run fine and if one leaves the interpreter with <Ctrl-D> python will exit cleanly.
However if one press <Ctrl-C> to kill the interactive interpreter and then exits python or press return a couple of time you get a core dump.

My platform is:
   HP-UX te35 B.11.00 A 9000/785 2015352223 two-user license

I am running Python 2.0
This is the code of the test program:

#!/usr/local/bin/python
import time, threading, whrandom, code, sys

class MyThread(threading.Thread):
    """ reports once per second
    """
    def run(self):
        while 1:
            print "alive ...."
            time.sleep(1)
        print self.getName(), "is DONE"


if __name__ == '__main__':
    threadList = []

    # Create MyThread() threads
    t = MyThread()
    t.setDaemon(1)
    t.start()

    # This is the main thread ... since there is only one other
    # thread and it is a 'daemon', killing the main thread kills
    # the whole thing.
    locals = sys.modules['__main__'].__dict__
    code.interact(locals)

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119772&group_id=5470


From mal@lemburg.com  Mon Oct 30 16:42:00 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon, 30 Oct 2000 17:42:00 +0100
Subject: [Python-bugs-list] Re: [Bug #119755] sys.getdefaultencoding
 undocumented
References: <200010301444.GAA28404@sf-web2.i.sourceforge.net> <053701c0428a$5e68cb20$102b2bc1@cadlab.it>
Message-ID: <39FDA4D8.5873BC96@lemburg.com>

Alex Martelli wrote:
> 
> > Summary: sys.getdefaultencoding undocumented
> >
> > Details: I can't find any documentation of the getdefaultencoding function
> of module sys (though I can guess what it does...), nor any explanation
> about how to set/change the default encoding (or assertion that it cannot be
> changed).
>     [snip]
> > Since the default encoding is 'ascii' unless one edits site.py or
> > sitecustomize.py to use something else, there is not much to document
> 
> But what should be placed in site.py or sitecustomize.py to
> use a different default-encoding rather than 'ascii'...?  I
> can't see that documented anywhere, either (myopia...?)

Here's what I wrote for the 2.0 docs (this will in some form
appear in the next docs release AFAIK):

"""
locale.py:

    getdefaultlocale(envvars=('LANGUAGE', 'LC_ALL', 'LC_CTYPE', 'LANG')) :
        Tries to determine the default locale settings and returns
        them as tuple (language code, encoding).
        
        According to POSIX, a program which has not called
        setlocale(LC_ALL, "") runs using the portable 'C' locale.
        Calling setlocale(LC_ALL, "") lets it use the default locale as
        defined by the LANG variable. Since we don't want to interfere
        with the current locale setting we thus emulate the behavior
        in the way described above.
        
        To maintain compatibility with other platforms, not only the
        LANG variable is tested, but a list of variables given as
        envvars parameter. The first found to be defined will be
        used. envvars defaults to the search path used in GNU gettext;
        it must always contain the variable name 'LANG'.
        
        Except for the code 'C', the language code corresponds to RFC
        1766.  code and encoding can be None in case the values cannot
        be determined.

    [new in 2.0b1]

    getlocale(category=0) :
        Returns the current setting for the given locale category as
        tuple (language code, encoding).
        
        category may be one of the LC_* value except LC_ALL. It
        defaults to LC_CTYPE.
        
        Except for the code 'C', the language code corresponds to RFC
        1766.  code and encoding can be None in case the values cannot
        be determined.

    [new in 2.0b1]

    normalize(localename) :
        Returns a normalized locale code for the given locale
        name.
        
        The returned locale code is formatted for use with
        setlocale().
        
        If normalization fails, the original name is returned
        unchanged.
        
        If the given encoding is not known, the function defaults to
        the default encoding for the locale code just like setlocale()
        does.

    [new in 2.0b1]

    resetlocale(category=6) :
        Sets the locale for category to the default setting.
        
        The default setting is determined by calling
        getdefaultlocale(). category defaults to LC_ALL.

    [new in 2.0b1]

    setlocale(category, locale=None) :
        Set the locale for the given category.  The locale can be
        a string, a locale tuple (language code, encoding), or None.
        
        Locale tuples are converted to strings the locale aliasing
        engine.  Locale strings are passed directly to the C lib.
        
        category may be given as one of the LC_* values.

    [changed in 2.0b1 to also accept a tuple as input to category]

These APIs can be put to use in the site.py file. It already
contains template code which sets the default encoding depending
on the current default locale.

New in 2.0b1 are also the related sys module APIs:

        getdefaultencoding() -> string
        
        Return the current default string encoding used by the Unicode 
        implementation.

        setdefaultencoding(encoding)

        Set the current default string encoding used by the Unicode
        implementation. Only available in site.py.
"""

> > here ;-)
> >
> > Anyway, documentation was already written and will show up with
> > the next documentation release, I guess.... Fred ?
> 
> I, personally, can wait, but there's some guy over in c.l.p
> who's dying to get latin1 as the default, it seems.

He will only have to uncomment the relevant code in site.py:

"""
# Set the string encoding used by the Unicode implementation.  The
# default is 'ascii', but if you're willing to experiment, you can
# change this.

encoding = "ascii" # Default value set by _PyUnicode_Init()

if 0:
    # Enable to support locale aware default string encodings.
    import locale
    loc = locale.getdefaultlocale()
    if loc[1]:
        encoding = loc[1]

if 0:
    # Enable to switch off string to Unicode coercion and implicit
    # Unicode to string conversion.
    encoding = "undefined"

if encoding != "ascii":
    sys.setdefaultencoding(encoding)
"""

Feel free to forward the docs to c.l.p. It's really not that
hard to use .setdefaultencoding() et al. :-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From noreply@sourceforge.net  Mon Oct 30 16:47:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 30 Oct 2000 08:47:40 -0800
Subject: [Python-bugs-list] [Bug #119772] Interactive InterPreter+ Thread -> core dump at exit
Message-ID: <200010301647.IAA10797@sf-web3.vaspecialprojects.com>

Bug #119772, was updated on 2000-Oct-30 08:28
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: Interactive InterPreter+ Thread -> core dump at exit

Details: The following code executes a thread that prints a message every second while the main thread shows a python shell. 
It will run fine and if one leaves the interpreter with <Ctrl-D> python will exit cleanly.
However if one press <Ctrl-C> to kill the interactive interpreter and then exits python or press return a couple of time you get a core dump.

My platform is:
   HP-UX te35 B.11.00 A 9000/785 2015352223 two-user license

I am running Python 2.0
This is the code of the test program:

#!/usr/local/bin/python
import time, threading, whrandom, code, sys

class MyThread(threading.Thread):
    """ reports once per second
    """
    def run(self):
        while 1:
            print "alive ...."
            time.sleep(1)
        print self.getName(), "is DONE"


if __name__ == '__main__':
    threadList = []

    # Create MyThread() threads
    t = MyThread()
    t.setDaemon(1)
    t.start()

    # This is the main thread ... since there is only one other
    # thread and it is a 'daemon', killing the main thread kills
    # the whole thing.
    locals = sys.modules['__main__'].__dict__
    code.interact(locals)

Follow-Ups:

Date: 2000-Oct-30 08:47
By: jhylton

Comment:
I can reproduce this on RH Linux, but not running Python under gdb.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119772&group_id=5470


From noreply@sourceforge.net  Mon Oct 30 17:15:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 30 Oct 2000 09:15:50 -0800
Subject: [Python-bugs-list] [Bug #117241] class.method(*([self]+args)) gave me a 'unbound method must be called with class instance 1st argument" error message.
Message-ID: <200010301715.JAA10948@sf-web1.i.sourceforge.net>

Bug #117241, was updated on 2000-Oct-18 15:28
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Closed
Resolution: None
Bug Group: None
Priority: 7
Summary: class.method(*([self]+args)) gave me a 'unbound method must be called with class instance 1st argument" error message.

Details: I have some 1.5 code like this:

apply(BaseMsgTemplate.__call__,[self]+args)

This works great and does what I want, calls the base class call method
with the current instance as self.  I thought I'd convert it to the
new calling syntax:

BaseMsgTemplate.__call__(*([self]+args))

But this gave me the error message:

'unbound method must be called with class instance 1st argument'

I *think* the * argument method is supposed to be functionally
equivalent to apply, so I think this is a bug. 


Follow-Ups:

Date: 2000-Oct-27 05:01
By: gvanrossum

Comment:
Definitely a bug! A simpler example would be Base.__init__(*(self, arg)).
-------------------------------------------------------

Date: 2000-Oct-30 09:15
By: jhylton

Comment:
Fixed in revision 2.213 of ceval.c

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117241&group_id=5470


From noreply@sourceforge.net  Mon Oct 30 17:48:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 30 Oct 2000 09:48:24 -0800
Subject: [Python-bugs-list] [Bug #110665] Compiling python on hpux 11.00 with threads (PR#360)
Message-ID: <200010301748.JAA11833@sf-web3.vaspecialprojects.com>

Bug #110665, was updated on 2000-Jul-31 14:12
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: Compiling python on hpux 11.00 with threads (PR#360)

Details: Jitterbug-Id: 360
Submitted-By: philipp.jocham@salomon.at
Date: Fri, 16 Jun 2000 08:47:06 -0400 (EDT)
Version: 1.5.2
OS: HP-UX 11.00


There are two missing details in the configure process to make this work
out of the box.

First: The function 
	pthread_create
isn't found in library libpthread.a but in libcma.a, because
pthread_create is just a macro in sys/pthread.h pointing to 
	__pthread_create_system

After patching ./configure directly and running 
	./configure --with-thread
(now detecting the correct library /usr/lib/libpthread.a) I also
added -lcl to Modules/Makefile at
	LIBS=           -lnet -lnsl -ldld  -lpthread -lcl

otherwise importing of modules with threads didn't work 
(in this case oci_.sl from DCOracle). 

I'm not sure about the correct syntax or wether it's the correct
place and method, but I would suggest a solution like the following
code snippet.

[...]
AC_MSG_CHECKING(for --with-thread)
[...]
AC_DEFINE(_POSIX_THREADS)
LIBS="$LIBS -lpthread -lcl"
LIBOBJS="$LIBOBJS thread.o"], [
AC_CHECK_LIB(pthread, __pthread_create_system, [AC_DEFINE(WITH_THREAD)
[...]

I hope this helps to make installation process smoother.
Fell free to contact me, if there are further questions.
Philipp
-- 
I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.



====================================================================
Audit trail:
Tue Jul 11 08:26:01 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-22 02:56
By: gvanrossum

Comment:
Taking this because I'm considering to redesign the thread configuration section in configure.in anyway -- there's a similar bug report for Alpha OSF1.
-------------------------------------------------------

Date: 2000-Sep-25 06:10
By: gvanrossum

Comment:
I'm hoping that this was fixed by recent changes. Sent an email to the original submittor to verify.
-------------------------------------------------------

Date: 2000-Oct-06 10:40
By: gvanrossum

Comment:
I have two reports from people for whom configure, build and run  with threads now works on HP-UX 10 and 11. I'm not sure what to do about this report... What's different on Philipp's system???
-------------------------------------------------------

Date: 2000-Oct-10 04:55
By: edg

Comment:
I can confirm that the bug still exists in 2.0c1.
It works fine on HP-UX 10.20 (which only has libcma),
but not on HP-UX 11 (which both has libcma and libpthread).
The pthread_create function is not defined as a macro though,
but as a static function:

static int pthread_create(pthread_t *tid, const pthread_attr_t *attr, void *(*start_routine)(void *), void *arg)
   { return(__pthread_create_system(tid, attr, start_routine, arg)); }

I don't see an easy way to work around this.
I'm not a configure expert, but perhaps the script should
first check whether this code compiles and links:

#include <pthread.h>
int main()
{
   pthread_create(0,0,0,0);
   return 0;
}

and if not, fall back on the other tests ?

-------------------------------------------------------

Date: 2000-Oct-13 07:45
By: gvanrossum

Comment:
OK, so the correct thing to do seems to be to somehow add #include <pthread.h> to the tests for thread libraries. I'm afraid I won't be able to fix this in 2.0final, but I'll think about fixing it in 2.1 (or 2.0.1, whichever comes first :-).
-------------------------------------------------------

Date: 2000-Oct-30 09:48
By: gvanrossum

Comment:
Philipp submitted a patch to configure.in that fixes the problem for him and doesn't look like it would break things for others.  configure.in, CVS revision 1.175.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110665&group_id=5470


From noreply@sourceforge.net  Mon Oct 30 18:43:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 30 Oct 2000 10:43:45 -0800
Subject: [Python-bugs-list] [Bug #112317] os.rename transparent handling of cross-filesystem issues
Message-ID: <200010301843.KAA12908@sf-web3.vaspecialprojects.com>

Bug #112317, was updated on 2000-Aug-19 10:09
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 3
Summary: os.rename transparent handling of cross-filesystem issues

Details: On some systems (specifically, Linux), the rename system call will throw
an EXDEV error if rename is used across filesystems.  It would be convenient for the user if os.rename were extended to handle this transparently (like most mv commands do).

The benefits of this. . .getting rid of code like the following:

try:
    os.rename('ff','/tmp/ff')
except:
    open('/tmp/ff','w').write(open('ff','r').read())
    os.unlink('ff')

Actually, the real benefit is that code (written by morons like myself) using os.rename will continue to work even after the administrator moves the target directory to another filesystem.

I took a quick look at posixmodule.c.  A quick hack changes posix_2str's
signature to the following:

PyObject *args
char *format
int (*func)(const char*, const char *)
int (*special_handler)(const char *, const char *)

and the inner function to:

if (res != 0)
    if ((! special_handler) || (*special_handler)(path1,path2))
         return posix_error()

Of course, then a smart copy routine (includes an unlink step).  The most unclear thing at this point is what to do with the errno.  Would a failure in
the errorhandler report the original errno or its own errno???

Personally, a more general solution would allow the user (python-level) to optionally pass in *their own* error handling function/method.




Follow-Ups:

Date: 2000-Aug-25 07:44
By: jhylton

Comment:
revisit this after 2.0

-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-15 13:01
By: fdrake

Comment:
Moved to PEP 42 as a feature request for a post-2.0 version of Python.
-------------------------------------------------------

Date: 2000-Oct-30 10:43
By: gvanrossum

Comment:
Copying files (and directories) properly is a very platform specific task -- there are lots of pitfalls that the copying code has to watch out for, e.g. copying files with "holes", properly copying all metadata, copying special files... I think that the os.rename() call is not the proper place to implement all this. But it's a useful feature nevertheless, and could perhaps be accommodated by a higher level function in the shutil module (which has the basic copying primitives).

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112317&group_id=5470


From noreply@sourceforge.net  Mon Oct 30 21:31:41 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 30 Oct 2000 13:31:41 -0800
Subject: [Python-bugs-list] [Bug #119556] Python 2.0 httplib doesn't like ICY status lines
Message-ID: <200010302131.NAA16055@sf-web1.i.sourceforge.net>

Bug #119556, was updated on 2000-Oct-27 10:24
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Python 2.0 httplib doesn't like ICY status lines

Details: 
I have a Python script that captures streaming audio on the Internet.
The homepage is at http://beam-back.sourceforge.net  It works fine
with Python 1.5.2 and Python 1.6.  One of my users noticed the script
is broken under Python 2.0.

In the getreply function of httplib.py in Python 1.5.2, even if 
ver[:5] != 'HTTP/', the connection is left open.  I depend on this 
behavior because streaming audio links found at 
http://www.shoutcast.com/ return a status line like this:

ICY 200 OK

Under Python 1.6 and 1.5.2, I can happily go on and use getfile() to
obtain the data on the connection.

In the getreply function of httplib.py in Python 2.0, the BadStatusLine
exception (raised by ver[:5] != 'HTTP/' in begin) causes the connection
to be closed.

I'm writing to find out how I could go about discussing a possible
return to the previous behavior in future releases of Python.  If
that is not feasible, I would be appreciative of any advice on how
I should go about porting the script to Python 2.0.

Regards,
--Kal




Follow-Ups:

Date: 2000-Oct-28 18:12
By: loewis

Comment:
The response of the server clearly violates RFC 2616, section 6.1. Where is the documentation for the protocol that this server implements? If you need to support this protocol (which clearly is not HTTP), you need to implement your own response class (perhaps inheriting from HTTPResponse if possible).
-------------------------------------------------------

Date: 2000-Oct-30 13:31
By: kal

Comment:
As far as I know, there is no published doc for the protocol.
I'm working from the xmms source code and just trial and error.
You're right.  I should write a new response class for supporting 
ICY instead of latching onto httplib.

Thanks.



-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119556&group_id=5470


From noreply@sourceforge.net  Mon Oct 30 21:35:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 30 Oct 2000 13:35:20 -0800
Subject: [Python-bugs-list] [Bug #119806] cgi.py uses too much memory on large file uploads
Message-ID: <200010302135.NAA16133@sf-web1.i.sourceforge.net>

Bug #119806, was updated on 2000-Oct-30 13:35
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: cgi.py uses too much memory on large file uploads

Details: When uploading files through a web form and parsing the form using cgi.py - the entire fil(s are read into memory, which is intolerable with very large (I'm thinking multiple 10's of megabyte) files.

The culprit seems to be in the FieldStorage class, basically the three calls to:

   self.lines.append(line)

in the read_lines_to_eof, read_lines_to_outerboundary, and skip_lines methods.  

Commenting those calls out seems to fix the problem, as long as you don't care to access the 'lines' member of the FieldStorage instance.  A real fix would possibly be to add a "keep_lines=1" keyword parameter to FieldStorage.__init__(), save that value in the instance, and check it before accumulating form lines.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119806&group_id=5470


From noreply@sourceforge.net  Tue Oct 31 01:12:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 30 Oct 2000 17:12:20 -0800
Subject: [Python-bugs-list] [Bug #119822] urllib doesn't like unicode
Message-ID: <200010310112.RAA19462@sf-web1.i.sourceforge.net>

Bug #119822, was updated on 2000-Oct-30 17:12
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: urllib doesn't like unicode

Details: 
getting a file via urllib.urlopen(u"http://foobar/blahblah")
produces undesirable results.

Something like:

  File "/usr/local/lib/python2.0/urllib.py", line 61, in urlopen
    return _urlopener.open(url)
  File "/usr/local/lib/python2.0/urllib.py", line 166, in open
    return getattr(self, name)(url)
  File "/usr/local/lib/python2.0/urllib.py", line 248, in open_http
    host, selector = url
ValueError: unpack sequence of wrong size


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119822&group_id=5470


From noreply@sourceforge.net  Tue Oct 31 02:25:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 30 Oct 2000 18:25:21 -0800
Subject: [Python-bugs-list] [Bug #119645] distutils.sysconfig.LINKFORSHARED is undefined
Message-ID: <200010310225.SAA20687@sf-web3.vaspecialprojects.com>

Bug #119645, was updated on 2000-Oct-28 17:24
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: distutils.sysconfig.LINKFORSHARED is undefined

Details: The current documentation (in http://www.python.org/doc/current/ext/link-reqs.html) says to check the value of distutils.sysconfig.LINKFORSHARED in order to get compiler options for embedding Python.  However, this value is undefined in Python 2.0, installed on a RedHat Linux system from the RPMs on www.python.org:

>>> import distutils.sysconfig
>>> distutils.sysconfig.LINKFORSHARED 
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: LINKFORSHARED


Follow-Ups:

Date: 2000-Oct-30 18:25
By: gward

Comment:
This is a documentation bug, but I plead partly guilty (since I changed the interface of the distutils.sysconfig module without thinking to see if it had been documented anywhere, implicitly or not).  Oops.

This patch fixes the doc bug:

--- ext.tex     2000/10/26 17:19:58     1.87
+++ ext.tex     2000/10/31 02:22:58
@@ -2138,7 +2138,7 @@
 
 \begin{verbatim}
 >>> import distutils.sysconfig
->>> distutils.sysconfig.LINKFORSHARED 
+>>> distutils.sysconfig.get_config_var("LINKFORSHARED")
 '-Xlinker -export-dynamic'
 \end{verbatim}
 \refstmodindex{distutils.sysconfig}

Fred, I can check this in if you want...
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119645&group_id=5470


From noreply@sourceforge.net  Tue Oct 31 09:47:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 31 Oct 2000 01:47:16 -0800
Subject: [Python-bugs-list] [Bug #119851] inline C++ keyword in config.h
Message-ID: <200010310947.BAA26050@sf-web3.vaspecialprojects.com>

Bug #119851, was updated on 2000-Oct-31 01:47
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: inline C++ keyword in config.h

Details: Hi,

I have built Python 2.0 on Solaris 7 using the Sun C compiler.

Now I see the following piece of code in config.h:

/* Define as __inline if that's what the C compiler calls it.  */
#define inline

This is a problem when writing Python modules in C++
and should probably be removed. What was the intent
in the first place?

Thanks,
Dimitri


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119851&group_id=5470


From noreply@sourceforge.net  Tue Oct 31 11:50:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 31 Oct 2000 03:50:18 -0800
Subject: [Python-bugs-list] [Bug #119860] Exception "TypeError: not enough arguments" without details
Message-ID: <200010311150.DAA23358@sf-web2.i.sourceforge.net>

Bug #119860, was updated on 2000-Oct-31 03:50
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 5
Summary: Exception "TypeError: not enough arguments" without details

Details: It is possible to create a TypeError without a stack trace thus creating an exception without any hints what is wrong. You will need a third party module (I'll use PyGTK) to reproduce this:

------- test.py ---------------------
from gtk import *

def test (x, y):
    print x, y
    mainquit ()

timeout_add (1.0, test)

mainloop ()
-------- test.py ----------

Run this and you will get this message:

--- output ------------------------
TypeError: not enough parameters; expected 2, got 0
--- output ------------------------

The problem is of course that when Python has to evaluate the code, there is no "calling" instance (and thus Python has no idea what to print). As I see it, there are only two possible solutions:

- Users who want to use this API (to run Python code) must submit a "position" object (which will make python print "test.py:7 timeout_add..." when an exception happens in the C code which tries to call test()). For this, there must be an API to query the current position in a source script (should already be there because the code which prints stack traces must do something very similar).
- The code which prints the exception is in Python/ceval.c in ceval2(). The first object passed it a CodeObject. If we would pass the function object instead, we could at least print the name of the function. But ceval2() is also used in other circumstances, therefore, this might be impossible.

A quick solution and/or workaround would be most welcome !

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119860&group_id=5470


From noreply@sourceforge.net  Tue Oct 31 12:22:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 31 Oct 2000 04:22:28 -0800
Subject: [Python-bugs-list] [Bug #119862] Memory leak in python 2.0 and below
Message-ID: <200010311222.EAA28010@sf-web3.vaspecialprojects.com>

Bug #119862, was updated on 2000-Oct-31 04:22
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Memory leak in python 2.0 and below

Details: The reference count of the item returned by the PyMapping_GetItemString function in call inside the function vgetargskeywords is not decremented. This can result in a memory leak.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119862&group_id=5470


From noreply@sourceforge.net  Tue Oct 31 16:35:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 31 Oct 2000 08:35:53 -0800
Subject: [Python-bugs-list] [Bug #119883] smtplib.py can leak file descriptors
Message-ID: <200010311635.IAA30910@sf-web1.i.sourceforge.net>

Bug #119883, was updated on 2000-Oct-31 08:35
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: smtplib.py can leak file descriptors

Details: If the socket.connect() fails in SMTP.connect() in smtplib.py, file descriptors are leaked.  Patch #102185 fixes this.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119883&group_id=5470


From noreply@sourceforge.net  Tue Oct 31 19:10:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 31 Oct 2000 11:10:51 -0800
Subject: [Python-bugs-list] [Bug #119558] bsddb module doesn't check return value of malloc()
Message-ID: <200010311910.LAA00586@sf-web1.i.sourceforge.net>

Bug #119558, was updated on 2000-Oct-27 10:46
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 4
Summary: bsddb module doesn't check return value of malloc()

Details: The bsddbmodule often uses code like this:

if (krec.size > sizeof(buf)) data = malloc(krec.size);
else data = buf;
memcpy(data,krec.data,krec.size);

If malloc() returns NULL, this will do a memcpy() using
NULL as the dest point.


Follow-Ups:

Date: 2000-Oct-29 09:55
By: jhylton

Comment:
Do you want to fix it?  Or should we wait for your new module?

-------------------------------------------------------

Date: 2000-Oct-31 11:10
By: akuchling

Comment:
I'll take care of it, though I'm not sure when I'll get around to it.  It'll make a good evening's project.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119558&group_id=5470


From noreply@sourceforge.net  Tue Oct 31 21:38:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 31 Oct 2000 13:38:56 -0800
Subject: [Python-bugs-list] [Bug #119960] Encoding bugs.
Message-ID: <200010312138.NAA04084@sf-web3.vaspecialprojects.com>

Bug #119960, was updated on 2000-Oct-31 13:38
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Encoding bugs.

Details: Win98, Python2.0final.

1. I can't write cyrillic letters in IDLE editor.

I tried to figure, what's happened and found that
Tcl has command 'encoding'. I typed in IDLE shell:

>>> from Tkinter import *
>>> root = Tk()
>>> root.tk.call("encoding", "names")
'utf-8 identity unicode'
>>> root.tk.call("encoding", "system")
'identity'

But Tcl had numerous encodings in 'tcl\tcl8.3\encodings'
including 'cp1251'!

Then I installed Tk separately and removed tcl83.dll
and tk83.dll from DLLs:

>>> from Tkinter import *
>>> root = Tk()
>>> root.tk.call("encoding", "names")
'cp860 cp861 [.........] cp857 unicode'
>>> root.tk.call("encoding", "system")
'cp1251'

So, when tcl/tk dlls in Python\DLLs directory,
TCL can't load all it's encodings.

But this is not the end.

I typed in IDLE shell:

>>> print "hello <in russian>" # all chars looks correctly.
and got:
Exception in Tkinter callback
Traceback (most recent call last):
  File "c:\python20\lib\lib-tk\Tkinter.py", line 1287, in __call__
    return apply(self.func, args)
  File "C:\PYTHON20\Tools\idle\PyShell.py", line 579, in enter_callback
    self.runit()
  File "C:\PYTHON20\Tools\idle\PyShell.py", line 598, in runit
    more = self.interp.runsource(line)
  File "C:\PYTHON20\Tools\idle\PyShell.py", line 183, in runsource
    return InteractiveInterpreter.runsource(self, source, filename)
  File "c:\python20\lib\code.py", line 61, in runsource
    code = compile_command(source, filename, symbol)
  File "c:\python20\lib\codeop.py", line 61, in compile_command
    code = compile(source, filename, symbol)
UnicodeError: ASCII encoding error: ordinal not in range(128)
print "[the same characters]"
Then, when I pressed Enter again, i got the same
error message. I stopped this by pressing C-Break.

[1/2 hour later]
I fix this by editing site.py:
if 1: # was: if 0
  # Enable to support locale aware default string encodings.

I typed again:
>>> print "hello <in russian>"
and got:
<some strange letters>
>>> print unicode("hello <in russian>")
<some strange letters>

[2 hours later]
Looking sources of _tkinter.c:

static Tcl_Obj* AsObj(PyObject *value)
{
    if type(value) is StringType:
        return Tcl_NewStringObj(value)
    elif type(value) is UnicodeType:
        ...
...
}

But I read in
<http://dev.scriptics.com/doc/howto/i18n.html>
that all Tcl functions require all strings to
be passed in UTF-8. So, this code must look like:

    if type(value) is StringType:
        if TCL_Version >= 8.1:
             return Tcl_NewStringObj(<value converted
           to UTF-8 string using sys.getdefaultencoding()>)
        else:
             return Tcl_NewStringObj(value)

And when I typed:
>>> print unicode("hello <in russian>").encode('utf-8')
i got:
hello <in russian>

This is the end.

P.S. Sorry for my bad english, but I really want to
use IDLE and Tkinter in our school, so I can't wait
for somebody other writing bug report.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119960&group_id=5470


From noreply@sourceforge.net  Tue Oct 31 22:18:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 31 Oct 2000 14:18:45 -0800
Subject: [Python-bugs-list] [Bug #120081] PyDict_Update() missing from C API
Message-ID: <200010312218.OAA04474@sf-web2.i.sourceforge.net>

Bug #120081, was updated on 2000-Oct-31 14:18
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 4
Summary: PyDict_Update() missing from C API

Details: The C API should include a PyDict_Update() function which takes a dictionary as its first argument, and an arbitrary mapping as its second.  Similarly there should probably be a PyMapping_Update() in the abstract API (and several other dictionary methods in there too).

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=120081&group_id=5470


From noreply@sourceforge.net  Tue Oct 31 22:20:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 31 Oct 2000 14:20:18 -0800
Subject: [Python-bugs-list] [Bug #120082] making vars() more useful
Message-ID: <200010312220.OAA04584@sf-web2.i.sourceforge.net>

Bug #120082, was updated on 2000-Oct-31 14:20
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 4
Summary: making vars() more useful

Details: It might make sense to change built-in vars() with no arguments.  Instead of being equivalent to locals(), it should be equivalent to the following Python code:

d = globals().copy()
d.update(locals())


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=120082&group_id=5470