From noreply@sourceforge.net  Sat Jun  1 01:06:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 May 2002 17:06:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-561858 ] Assertion with very long lists
Message-ID: <E17DwPb-0006Eq-00@usw-sf-web1.sourceforge.net>

Bugs item #561858, was opened at 2002-05-29 06:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Jerome Alet (jalet)
Assigned to: Nobody/Anonymous (nobody)
Summary: Assertion with very long lists

Initial Comment:
I've tried to import a module which only define a list
of 170000 elements (a word list) which defines an
element per line, so the module also has 170000 lines
in it. Here's the error :

--- CUT ---
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import dictionnaire
python: ../Python/ceval.c:695: eval_code2: Assertion
`(stack_pointer - f->f_valuestack) <= f->f_stacksize'
failed.
Abandon
--- CUT ---

this seems to be the same problem as bug id 210647 but
there's no segfault.

the module is attached to this bug report.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 20:06

Message:
Logged In: YES 
user_id=33168

I found at least part of the problem, perhaps everything.
The co_stacksize > 32767 and only a short value is marshalled
to the .pyc.

See Python/marshal.c line 246.

Not sure how to fix yet.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 18:32

Message:
Logged In: YES 
user_id=33168

I think there are several problems here.
I was able to narrow down at least one problem to a long list.
It doesn't seem to have anything to do w/backslashes.

There seems to be an interaction with importing the module.
If the long list is in __main__, the problem does not occur.
The problem only occurs when the list is in an imported module
and only after importing it the second time (after the .pyc
is created).

If a list has 32768+ items there seems to be a memory problem.
There is an exception, then a crash.  Here's the exception:

TypeError: unsupported operand type(s) for &: 'str' and 'str'

Here's a stack trace against CVS version:

#0  chunk_free (ar_ptr=0x401b1620, p=0x8156a10) at malloc.c:3180
#1  0x400fdbf4 in __libc_free (mem=0x8156a18) at malloc.c:3154
#2  0x0805c0db in list_dealloc (op=0x401c4eac) at
Objects/listobject.c:214
#3  0x080c7618 in PyDict_SetItem (op=0x401bd79c,
key=0x401c4ec0, 
    value=0x80e185c) at Objects/dictobject.c:373
#4  0x080c93f9 in PyDict_SetItemString (v=0x401bd79c,
key=0x80d9070 "path", 
    item=0x80e185c) at Objects/dictobject.c:1895
#5  0x08099ad8 in PyImport_Cleanup () at Python/import.c:286
#6  0x080a266d in Py_Finalize () at Python/pythonrun.c:228
#7  0x08053766 in Py_Main (argc=2, argv=0xbffff904) at
Modules/main.c:379


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

Comment By: Jerome Alet (jalet)
Date: 2002-05-29 08:42

Message:
Logged In: YES 
user_id=97214

I've done more tests, the bug only occurs if every line has
a backslash at its end :

liste = [ \
            "item0", \
            "item1", \
            # ... many many lines
            "itemN" ]

and it works if I remove the \ from each end of line.

hth.

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

Comment By: Jerome Alet (jalet)
Date: 2002-05-29 06:14

Message:
Logged In: YES 
user_id=97214

module too long to be attached. ask it by email at
alet@librelogiciel.com if needed.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470



From noreply@sourceforge.net  Sat Jun  1 01:17:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 May 2002 17:17:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-561858 ] Assertion with very long lists
Message-ID: <E17DwaI-0002pS-00@usw-sf-web3.sourceforge.net>

Bugs item #561858, was opened at 2002-05-29 06:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Jerome Alet (jalet)
Assigned to: Nobody/Anonymous (nobody)
Summary: Assertion with very long lists

Initial Comment:
I've tried to import a module which only define a list
of 170000 elements (a word list) which defines an
element per line, so the module also has 170000 lines
in it. Here's the error :

--- CUT ---
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import dictionnaire
python: ../Python/ceval.c:695: eval_code2: Assertion
`(stack_pointer - f->f_valuestack) <= f->f_stacksize'
failed.
Abandon
--- CUT ---

this seems to be the same problem as bug id 210647 but
there's no segfault.

the module is attached to this bug report.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 20:17

Message:
Logged In: YES 
user_id=33168

Got a fix.  Patch attached.  
It will probably have to be changed,
since I don't remember what else needs to be
done when the MAGIC is changed.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 20:06

Message:
Logged In: YES 
user_id=33168

I found at least part of the problem, perhaps everything.
The co_stacksize > 32767 and only a short value is marshalled
to the .pyc.

See Python/marshal.c line 246.

Not sure how to fix yet.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 18:32

Message:
Logged In: YES 
user_id=33168

I think there are several problems here.
I was able to narrow down at least one problem to a long list.
It doesn't seem to have anything to do w/backslashes.

There seems to be an interaction with importing the module.
If the long list is in __main__, the problem does not occur.
The problem only occurs when the list is in an imported module
and only after importing it the second time (after the .pyc
is created).

If a list has 32768+ items there seems to be a memory problem.
There is an exception, then a crash.  Here's the exception:

TypeError: unsupported operand type(s) for &: 'str' and 'str'

Here's a stack trace against CVS version:

#0  chunk_free (ar_ptr=0x401b1620, p=0x8156a10) at malloc.c:3180
#1  0x400fdbf4 in __libc_free (mem=0x8156a18) at malloc.c:3154
#2  0x0805c0db in list_dealloc (op=0x401c4eac) at
Objects/listobject.c:214
#3  0x080c7618 in PyDict_SetItem (op=0x401bd79c,
key=0x401c4ec0, 
    value=0x80e185c) at Objects/dictobject.c:373
#4  0x080c93f9 in PyDict_SetItemString (v=0x401bd79c,
key=0x80d9070 "path", 
    item=0x80e185c) at Objects/dictobject.c:1895
#5  0x08099ad8 in PyImport_Cleanup () at Python/import.c:286
#6  0x080a266d in Py_Finalize () at Python/pythonrun.c:228
#7  0x08053766 in Py_Main (argc=2, argv=0xbffff904) at
Modules/main.c:379


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

Comment By: Jerome Alet (jalet)
Date: 2002-05-29 08:42

Message:
Logged In: YES 
user_id=97214

I've done more tests, the bug only occurs if every line has
a backslash at its end :

liste = [ \
            "item0", \
            "item1", \
            # ... many many lines
            "itemN" ]

and it works if I remove the \ from each end of line.

hth.

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

Comment By: Jerome Alet (jalet)
Date: 2002-05-29 06:14

Message:
Logged In: YES 
user_id=97214

module too long to be attached. ask it by email at
alet@librelogiciel.com if needed.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470



From noreply@sourceforge.net  Sat Jun  1 01:27:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 May 2002 17:27:50 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-563141 ] fileinput/gzip modules should play well
Message-ID: <E17DwkI-0006SY-00@usw-sf-web1.sourceforge.net>

Feature Requests item #563141, was opened at 2002-05-31 17:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=563141&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg White (groggygreggy)
Assigned to: Nobody/Anonymous (nobody)
Summary: fileinput/gzip modules should play well

Initial Comment:
It seems to be nearly impossible to use the fileinput 
module to read gzip files, even though gzip support is 
available in the gzip module.

As a first step, it would be nice if the fileinput.FileInput 
class provided an overridable method that let outsiders 
glue the gzip module in place.

It would also be nice if there was a way to make fileinput 
just automatically support gzip files (if, for instance, it 
saw a .gz extension).

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=563141&group_id=5470



From noreply@sourceforge.net  Sat Jun  1 02:23:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 May 2002 18:23:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-563148 ] built-in LIST operation has bug
Message-ID: <E17DxcG-0003TG-00@usw-sf-web3.sourceforge.net>

Bugs item #563148, was opened at 2002-06-01 01:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563148&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Tom Stanik (mytost)
Assigned to: Nobody/Anonymous (nobody)
Summary: built-in LIST operation has bug

Initial Comment:
example, to create a list of lists one can enter:

>>> d=[[0] * 4] * 5
>>> print d
[[0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 
0]]

if you want to change the first element in the first list:

>>> d[0][0]=1
>>> print d
[[1, 0, 0, 0], [1, 0, 0, 0], [1, 0, 0, 0], [1, 0, 0, 0], [1, 0, 0, 
0]] ***** INCORECT *****, all the first element changed

Alternatively, if you build the list manually:

>>> d=[0,0,0,0,0]
>>> d[0]=[0,0,0,0]
>>> d[1]=[0,0,0,0]
>>> d[2]=[0,0,0,0]
>>> d[3]=[0,0,0,0]
>>> print d
[[0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 
0]] 

changing the first element in the first list yields the 
correct result

>>> d[0][0]=1
>>> print d
[[1, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 
0]] ***** CORRECT *****

The same list depending on hows it built yields a 
different behavior

my version of python:

$ python -v
# /usr/local/lib/python2.2/site.pyc 
matches /usr/local/lib/python2.2/site.py
import site # precompiled 
from /usr/local/lib/python2.2/site.pyc
# /usr/local/lib/python2.2/os.pyc 
matches /usr/local/lib/python2.2/os.py
import os # precompiled 
from /usr/local/lib/python2.2/os.pyc
import posix # builtin
# /usr/local/lib/python2.2/posixpath.pyc 
matches /usr/local/lib/python2.2/posixpath.py
import posixpath # precompiled 
from /usr/local/lib/python2.2/posixpath.pyc
# /usr/local/lib/python2.2/stat.pyc 
matches /usr/local/lib/python2.2/stat.py
import stat # precompiled 
from /usr/local/lib/python2.2/stat.pyc
# /usr/local/lib/python2.2/UserDict.pyc 
matches /usr/local/lib/python2.2/UserDict.py
import UserDict # precompiled 
from /usr/local/lib/python2.2/UserDict.pyc
# /usr/local/lib/python2.2/copy_reg.pyc 
matches /usr/local/lib/python2.2/copy_reg.py
import copy_reg # precompiled 
from /usr/local/lib/python2.2/copy_reg.pyc
# /usr/local/lib/python2.2/types.pyc 
matches /usr/local/lib/python2.2/types.py
import types # precompiled 
from /usr/local/lib/python2.2/types.pyc
# /usr/local/lib/python2.2/__future__.pyc 
matches /usr/local/lib/python2.2/__future__.py
import __future__ # precompiled 
from /usr/local/lib/python2.2/__future__.pyc
Python 2.2.1 (#1, May 10 2002, 23:36:51) 
[GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more 
information.
dlopen("/usr/local/lib/python2.2/lib-dynload/readline.so", 
2);
import readline # dynamically loaded 
from /usr/local/lib/python2.2/lib-dynload/readline.so
>>> 




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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563148&group_id=5470



From noreply@sourceforge.net  Sat Jun  1 03:04:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 May 2002 19:04:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-561858 ] Assertion with very long lists
Message-ID: <E17DyGF-0001g0-00@usw-sf-web4.sourceforge.net>

Bugs item #561858, was opened at 2002-05-29 06:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Jerome Alet (jalet)
Assigned to: Nobody/Anonymous (nobody)
Summary: Assertion with very long lists

Initial Comment:
I've tried to import a module which only define a list
of 170000 elements (a word list) which defines an
element per line, so the module also has 170000 lines
in it. Here's the error :

--- CUT ---
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import dictionnaire
python: ../Python/ceval.c:695: eval_code2: Assertion
`(stack_pointer - f->f_valuestack) <= f->f_stacksize'
failed.
Abandon
--- CUT ---

this seems to be the same problem as bug id 210647 but
there's no segfault.

the module is attached to this bug report.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 22:04

Message:
Logged In: YES 
user_id=33168

Final patch attached.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 20:17

Message:
Logged In: YES 
user_id=33168

Got a fix.  Patch attached.  
It will probably have to be changed,
since I don't remember what else needs to be
done when the MAGIC is changed.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 20:06

Message:
Logged In: YES 
user_id=33168

I found at least part of the problem, perhaps everything.
The co_stacksize > 32767 and only a short value is marshalled
to the .pyc.

See Python/marshal.c line 246.

Not sure how to fix yet.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 18:32

Message:
Logged In: YES 
user_id=33168

I think there are several problems here.
I was able to narrow down at least one problem to a long list.
It doesn't seem to have anything to do w/backslashes.

There seems to be an interaction with importing the module.
If the long list is in __main__, the problem does not occur.
The problem only occurs when the list is in an imported module
and only after importing it the second time (after the .pyc
is created).

If a list has 32768+ items there seems to be a memory problem.
There is an exception, then a crash.  Here's the exception:

TypeError: unsupported operand type(s) for &: 'str' and 'str'

Here's a stack trace against CVS version:

#0  chunk_free (ar_ptr=0x401b1620, p=0x8156a10) at malloc.c:3180
#1  0x400fdbf4 in __libc_free (mem=0x8156a18) at malloc.c:3154
#2  0x0805c0db in list_dealloc (op=0x401c4eac) at
Objects/listobject.c:214
#3  0x080c7618 in PyDict_SetItem (op=0x401bd79c,
key=0x401c4ec0, 
    value=0x80e185c) at Objects/dictobject.c:373
#4  0x080c93f9 in PyDict_SetItemString (v=0x401bd79c,
key=0x80d9070 "path", 
    item=0x80e185c) at Objects/dictobject.c:1895
#5  0x08099ad8 in PyImport_Cleanup () at Python/import.c:286
#6  0x080a266d in Py_Finalize () at Python/pythonrun.c:228
#7  0x08053766 in Py_Main (argc=2, argv=0xbffff904) at
Modules/main.c:379


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

Comment By: Jerome Alet (jalet)
Date: 2002-05-29 08:42

Message:
Logged In: YES 
user_id=97214

I've done more tests, the bug only occurs if every line has
a backslash at its end :

liste = [ \
            "item0", \
            "item1", \
            # ... many many lines
            "itemN" ]

and it works if I remove the \ from each end of line.

hth.

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

Comment By: Jerome Alet (jalet)
Date: 2002-05-29 06:14

Message:
Logged In: YES 
user_id=97214

module too long to be attached. ask it by email at
alet@librelogiciel.com if needed.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470



From noreply@sourceforge.net  Sat Jun  1 06:30:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 May 2002 22:30:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-563060 ] Module can be used as a base class
Message-ID: <E17E1TO-0000rO-00@usw-sf-web1.sourceforge.net>

Bugs item #563060, was opened at 2002-05-31 15:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563060&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Module can be used as a base class

Initial Comment:
>From python-dev:

> But this is not what I would expect:
> 
>       >>> import string
>       >>> class newstr(string): pass
>       ... 
>       # i would have expected this to raise a TypeError
>       >>> x = newstr()
>       Traceback (most recent call last):
>         File "<stdin>", line 1, in ?
>       TypeError: 'module' object is not callable
> 
> Perhaps this error should be handled when the class
is constructed
> rather than when instantiating an object?

Guido says "the bug is that you can use any module as a
base class"

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

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-06-01 01:30

Message:
Logged In: YES 
user_id=12800

Note that this bug exists in Python 2.2.1 also.

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

Comment By: Phillip J. Eby (pje)
Date: 2002-05-31 16:27

Message:
Logged In: YES 
user_id=56214

More specifically, ModuleType's constructor accepts and
ignores a (name,bases,dict) call signature.  Other objects
will fail at class construction time like this:

>>> class d({}): pass

Traceback (most recent call last):
  File "<pyshell#1>", line 1, in ?
    class d({}): pass
TypeError: dict() takes at most 1 argument (3 given)
>>> class n(1): pass

Traceback (most recent call last):
  File "<pyshell#3>", line 1, in ?
    class n(1): pass
TypeError: int() takes at most 2 arguments (3 given)
>>> class s("s"): pass

Traceback (most recent call last):
  File "<pyshell#5>", line 1, in ?
    class s("s"): pass
TypeError: str() takes at most 1 argument (3 given)
>>> 

Since the module constructor doesn't actually need any
arguments, it should complain the same way the above items do.

Interestingly, while type(module) doesn't complain when
called with excess arguments, the function 'new.module'
does.  Ironically, the docstring for new.module seems to
imply it takes an argument.  Perhaps new.module should
simply refer to type(module), once the latter is fixed.

Another, far more radical fix for this bug would be to
change the constructor to accept the (name,bases,dict)
signature, thus making it possible to subclass a module and
have it work correctly, for some value of "correctly".  :)

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563060&group_id=5470



From noreply@sourceforge.net  Sat Jun  1 13:25:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 01 Jun 2002 05:25:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-563273 ] Clarify documentation for inspect
Message-ID: <E17E7x2-0001QH-00@usw-sf-web3.sourceforge.net>

Bugs item #563273, was opened at 2002-06-01 12:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563273&group_id=5470

Category: Documentation
Group: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Franc,ois Pinard (pinard)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Clarify documentation for inspect

Initial Comment:
See attached message text.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563273&group_id=5470



From noreply@sourceforge.net  Sat Jun  1 15:03:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 01 Jun 2002 07:03:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-563298 ] Fuzziness in inspect module documentatio
Message-ID: <E17E9TO-0000CH-00@usw-sf-web4.sourceforge.net>

Bugs item #563298, was opened at 2002-06-01 14:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563298&group_id=5470

Category: Documentation
Group: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Franc,ois Pinard (pinard)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Fuzziness in inspect module documentatio

Initial Comment:
Hello, Fred.

I'm looking at Web pages about the `inspect' module,
and more precisely
`inspect-stack.html'.  The text speaks about "higher"
and "lower", "above"
and "below", and this is ambiguous as people would draw
the stack top up,
and other would draw the stack top down.  Do you agree
that this could
be clarified?

The text could rather stick with words like "recent" or
"older", or "near
the top" or "away from the top", maybe.  Beware that
the word "deeper"
is ambiguous too.  Or else, the text could explain the
drawing convention
for stacks used in the text, so people could interpret
what is written.

One might try to guess the drawing conventions from the
fact functions have
"outer" and "inner" in their name, but this is too
difficult.

Maybe the text could use "outer" and "inner" more
systematically, all over?
It would most probably create more clarity.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563298&group_id=5470



From noreply@sourceforge.net  Sat Jun  1 15:10:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 01 Jun 2002 07:10:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-563303 ] Heap corruption in debug
Message-ID: <E17E9aK-0000FY-00@usw-sf-web4.sourceforge.net>

Bugs item #563303, was opened at 2002-06-01 03:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563303&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Cliff Owen (cliffo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Heap corruption in debug

Initial Comment:
PyObject_DebugMalloc() returns a pointer that is +8 
bytes to detect for underwriting the pointer.

Sometimes, PyObject_Free() is called instead of going 
through PyObject_DebugFree(). This means the pointer 
is off by 8. PyObject_Free() takes the pointer passed in 
as being valid, and will update the pool to indicate the 
passed pointer is a pointer to the new free block.

Corruption of the heap occurs when 
PyObject_DebugMalloc() is called and there are 
multiple free blocks in a row that are properly aligned. 
Writing the FORBIDDENBYTE set to the end of the 
newly allocated block may stomp the next free pointer.

2 more allocations later on this arena, and you will AV.

Why is PyObject_Free() being called instead of 
PyObject_DebugFree() (from ste_dealloc)? I'm 
assuming it was built incorrectly or there's an ordering 
issue in objimpl.h where PyObject_Free() is defined 
before the macro, and referenced by PyObject_Del.

The fact remains that a simple alignment check in 
PyObject_Free() will handle any misaligned pointer.

If I've got this completely screwed up and it is in fact 
building incorrectly, please let me know. I've traced 
through it about 100 times. I'm fairly certain I understand 
how/why it works the way it does, but I could be wrong.

This problem would only show up in debug mode.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563303&group_id=5470



From noreply@sourceforge.net  Sat Jun  1 15:56:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 01 Jun 2002 07:56:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-561858 ] Assertion with very long lists
Message-ID: <E17EAJN-0002Yu-00@usw-sf-web3.sourceforge.net>

Bugs item #561858, was opened at 2002-05-29 06:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Jerome Alet (jalet)
Assigned to: Nobody/Anonymous (nobody)
Summary: Assertion with very long lists

Initial Comment:
I've tried to import a module which only define a list
of 170000 elements (a word list) which defines an
element per line, so the module also has 170000 lines
in it. Here's the error :

--- CUT ---
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import dictionnaire
python: ../Python/ceval.c:695: eval_code2: Assertion
`(stack_pointer - f->f_valuestack) <= f->f_stacksize'
failed.
Abandon
--- CUT ---

this seems to be the same problem as bug id 210647 but
there's no segfault.

the module is attached to this bug report.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-01 10:56

Message:
Logged In: YES 
user_id=33168

Added a patch for 2.2 (2.1) is basically the same.
No test for 2.2/2.1 though.
Could someone please review before checkin?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 22:04

Message:
Logged In: YES 
user_id=33168

Final patch attached.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 20:17

Message:
Logged In: YES 
user_id=33168

Got a fix.  Patch attached.  
It will probably have to be changed,
since I don't remember what else needs to be
done when the MAGIC is changed.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 20:06

Message:
Logged In: YES 
user_id=33168

I found at least part of the problem, perhaps everything.
The co_stacksize > 32767 and only a short value is marshalled
to the .pyc.

See Python/marshal.c line 246.

Not sure how to fix yet.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 18:32

Message:
Logged In: YES 
user_id=33168

I think there are several problems here.
I was able to narrow down at least one problem to a long list.
It doesn't seem to have anything to do w/backslashes.

There seems to be an interaction with importing the module.
If the long list is in __main__, the problem does not occur.
The problem only occurs when the list is in an imported module
and only after importing it the second time (after the .pyc
is created).

If a list has 32768+ items there seems to be a memory problem.
There is an exception, then a crash.  Here's the exception:

TypeError: unsupported operand type(s) for &: 'str' and 'str'

Here's a stack trace against CVS version:

#0  chunk_free (ar_ptr=0x401b1620, p=0x8156a10) at malloc.c:3180
#1  0x400fdbf4 in __libc_free (mem=0x8156a18) at malloc.c:3154
#2  0x0805c0db in list_dealloc (op=0x401c4eac) at
Objects/listobject.c:214
#3  0x080c7618 in PyDict_SetItem (op=0x401bd79c,
key=0x401c4ec0, 
    value=0x80e185c) at Objects/dictobject.c:373
#4  0x080c93f9 in PyDict_SetItemString (v=0x401bd79c,
key=0x80d9070 "path", 
    item=0x80e185c) at Objects/dictobject.c:1895
#5  0x08099ad8 in PyImport_Cleanup () at Python/import.c:286
#6  0x080a266d in Py_Finalize () at Python/pythonrun.c:228
#7  0x08053766 in Py_Main (argc=2, argv=0xbffff904) at
Modules/main.c:379


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

Comment By: Jerome Alet (jalet)
Date: 2002-05-29 08:42

Message:
Logged In: YES 
user_id=97214

I've done more tests, the bug only occurs if every line has
a backslash at its end :

liste = [ \
            "item0", \
            "item1", \
            # ... many many lines
            "itemN" ]

and it works if I remove the \ from each end of line.

hth.

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

Comment By: Jerome Alet (jalet)
Date: 2002-05-29 06:14

Message:
Logged In: YES 
user_id=97214

module too long to be attached. ask it by email at
alet@librelogiciel.com if needed.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470



From noreply@sourceforge.net  Sat Jun  1 16:03:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 01 Jun 2002 08:03:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-563148 ] built-in LIST operation has bug
Message-ID: <E17EAPU-0000cN-00@usw-sf-web4.sourceforge.net>

Bugs item #563148, was opened at 2002-06-01 01:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563148&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Tom Stanik (mytost)
>Assigned to: Michael Hudson (mwh)
Summary: built-in LIST operation has bug

Initial Comment:
example, to create a list of lists one can enter:

>>> d=[[0] * 4] * 5
>>> print d
[[0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 
0]]

if you want to change the first element in the first list:

>>> d[0][0]=1
>>> print d
[[1, 0, 0, 0], [1, 0, 0, 0], [1, 0, 0, 0], [1, 0, 0, 0], [1, 0, 0, 
0]] ***** INCORECT *****, all the first element changed

Alternatively, if you build the list manually:

>>> d=[0,0,0,0,0]
>>> d[0]=[0,0,0,0]
>>> d[1]=[0,0,0,0]
>>> d[2]=[0,0,0,0]
>>> d[3]=[0,0,0,0]
>>> print d
[[0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 
0]] 

changing the first element in the first list yields the 
correct result

>>> d[0][0]=1
>>> print d
[[1, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 
0]] ***** CORRECT *****

The same list depending on hows it built yields a 
different behavior

my version of python:

$ python -v
# /usr/local/lib/python2.2/site.pyc 
matches /usr/local/lib/python2.2/site.py
import site # precompiled 
from /usr/local/lib/python2.2/site.pyc
# /usr/local/lib/python2.2/os.pyc 
matches /usr/local/lib/python2.2/os.py
import os # precompiled 
from /usr/local/lib/python2.2/os.pyc
import posix # builtin
# /usr/local/lib/python2.2/posixpath.pyc 
matches /usr/local/lib/python2.2/posixpath.py
import posixpath # precompiled 
from /usr/local/lib/python2.2/posixpath.pyc
# /usr/local/lib/python2.2/stat.pyc 
matches /usr/local/lib/python2.2/stat.py
import stat # precompiled 
from /usr/local/lib/python2.2/stat.pyc
# /usr/local/lib/python2.2/UserDict.pyc 
matches /usr/local/lib/python2.2/UserDict.py
import UserDict # precompiled 
from /usr/local/lib/python2.2/UserDict.pyc
# /usr/local/lib/python2.2/copy_reg.pyc 
matches /usr/local/lib/python2.2/copy_reg.py
import copy_reg # precompiled 
from /usr/local/lib/python2.2/copy_reg.pyc
# /usr/local/lib/python2.2/types.pyc 
matches /usr/local/lib/python2.2/types.py
import types # precompiled 
from /usr/local/lib/python2.2/types.pyc
# /usr/local/lib/python2.2/__future__.pyc 
matches /usr/local/lib/python2.2/__future__.py
import __future__ # precompiled 
from /usr/local/lib/python2.2/__future__.pyc
Python 2.2.1 (#1, May 10 2002, 23:36:51) 
[GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more 
information.
dlopen("/usr/local/lib/python2.2/lib-dynload/readline.so", 
2);
import readline # dynamically loaded 
from /usr/local/lib/python2.2/lib-dynload/readline.so
>>> 




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

>Comment By: Michael Hudson (mwh)
Date: 2002-06-01 15:03

Message:
Logged In: YES 
user_id=6656

Sigh.  This is not a bug.  You could try reading 

http://starship.python.net/crew/mwh/hacks/objectthink.html

to gain a better understanding of what's going on.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563148&group_id=5470



From noreply@sourceforge.net  Sat Jun  1 16:05:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 01 Jun 2002 08:05:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-563148 ] built-in LIST operation has bug
Message-ID: <E17EARM-0002cX-00@usw-sf-web3.sourceforge.net>

Bugs item #563148, was opened at 2002-05-31 21:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563148&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Tom Stanik (mytost)
>Assigned to: Nobody/Anonymous (nobody)
Summary: built-in LIST operation has bug

Initial Comment:
example, to create a list of lists one can enter:

>>> d=[[0] * 4] * 5
>>> print d
[[0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 
0]]

if you want to change the first element in the first list:

>>> d[0][0]=1
>>> print d
[[1, 0, 0, 0], [1, 0, 0, 0], [1, 0, 0, 0], [1, 0, 0, 0], [1, 0, 0, 
0]] ***** INCORECT *****, all the first element changed

Alternatively, if you build the list manually:

>>> d=[0,0,0,0,0]
>>> d[0]=[0,0,0,0]
>>> d[1]=[0,0,0,0]
>>> d[2]=[0,0,0,0]
>>> d[3]=[0,0,0,0]
>>> print d
[[0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 
0]] 

changing the first element in the first list yields the 
correct result

>>> d[0][0]=1
>>> print d
[[1, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 
0]] ***** CORRECT *****

The same list depending on hows it built yields a 
different behavior

my version of python:

$ python -v
# /usr/local/lib/python2.2/site.pyc 
matches /usr/local/lib/python2.2/site.py
import site # precompiled 
from /usr/local/lib/python2.2/site.pyc
# /usr/local/lib/python2.2/os.pyc 
matches /usr/local/lib/python2.2/os.py
import os # precompiled 
from /usr/local/lib/python2.2/os.pyc
import posix # builtin
# /usr/local/lib/python2.2/posixpath.pyc 
matches /usr/local/lib/python2.2/posixpath.py
import posixpath # precompiled 
from /usr/local/lib/python2.2/posixpath.pyc
# /usr/local/lib/python2.2/stat.pyc 
matches /usr/local/lib/python2.2/stat.py
import stat # precompiled 
from /usr/local/lib/python2.2/stat.pyc
# /usr/local/lib/python2.2/UserDict.pyc 
matches /usr/local/lib/python2.2/UserDict.py
import UserDict # precompiled 
from /usr/local/lib/python2.2/UserDict.pyc
# /usr/local/lib/python2.2/copy_reg.pyc 
matches /usr/local/lib/python2.2/copy_reg.py
import copy_reg # precompiled 
from /usr/local/lib/python2.2/copy_reg.pyc
# /usr/local/lib/python2.2/types.pyc 
matches /usr/local/lib/python2.2/types.py
import types # precompiled 
from /usr/local/lib/python2.2/types.pyc
# /usr/local/lib/python2.2/__future__.pyc 
matches /usr/local/lib/python2.2/__future__.py
import __future__ # precompiled 
from /usr/local/lib/python2.2/__future__.pyc
Python 2.2.1 (#1, May 10 2002, 23:36:51) 
[GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more 
information.
dlopen("/usr/local/lib/python2.2/lib-dynload/readline.so", 
2);
import readline # dynamically loaded 
from /usr/local/lib/python2.2/lib-dynload/readline.so
>>> 




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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-01 11:05

Message:
Logged In: YES 
user_id=33168

This is the expected behaviour.
See FAQ entry 4.50.

http://www.python.org/cgi-bin/faqw.py?req=show&file=faq04.050.htp


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

Comment By: Michael Hudson (mwh)
Date: 2002-06-01 11:03

Message:
Logged In: YES 
user_id=6656

Sigh.  This is not a bug.  You could try reading 

http://starship.python.net/crew/mwh/hacks/objectthink.html

to gain a better understanding of what's going on.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563148&group_id=5470



From noreply@sourceforge.net  Sat Jun  1 17:35:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 01 Jun 2002 09:35:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-563303 ] Heap corruption in debug
Message-ID: <E17EBrB-0001FE-00@usw-sf-web4.sourceforge.net>

Bugs item #563303, was opened at 2002-06-01 10:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563303&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Cliff Owen (cliffo)
>Assigned to: Tim Peters (tim_one)
Summary: Heap corruption in debug

Initial Comment:
PyObject_DebugMalloc() returns a pointer that is +8 
bytes to detect for underwriting the pointer.

Sometimes, PyObject_Free() is called instead of going 
through PyObject_DebugFree(). This means the pointer 
is off by 8. PyObject_Free() takes the pointer passed in 
as being valid, and will update the pool to indicate the 
passed pointer is a pointer to the new free block.

Corruption of the heap occurs when 
PyObject_DebugMalloc() is called and there are 
multiple free blocks in a row that are properly aligned. 
Writing the FORBIDDENBYTE set to the end of the 
newly allocated block may stomp the next free pointer.

2 more allocations later on this arena, and you will AV.

Why is PyObject_Free() being called instead of 
PyObject_DebugFree() (from ste_dealloc)? I'm 
assuming it was built incorrectly or there's an ordering 
issue in objimpl.h where PyObject_Free() is defined 
before the macro, and referenced by PyObject_Del.

The fact remains that a simple alignment check in 
PyObject_Free() will handle any misaligned pointer.

If I've got this completely screwed up and it is in fact 
building incorrectly, please let me know. I've traced 
through it about 100 times. I'm fairly certain I understand 
how/why it works the way it does, but I could be wrong.

This problem would only show up in debug mode.

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

>Comment By: Tim Peters (tim_one)
Date: 2002-06-01 12:35

Message:
Logged In: YES 
user_id=31435

Do you have an actual program that shows corruption, or 
are you speculating?

Note that in a debug build, it's not possible to call 
PyObject_Free:  the name PyObject_Free is remapped to 
_PyObject_DebugFree by objimpl.h then.  In a debug build 
when pymalloc is enabled, all calls to all PyMem_XYZ and 
PyObject_XYZ memory functions are redirected to 
_PyObject_DebugXYZ, except within obmalloc.c itself 
(which #undefs some name substitutions).

ste_dealloc doesn't call PyObject_Free.  It calls 
PyObject_Del.  In a debug pymalloc build, that ends up 
calling _PyObject_DebugFree.  Step through it in a 
debugger if you don't believe it <wink>.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563303&group_id=5470



From noreply@sourceforge.net  Sat Jun  1 17:55:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 01 Jun 2002 09:55:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-563338 ] Getting traceback in embedded python.
Message-ID: <E17ECAS-0001Sj-00@usw-sf-web2.sourceforge.net>

Bugs item #563338, was opened at 2002-06-01 09:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563338&group_id=5470

Category: Documentation
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Bjorn Pettersen (bpettersen)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Getting traceback in embedded python.

Initial Comment:
It would be nice if there was an API method for getting 
the traceback as a string for use in embedded Python 
applications. Since I couldn't find any such function I 
created the following, maybe it could be added to the 
embedding docs?

class PyException : public std::exception {
  std::string msg;
public:
  PyException(const std::string& m) : msg(m) {}
  const char* what() { return msg.c_str(); }
};

std::string getTraceback() {
  std::string result;
  PyObject *exception, *v, *traceback;
  PyErr_Fetch(&exception, &v, &traceback);
  PyErr_NormalizeException(&exception, &v, 
&traceback);

  /*
    import traceback
    lst = traceback.format_exception(exception, v, 
traceback)
  */
  PyObject* tbstr = PyString_FromString("traceback");
  PyObject* tbmod = PyImport_Import(tbstr);
  if (!tbmod) 
    throw PyException("Unable to import traceback 
module. Is your Python installed?");
  PyObject* tbdict = PyModule_GetDict(tbmod);
  PyObject* formatFunc = PyDict_GetItemString
(tbdict, "format_exception");
  if (!formatFunc) 
    throw PyException("Can't find 
traceback.format_exception");
  if (!traceback) {
    traceback = Py_None;
    Py_INCREF(Py_None);
  }
  PyObject* args = Py_BuildValue("(OOO)", exception, 
v, traceback);
  PyObject* lst = PyObject_CallObject(formatFunc, 
args);

  for (int i=0; i<PyList_GET_SIZE(lst); i++) {
    result += PyString_AsString(PyList_GetItem(lst, i));
  }

  Py_DECREF(args);
  Py_DECREF(lst);
  return result;
}


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563338&group_id=5470



From noreply@sourceforge.net  Sat Jun  1 19:14:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 01 Jun 2002 11:14:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-561858 ] Assertion with very long lists
Message-ID: <E17EDP0-0003ub-00@usw-sf-web3.sourceforge.net>

Bugs item #561858, was opened at 2002-05-29 06:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Jerome Alet (jalet)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Assertion with very long lists

Initial Comment:
I've tried to import a module which only define a list
of 170000 elements (a word list) which defines an
element per line, so the module also has 170000 lines
in it. Here's the error :

--- CUT ---
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import dictionnaire
python: ../Python/ceval.c:695: eval_code2: Assertion
`(stack_pointer - f->f_valuestack) <= f->f_stacksize'
failed.
Abandon
--- CUT ---

this seems to be the same problem as bug id 210647 but
there's no segfault.

the module is attached to this bug report.

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

>Comment By: Tim Peters (tim_one)
Date: 2002-06-01 14:14

Message:
Logged In: YES 
user_id=31435

Assuming the patch you're talking about is the one named 
long-list-2.2.diff, looks good to me, so Accepted and 
assigned back to you.  Thanks!

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-01 10:56

Message:
Logged In: YES 
user_id=33168

Added a patch for 2.2 (2.1) is basically the same.
No test for 2.2/2.1 though.
Could someone please review before checkin?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 22:04

Message:
Logged In: YES 
user_id=33168

Final patch attached.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 20:17

Message:
Logged In: YES 
user_id=33168

Got a fix.  Patch attached.  
It will probably have to be changed,
since I don't remember what else needs to be
done when the MAGIC is changed.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 20:06

Message:
Logged In: YES 
user_id=33168

I found at least part of the problem, perhaps everything.
The co_stacksize > 32767 and only a short value is marshalled
to the .pyc.

See Python/marshal.c line 246.

Not sure how to fix yet.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 18:32

Message:
Logged In: YES 
user_id=33168

I think there are several problems here.
I was able to narrow down at least one problem to a long list.
It doesn't seem to have anything to do w/backslashes.

There seems to be an interaction with importing the module.
If the long list is in __main__, the problem does not occur.
The problem only occurs when the list is in an imported module
and only after importing it the second time (after the .pyc
is created).

If a list has 32768+ items there seems to be a memory problem.
There is an exception, then a crash.  Here's the exception:

TypeError: unsupported operand type(s) for &: 'str' and 'str'

Here's a stack trace against CVS version:

#0  chunk_free (ar_ptr=0x401b1620, p=0x8156a10) at malloc.c:3180
#1  0x400fdbf4 in __libc_free (mem=0x8156a18) at malloc.c:3154
#2  0x0805c0db in list_dealloc (op=0x401c4eac) at
Objects/listobject.c:214
#3  0x080c7618 in PyDict_SetItem (op=0x401bd79c,
key=0x401c4ec0, 
    value=0x80e185c) at Objects/dictobject.c:373
#4  0x080c93f9 in PyDict_SetItemString (v=0x401bd79c,
key=0x80d9070 "path", 
    item=0x80e185c) at Objects/dictobject.c:1895
#5  0x08099ad8 in PyImport_Cleanup () at Python/import.c:286
#6  0x080a266d in Py_Finalize () at Python/pythonrun.c:228
#7  0x08053766 in Py_Main (argc=2, argv=0xbffff904) at
Modules/main.c:379


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

Comment By: Jerome Alet (jalet)
Date: 2002-05-29 08:42

Message:
Logged In: YES 
user_id=97214

I've done more tests, the bug only occurs if every line has
a backslash at its end :

liste = [ \
            "item0", \
            "item1", \
            # ... many many lines
            "itemN" ]

and it works if I remove the \ from each end of line.

hth.

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

Comment By: Jerome Alet (jalet)
Date: 2002-05-29 06:14

Message:
Logged In: YES 
user_id=97214

module too long to be attached. ask it by email at
alet@librelogiciel.com if needed.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470



From noreply@sourceforge.net  Sat Jun  1 19:28:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 01 Jun 2002 11:28:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-561858 ] Assertion with very long lists
Message-ID: <E17EDc0-00040L-00@usw-sf-web3.sourceforge.net>

Bugs item #561858, was opened at 2002-05-29 06:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Jerome Alet (jalet)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Assertion with very long lists

Initial Comment:
I've tried to import a module which only define a list
of 170000 elements (a word list) which defines an
element per line, so the module also has 170000 lines
in it. Here's the error :

--- CUT ---
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import dictionnaire
python: ../Python/ceval.c:695: eval_code2: Assertion
`(stack_pointer - f->f_valuestack) <= f->f_stacksize'
failed.
Abandon
--- CUT ---

this seems to be the same problem as bug id 210647 but
there's no segfault.

the module is attached to this bug report.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-01 14:28

Message:
Logged In: YES 
user_id=33168

Thanks Tim.
Checked in for 2.1/2.2 as 2.175.2.3 and 2.192.6.2. 

Could you or someone also review the other patch for current
CVS?
That patch has a test and is different ([rw]_short ->
[rw]_long).

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

Comment By: Tim Peters (tim_one)
Date: 2002-06-01 14:14

Message:
Logged In: YES 
user_id=31435

Assuming the patch you're talking about is the one named 
long-list-2.2.diff, looks good to me, so Accepted and 
assigned back to you.  Thanks!

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-01 10:56

Message:
Logged In: YES 
user_id=33168

Added a patch for 2.2 (2.1) is basically the same.
No test for 2.2/2.1 though.
Could someone please review before checkin?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 22:04

Message:
Logged In: YES 
user_id=33168

Final patch attached.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 20:17

Message:
Logged In: YES 
user_id=33168

Got a fix.  Patch attached.  
It will probably have to be changed,
since I don't remember what else needs to be
done when the MAGIC is changed.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 20:06

Message:
Logged In: YES 
user_id=33168

I found at least part of the problem, perhaps everything.
The co_stacksize > 32767 and only a short value is marshalled
to the .pyc.

See Python/marshal.c line 246.

Not sure how to fix yet.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 18:32

Message:
Logged In: YES 
user_id=33168

I think there are several problems here.
I was able to narrow down at least one problem to a long list.
It doesn't seem to have anything to do w/backslashes.

There seems to be an interaction with importing the module.
If the long list is in __main__, the problem does not occur.
The problem only occurs when the list is in an imported module
and only after importing it the second time (after the .pyc
is created).

If a list has 32768+ items there seems to be a memory problem.
There is an exception, then a crash.  Here's the exception:

TypeError: unsupported operand type(s) for &: 'str' and 'str'

Here's a stack trace against CVS version:

#0  chunk_free (ar_ptr=0x401b1620, p=0x8156a10) at malloc.c:3180
#1  0x400fdbf4 in __libc_free (mem=0x8156a18) at malloc.c:3154
#2  0x0805c0db in list_dealloc (op=0x401c4eac) at
Objects/listobject.c:214
#3  0x080c7618 in PyDict_SetItem (op=0x401bd79c,
key=0x401c4ec0, 
    value=0x80e185c) at Objects/dictobject.c:373
#4  0x080c93f9 in PyDict_SetItemString (v=0x401bd79c,
key=0x80d9070 "path", 
    item=0x80e185c) at Objects/dictobject.c:1895
#5  0x08099ad8 in PyImport_Cleanup () at Python/import.c:286
#6  0x080a266d in Py_Finalize () at Python/pythonrun.c:228
#7  0x08053766 in Py_Main (argc=2, argv=0xbffff904) at
Modules/main.c:379


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

Comment By: Jerome Alet (jalet)
Date: 2002-05-29 08:42

Message:
Logged In: YES 
user_id=97214

I've done more tests, the bug only occurs if every line has
a backslash at its end :

liste = [ \
            "item0", \
            "item1", \
            # ... many many lines
            "itemN" ]

and it works if I remove the \ from each end of line.

hth.

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

Comment By: Jerome Alet (jalet)
Date: 2002-05-29 06:14

Message:
Logged In: YES 
user_id=97214

module too long to be attached. ask it by email at
alet@librelogiciel.com if needed.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470



From noreply@sourceforge.net  Sat Jun  1 22:05:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 01 Jun 2002 14:05:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-562585 ] build problems on DEC Unix 4.0f
Message-ID: <E17EG4B-0008Tq-00@usw-sf-web1.sourceforge.net>

Bugs item #562585, was opened at 2002-05-30 22:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562585&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Garey Mills (gareytm)
Assigned to: Nobody/Anonymous (nobody)
Summary: build problems on DEC Unix 4.0f

Initial Comment:
Building with cc instead of gcc (as recommended) and with configure switch '--with-dec-threads' (also 
recommended. 'make test yields the following errors and messages:

test test_bsddb crashed -- bsddb.error: (22, 'Invalid argument')

test test_format produced unexpected output:
**********************************************************************
*** lines 2-3 of actual output doesn't appear in expected output after line 1:
+ '%#o' % 0 == '00' != '0'
+ u'%#o' % 0 == u'00' != '0'
**********************************************************************


2 tests failed:
    test_bsddb test_format
27 tests skipped:
    test_al test_audioop test_cd test_cl test_curses test_dl test_gdbm
    test_gl test_gzip test_imageop test_imgfile test_linuxaudiodev
    test_locale test_minidom test_nis test_ntpath test_pyexpat
    test_rgbimg test_sax test_socket_ssl test_socketserver
    test_sunaudiodev test_unicode_file test_winreg test_winsound
    test_zipfile test_zlib
Ask someone to teach regrtest.py about which tests are
expected to get skipped on osf1V4.


Are test failures important? Who do I ask "to teach regrtest.py about which tests are expected to get 
skipped on osf1V4"?

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-01 23:05

Message:
Logged In: YES 
user_id=21627

Ok, I don't feel qualified to analyse this further from
remote. It seems that something on your system does not like
this file name; not sure whether this is the operating
system, bsddb, or something else. One would need to use
debugging techniques to get more information about the
nature of this problem. If you don't plan to use bsddb, you
can probably safely ignore this problem.

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

Comment By: Garey Mills (gareytm)
Date: 2002-06-01 00:47

Message:
Logged In: YES 
user_id=555793

Here is the output of the test with the file name:

# ./python Lib/test/regrtest.py -v test_bsddb
test_bsddb

Testing:  BTree

fname:  /tmp/@18218.0
test test_bsddb crashed -- bsddb.error: (22, 'Invalid argument')
Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 305, in runtest
    the_module = __import__(test, globals(), locals(), [])
  File "Lib/test/test_bsddb.py", line 79, in ?
    test(type[0], type[1])
  File "Lib/test/test_bsddb.py", line 21, in test
    f = openmethod(fname, 'c')
error: (22, 'Invalid argument')
1 test failed:
    test_bsddb

Garey

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-01 00:12

Message:
Logged In: YES 
user_id=21627

Can you please edit the fragment in test_bsddb.py that reads

    f = openmethod(fname, 'c')

to print fname before that line? Apparently, mktemp returns
a bad file name.

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

Comment By: Garey Mills (gareytm)
Date: 2002-05-31 00:40

Message:
Logged In: YES 
user_id=555793

Here are the command and output

# ./python Lib/test/regrtest.py -v test_bsddb
test_bsddb

Testing:  BTree
test test_bsddb crashed -- bsddb.error: (22, 'Invalid argument')
Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 305, in runtest
    the_module = __import__(test, globals(), locals(), [])
  File "./Lib/test/test_bsddb.py", line 76, in ?
    test(type[0], type[1])
  File "./Lib/test/test_bsddb.py", line 18, in test
    f = openmethod(fname, 'c')
error: (22, 'Invalid argument')
1 test failed:
    test_bsddb

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-31 00:18

Message:
Logged In: YES 
user_id=21627

the test_format bug is not important; it indicates a bug in
the system's C library.

For recording expected skipped tests, see Lib/regrtest.py.
Search for win32, and submit a patch that records the
expected skips. Alternatively, just don't worry about this.

For test_:bsddb, please run "python Lib/regrtest.py -v
test_bsddb" separately, and report the output.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562585&group_id=5470



From noreply@sourceforge.net  Sat Jun  1 22:10:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 01 Jun 2002 14:10:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-562892 ] use python if not pass test format??
Message-ID: <E17EG8b-0008Vz-00@usw-sf-web1.sourceforge.net>

Bugs item #562892, was opened at 2002-05-31 14:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562892&group_id=5470

Category: Build
Group: Python 2.2.1
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: ellen davis (ellendavis)
Assigned to: Nobody/Anonymous (nobody)
Summary: use python if not pass test format??

Initial Comment:

I have built pythin 2.2.1 on my Tru64 4.0F AlphapServer.  It builds OK, but does not pass test_format.  
>From previous posts, I found that the libc on Tru64 is broken (not ansi compliant), and that is the reason 
the test fails.  

I have a user in need on python today.  Is it safe to use the python binary, even though the test_format 
failed?  



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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-01 23:10

Message:
Logged In: YES 
user_id=21627

Yes, it is safe to use Python in this case; the failed test
indeed indicates a problem in the system's C library.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562892&group_id=5470



From noreply@sourceforge.net  Sat Jun  1 22:41:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 01 Jun 2002 14:41:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-559429 ] __gxx_personality_v0 not found by ld
Message-ID: <E17EGcx-0003Y1-00@usw-sf-web2.sourceforge.net>

Bugs item #559429, was opened at 2002-05-23 02:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559429&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: george r. goffe (grgoffe)
Assigned to: Nobody/Anonymous (nobody)
Summary: __gxx_personality_v0 not found by ld

Initial Comment:

Howdy,

I'm building Python-2.2.1 on a solaris 2.8 system and
am having trouble. The loader can not find the above
named external reference.

I'm enclosing the build log that shows (probably) more
than you ever wanted to know but it DOES show the
problem.

Any/all help/hints/tips would be appreciated.

Regards,

George...

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-01 23:41

Message:
Logged In: YES 
user_id=21627

The problem is that configure fails to recognize that
linking requires g++ with g++ 3; this is fixed in
configure.in 1.319/configure 1.309.

I recommend that you do not give any --with-cxx option to
configure.

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

Comment By: george r. goffe (grgoffe)
Date: 2002-05-31 04:54

Message:
Logged In: YES 
user_id=293753

Howdy,

I'm attempting to attach the latest build log. The old
version of my gcc was 3.0.4. This version is with gcc-3.1.

Sorry about the foulup.

Regards and thanks for all your help and time.

George...



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-31 00:22

Message:
Logged In: YES 
user_id=21627

This looks like a bug in your gcc installation. Python does
not define or use a symbol of that name.

You haven't actually enclosed the build log, but I don't
think this is necessary - it's a bug of your system. If you
disagree, please report the gcc version.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-24 21:15

Message:
Logged In: NO 

Hi,

I'm looking at the same problem in the same environment.

I could fix the failed compilation by changing gcc by g++,
which means that the --with-cxx=g++ option passed to
configure did not have the expected effect.

Regards,

R. Berber


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559429&group_id=5470



From noreply@sourceforge.net  Sat Jun  1 23:22:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 01 Jun 2002 15:22:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-563303 ] Heap corruption in debug
Message-ID: <E17EHGn-0003lO-00@usw-sf-web4.sourceforge.net>

Bugs item #563303, was opened at 2002-06-01 03:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563303&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Cliff Owen (cliffo)
Assigned to: Tim Peters (tim_one)
Summary: Heap corruption in debug

Initial Comment:
PyObject_DebugMalloc() returns a pointer that is +8 
bytes to detect for underwriting the pointer.

Sometimes, PyObject_Free() is called instead of going 
through PyObject_DebugFree(). This means the pointer 
is off by 8. PyObject_Free() takes the pointer passed in 
as being valid, and will update the pool to indicate the 
passed pointer is a pointer to the new free block.

Corruption of the heap occurs when 
PyObject_DebugMalloc() is called and there are 
multiple free blocks in a row that are properly aligned. 
Writing the FORBIDDENBYTE set to the end of the 
newly allocated block may stomp the next free pointer.

2 more allocations later on this arena, and you will AV.

Why is PyObject_Free() being called instead of 
PyObject_DebugFree() (from ste_dealloc)? I'm 
assuming it was built incorrectly or there's an ordering 
issue in objimpl.h where PyObject_Free() is defined 
before the macro, and referenced by PyObject_Del.

The fact remains that a simple alignment check in 
PyObject_Free() will handle any misaligned pointer.

If I've got this completely screwed up and it is in fact 
building incorrectly, please let me know. I've traced 
through it about 100 times. I'm fairly certain I understand 
how/why it works the way it does, but I could be wrong.

This problem would only show up in debug mode.

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

>Comment By: Cliff Owen (cliffo)
Date: 2002-06-01 11:22

Message:
Logged In: YES 
user_id=556609

Yes, I do have a program which demonstrates the problem. 
However, I cannot send it in because it is commercial in 
nature. :( I understand this poses a bit of a problem for 
debugging, but I'm hoping you understand. I do have other 
things that require more of my time than browsing the Python 
sources and making speculations on what I see. This did AV, 
and I did spend a while debugging it, with a debugger. Being 
the nice developer who's using a free product that's not being 
maintained by me, I thought I'd report this.

Yes, I also have seen what happens inside of objimpl.h, and 
do know that PyObject_Del is called in ste_dealloc. These 
are details I didn't think necessary to mention because you 
would obviously be familiar with the code and since I 
mentioned ste_dealloc, you might assume I would be familiar 
with these mappings as well since ste_dealloc() clearly calls 
PyObject_Del, which is nothing but a macro to 
PyObject_Free.

Regardless and bickering aside, I have added the following 
line to PyObject_Free() in my own code and it resolves the 
problem by assuring that any pointer passed in is properly 
aligned on the correct block size. This one line covers a 
multitude of sins from the caller.

p = (char *) p - ((char *)p - ((char *)pool + 
POOL_OVERHEAD)) % INDEX2SIZE(pool->szidx);

Right after:

if (ADDRESS_IN_RANGE(p, pool->arenaindex))

If you choose to use this line or not is up to you. If the user 
passes in a pointer that is aligned, this line does nothing. If 
the user passes in a pointer which resides anywhere in a 
valid block, that block is released. Is this the correct 
behavior? Probably not. It should probably raise an exception 
rather than allow the user to get away with it. This would at 
least force the user to figure out why they were passing in a 
bogus pointer in the first place.

Some additional information: I am building with MSVC 6.x 
(SP3), using a snapshot of the python 2.3 build. I am 
compiling into a static library using these defines only.

WIN32,_DEBUG,_MBCS,_LIB,USE_DL_EXPORT

If you need additional information, let me know. I'm not sure 
what else I can tell you.


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

Comment By: Tim Peters (tim_one)
Date: 2002-06-01 05:35

Message:
Logged In: YES 
user_id=31435

Do you have an actual program that shows corruption, or 
are you speculating?

Note that in a debug build, it's not possible to call 
PyObject_Free:  the name PyObject_Free is remapped to 
_PyObject_DebugFree by objimpl.h then.  In a debug build 
when pymalloc is enabled, all calls to all PyMem_XYZ and 
PyObject_XYZ memory functions are redirected to 
_PyObject_DebugXYZ, except within obmalloc.c itself 
(which #undefs some name substitutions).

ste_dealloc doesn't call PyObject_Free.  It calls 
PyObject_Del.  In a debug pymalloc build, that ends up 
calling _PyObject_DebugFree.  Step through it in a 
debugger if you don't believe it <wink>.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563303&group_id=5470



From noreply@sourceforge.net  Sun Jun  2 00:56:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 01 Jun 2002 16:56:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-563303 ] Heap corruption in debug
Message-ID: <E17EIjh-0001OR-00@usw-sf-web1.sourceforge.net>

Bugs item #563303, was opened at 2002-06-01 10:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563303&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Cliff Owen (cliffo)
Assigned to: Tim Peters (tim_one)
Summary: Heap corruption in debug

Initial Comment:
PyObject_DebugMalloc() returns a pointer that is +8 
bytes to detect for underwriting the pointer.

Sometimes, PyObject_Free() is called instead of going 
through PyObject_DebugFree(). This means the pointer 
is off by 8. PyObject_Free() takes the pointer passed in 
as being valid, and will update the pool to indicate the 
passed pointer is a pointer to the new free block.

Corruption of the heap occurs when 
PyObject_DebugMalloc() is called and there are 
multiple free blocks in a row that are properly aligned. 
Writing the FORBIDDENBYTE set to the end of the 
newly allocated block may stomp the next free pointer.

2 more allocations later on this arena, and you will AV.

Why is PyObject_Free() being called instead of 
PyObject_DebugFree() (from ste_dealloc)? I'm 
assuming it was built incorrectly or there's an ordering 
issue in objimpl.h where PyObject_Free() is defined 
before the macro, and referenced by PyObject_Del.

The fact remains that a simple alignment check in 
PyObject_Free() will handle any misaligned pointer.

If I've got this completely screwed up and it is in fact 
building incorrectly, please let me know. I've traced 
through it about 100 times. I'm fairly certain I understand 
how/why it works the way it does, but I could be wrong.

This problem would only show up in debug mode.

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

>Comment By: Tim Peters (tim_one)
Date: 2002-06-01 19:56

Message:
Logged In: YES 
user_id=31435

Could you try to describe exactly how the problem arises, 
holding off on speculation about causes and cures?  What I 
still don't grasp at all is how you get into this situation to 
begin with:  it should be impossible to enter PyObject_Free
() in a pymalloc debug build *except* when 
_PyObject_DebugFree() calls it.  Your report begins with

"""
Sometimes, PyObject_Free() is called instead of going 
through PyObject_DebugFree(). 
"""

and I'm still lost on that sentence:  it shouldn't be possible 
to do that in a debug build.  If there is a way to do it, it's a 
serious problem, and your suggested code won't fix it (it 
may hide bad symptoms by accident for a while, but the 
problem still exists and will come back to bite you later).

It's unclear to me why you mentioned ste_dealloc, but I've 
stepped thru that in the MSVC 6 debugger and it does call 
_PyObject_DebugFree in a debug build.  It's doing what it's 
supposed to do. 

1. Is it your claim that ste_dealloc actually calls 
PyObject_Free directly in *your* debug build?  "Yes" or "no" 
would be more helpful than outrage <wink>.

2. What does "a snapshot of the python 2.3 build" mean, 
exactly?  Did you compile it yourself?  If not, from where did 
you get it?

3. Are you writing your own C extensions?  If so, are you 
mixing _DEBUG with non-_DEBUG between Python and 
your own code?  If you are so mixing, it's never going to 
work (Python and extension modules on Windows must 
both be built with _DEBUG, or neither).

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

Comment By: Cliff Owen (cliffo)
Date: 2002-06-01 18:22

Message:
Logged In: YES 
user_id=556609

Yes, I do have a program which demonstrates the problem. 
However, I cannot send it in because it is commercial in 
nature. :( I understand this poses a bit of a problem for 
debugging, but I'm hoping you understand. I do have other 
things that require more of my time than browsing the Python 
sources and making speculations on what I see. This did AV, 
and I did spend a while debugging it, with a debugger. Being 
the nice developer who's using a free product that's not being 
maintained by me, I thought I'd report this.

Yes, I also have seen what happens inside of objimpl.h, and 
do know that PyObject_Del is called in ste_dealloc. These 
are details I didn't think necessary to mention because you 
would obviously be familiar with the code and since I 
mentioned ste_dealloc, you might assume I would be familiar 
with these mappings as well since ste_dealloc() clearly calls 
PyObject_Del, which is nothing but a macro to 
PyObject_Free.

Regardless and bickering aside, I have added the following 
line to PyObject_Free() in my own code and it resolves the 
problem by assuring that any pointer passed in is properly 
aligned on the correct block size. This one line covers a 
multitude of sins from the caller.

p = (char *) p - ((char *)p - ((char *)pool + 
POOL_OVERHEAD)) % INDEX2SIZE(pool->szidx);

Right after:

if (ADDRESS_IN_RANGE(p, pool->arenaindex))

If you choose to use this line or not is up to you. If the user 
passes in a pointer that is aligned, this line does nothing. If 
the user passes in a pointer which resides anywhere in a 
valid block, that block is released. Is this the correct 
behavior? Probably not. It should probably raise an exception 
rather than allow the user to get away with it. This would at 
least force the user to figure out why they were passing in a 
bogus pointer in the first place.

Some additional information: I am building with MSVC 6.x 
(SP3), using a snapshot of the python 2.3 build. I am 
compiling into a static library using these defines only.

WIN32,_DEBUG,_MBCS,_LIB,USE_DL_EXPORT

If you need additional information, let me know. I'm not sure 
what else I can tell you.


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

Comment By: Tim Peters (tim_one)
Date: 2002-06-01 12:35

Message:
Logged In: YES 
user_id=31435

Do you have an actual program that shows corruption, or 
are you speculating?

Note that in a debug build, it's not possible to call 
PyObject_Free:  the name PyObject_Free is remapped to 
_PyObject_DebugFree by objimpl.h then.  In a debug build 
when pymalloc is enabled, all calls to all PyMem_XYZ and 
PyObject_XYZ memory functions are redirected to 
_PyObject_DebugXYZ, except within obmalloc.c itself 
(which #undefs some name substitutions).

ste_dealloc doesn't call PyObject_Free.  It calls 
PyObject_Del.  In a debug pymalloc build, that ends up 
calling _PyObject_DebugFree.  Step through it in a 
debugger if you don't believe it <wink>.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563303&group_id=5470



From noreply@sourceforge.net  Sun Jun  2 01:11:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 01 Jun 2002 17:11:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-559429 ] __gxx_personality_v0 not found by ld
Message-ID: <E17EIy4-0001Xl-00@usw-sf-web1.sourceforge.net>

Bugs item #559429, was opened at 2002-05-22 17:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559429&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: george r. goffe (grgoffe)
Assigned to: Nobody/Anonymous (nobody)
Summary: __gxx_personality_v0 not found by ld

Initial Comment:

Howdy,

I'm building Python-2.2.1 on a solaris 2.8 system and
am having trouble. The loader can not find the above
named external reference.

I'm enclosing the build log that shows (probably) more
than you ever wanted to know but it DOES show the
problem.

Any/all help/hints/tips would be appreciated.

Regards,

George...

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

>Comment By: george r. goffe (grgoffe)
Date: 2002-06-01 17:11

Message:
Logged In: YES 
user_id=293753


Martin,

Your suggestion worked very well.

Thanks for your help.

George...


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-01 14:41

Message:
Logged In: YES 
user_id=21627

The problem is that configure fails to recognize that
linking requires g++ with g++ 3; this is fixed in
configure.in 1.319/configure 1.309.

I recommend that you do not give any --with-cxx option to
configure.

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

Comment By: george r. goffe (grgoffe)
Date: 2002-05-30 19:54

Message:
Logged In: YES 
user_id=293753

Howdy,

I'm attempting to attach the latest build log. The old
version of my gcc was 3.0.4. This version is with gcc-3.1.

Sorry about the foulup.

Regards and thanks for all your help and time.

George...



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-30 15:22

Message:
Logged In: YES 
user_id=21627

This looks like a bug in your gcc installation. Python does
not define or use a symbol of that name.

You haven't actually enclosed the build log, but I don't
think this is necessary - it's a bug of your system. If you
disagree, please report the gcc version.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-24 12:15

Message:
Logged In: NO 

Hi,

I'm looking at the same problem in the same environment.

I could fix the failed compilation by changing gcc by g++,
which means that the --with-cxx=g++ option passed to
configure did not have the expected effect.

Regards,

R. Berber


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559429&group_id=5470



From noreply@sourceforge.net  Sun Jun  2 02:25:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 01 Jun 2002 18:25:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-563148 ] built-in LIST operation has bug
Message-ID: <E17EK7g-0005bI-00@usw-sf-web2.sourceforge.net>

Bugs item #563148, was opened at 2002-06-01 01:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563148&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Tom Stanik (mytost)
Assigned to: Nobody/Anonymous (nobody)
Summary: built-in LIST operation has bug

Initial Comment:
example, to create a list of lists one can enter:

>>> d=[[0] * 4] * 5
>>> print d
[[0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 
0]]

if you want to change the first element in the first list:

>>> d[0][0]=1
>>> print d
[[1, 0, 0, 0], [1, 0, 0, 0], [1, 0, 0, 0], [1, 0, 0, 0], [1, 0, 0, 
0]] ***** INCORECT *****, all the first element changed

Alternatively, if you build the list manually:

>>> d=[0,0,0,0,0]
>>> d[0]=[0,0,0,0]
>>> d[1]=[0,0,0,0]
>>> d[2]=[0,0,0,0]
>>> d[3]=[0,0,0,0]
>>> print d
[[0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 
0]] 

changing the first element in the first list yields the 
correct result

>>> d[0][0]=1
>>> print d
[[1, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 
0]] ***** CORRECT *****

The same list depending on hows it built yields a 
different behavior

my version of python:

$ python -v
# /usr/local/lib/python2.2/site.pyc 
matches /usr/local/lib/python2.2/site.py
import site # precompiled 
from /usr/local/lib/python2.2/site.pyc
# /usr/local/lib/python2.2/os.pyc 
matches /usr/local/lib/python2.2/os.py
import os # precompiled 
from /usr/local/lib/python2.2/os.pyc
import posix # builtin
# /usr/local/lib/python2.2/posixpath.pyc 
matches /usr/local/lib/python2.2/posixpath.py
import posixpath # precompiled 
from /usr/local/lib/python2.2/posixpath.pyc
# /usr/local/lib/python2.2/stat.pyc 
matches /usr/local/lib/python2.2/stat.py
import stat # precompiled 
from /usr/local/lib/python2.2/stat.pyc
# /usr/local/lib/python2.2/UserDict.pyc 
matches /usr/local/lib/python2.2/UserDict.py
import UserDict # precompiled 
from /usr/local/lib/python2.2/UserDict.pyc
# /usr/local/lib/python2.2/copy_reg.pyc 
matches /usr/local/lib/python2.2/copy_reg.py
import copy_reg # precompiled 
from /usr/local/lib/python2.2/copy_reg.pyc
# /usr/local/lib/python2.2/types.pyc 
matches /usr/local/lib/python2.2/types.py
import types # precompiled 
from /usr/local/lib/python2.2/types.pyc
# /usr/local/lib/python2.2/__future__.pyc 
matches /usr/local/lib/python2.2/__future__.py
import __future__ # precompiled 
from /usr/local/lib/python2.2/__future__.pyc
Python 2.2.1 (#1, May 10 2002, 23:36:51) 
[GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more 
information.
dlopen("/usr/local/lib/python2.2/lib-dynload/readline.so", 
2);
import readline # dynamically loaded 
from /usr/local/lib/python2.2/lib-dynload/readline.so
>>> 




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

>Comment By: Tom Stanik (mytost)
Date: 2002-06-02 01:25

Message:
Logged In: YES 
user_id=556456


Its also documented on p.64 of "Learning Python" by 
O'Reilly.  

After submitting the bug report the problem kept bothering me 
and I had to understand what was happening.  I dug through 
the documentation and found the answer in an early chapter.  
I appoligize for not being able to withdraw the bug-report 
before you guys got to it.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-01 15:05

Message:
Logged In: YES 
user_id=33168

This is the expected behaviour.
See FAQ entry 4.50.

http://www.python.org/cgi-bin/faqw.py?req=show&file=faq04.050.htp


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

Comment By: Michael Hudson (mwh)
Date: 2002-06-01 15:03

Message:
Logged In: YES 
user_id=6656

Sigh.  This is not a bug.  You could try reading 

http://starship.python.net/crew/mwh/hacks/objectthink.html

to gain a better understanding of what's going on.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563148&group_id=5470



From noreply@sourceforge.net  Sun Jun  2 09:04:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 02 Jun 2002 01:04:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-563491 ] Add separator argument to readline()
Message-ID: <E17EQLz-0006GH-00@usw-sf-web1.sourceforge.net>

Bugs item #563491, was opened at 2002-06-02 01:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563491&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Escoto (bescoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add separator argument to readline()

Initial Comment:
This has probably been suggested previously because it
is so simple, but how about adding a second optional
argument to readline()?  If present, the second
argument would be a string (or possibly just a single
character) that marks the end of each line.  The
default is obviously '\n'. 

This scheme seems natural enough to me, and would
really help when parsing files with null terminated
lines.  There must be a lot of other uses too.



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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563491&group_id=5470



From noreply@sourceforge.net  Sun Jun  2 13:26:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 02 Jun 2002 05:26:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E17EURD-0005Vi-00@usw-sf-web2.sourceforge.net>

Bugs item #535545, was opened at 2002-03-27 03:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Martin v. Löwis (loewis)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 14:26

Message:
Logged In: YES 
user_id=21627

Whit, are you still interested in resolving this? If so, I
need to know the precise source distribution that you are
using, so I can produce patches against it.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-02 10:44

Message:
Logged In: YES 
user_id=21627

For 2.2.1, no action is needed - this is a system
configuration problem. 

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-31 22:21

Message:
Logged In: YES 
user_id=6656

Martin, what if anything do you think should be done here?

I'm leery of mucking with configure.in at this point.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 18:12

Message:
Logged In: YES 
user_id=133413

Have autoconf 2.13. Never explicitly used it though, and 
don't know the theory of it. If I patch, then invoke 
autoconf, then invoke configure ... well, that may not be 
what you mean, because it doesn't get around the problem.

If I just use your new configure file, that doesn't work 
either. Please specify the exact steps you require.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 17:35

Message:
Logged In: YES 
user_id=21627

If you have autoconf, you can just use the patch to
configure.in, and invoke 'autoconf'. In case you don't have
autoconf, I'll attach the complete configure file.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 17:30

Message:
Logged In: YES 
user_id=133413

Um ...

# patch -p1 <../conf.txt 
patching file `configure.in'
patching file `configure'
Reversed (or previously applied) patch detected!  Assume -R?
[n] 
Apply anyway? [n] y
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 1428.
2 out of 267 hunks FAILED -- saving rejects to configure.rej

If I say yes to -R, almost all hunks fail.

***************
*** 1,6 ****
  #! /bin/sh

- # From configure.in Revision: 1.288.6.3

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
--- 1,6 ----
  #! /bin/sh

+ # From configure.in Revision: 1.288.6.4

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
***************
*** 1428,1434 ****
          fi      
        case $ac_sys_system in
        AIX*)
-          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $(LINKCC)";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)
--- 1428,1434 ----
          fi      
        case $ac_sys_system in
        AIX*)
+          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $LINKCC";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)

Well, I'll try it as patched - those hunks don't look like
much is lost.

The config.log doesn't look good:

configure:2016: checking for sys/resource.h
configure:2026: gcc -E  conftest.c >/dev/null 2>conftest.out
In file included from /usr/include/sys/resource.h:25,
                 from configure:2022:
/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition
configure: failed program was:
#line 2021 "configure"
#include "confdefs.h"
#include <sys/resource.h>



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 16:58

Message:
Logged In: YES 
user_id=21627

Please try the attached conf.txt with an otherwise
unmodified system, and report whether it solves the problem.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 05:33

Message:
Logged In: YES 
user_id=133413

Probably not wisely, I tried changing the definition of
RLIM_INFINITY in bits/resource.h to match that in the kernel
header.  That took Python through the install, with make
test producing:

166 tests OK.
1 test failed:
    test_mmap
20 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl
test_imgfile
    test_largefile test_linuxaudiodev test_minidom test_nis
    test_ntpath test_pyexpat test_sax test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file
test_winreg
    test_winsound
4 skips unexpected on linux2:
    test_minidom test_linuxaudiodev test_pyexpat test_sax
make: *** [test] Error 1

As I understand all this, the definition to prefer should
probably be the one from glibc rather than the kernel (if it
even makes a difference on this value). Is this the one
which would be in effect if Python's configure were simply
to accept that resource.h is present rather than rejecting
it for this difference? 

RLIM_INFINITY btw is changed to match more recent kernels in
glibc 2.2 - but there's no rpm of that for Red Hat 6.x, and
of course building your own glibc is a good way to break a
system.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 00:03

Message:
Logged In: YES 
user_id=133413

A Google search leads me to a comment from Linus himself 
explaining that all the distributions symlinking like Red 
Hat 6.0 did are broken. I'm sure his theory is right, but 
out here in the real world, as he notes, many distros do 
that and most of us do have the idea that the current 
kernel should be built in /usr/src/linux. (Seems that rpms 
and debs of kernels put new kernel code there too - but 
I've always built kernels from tar.) 

Anyway, Linus's take is at: 
http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 23:43

Message:
Logged In: YES 
user_id=133413

You have good instincts on what to believe. I was mislead 
because rerunning configure produces a config.log without 
the warnings about resource.h. However running it in a 
freshly openned tar reproduces that warning; and even 
running it twice there (the second time, no warning) 
results in compilation failing at the same place.

So I think you have it - configure takes _any_ gcc warning 
as indicating nonexistence. And I think I see why the 
conflict comes on some systems but not on others. Red Hat 
6.0 sets /usr/include/asm as follows:

asm -> ../src/linux/include/asm/

That directory includes a "resource.h". On this box that 
happens to be code included with kernel 2.4.16, largely 
consisting of a modified definition of RLIM_INFINITY. I'd 
guess if the box still had a 2.2 kernel there would be no 
gcc warning. The whole of that file is:

#ifndef _I386_RESOURCE_H
#define _I386_RESOURCE_H

/*
 * Resource limits
 */

#define RLIMIT_CPU      0               /* CPU time in ms 
*/
#define RLIMIT_FSIZE    1               /* Maximum 
filesize */
#define RLIMIT_DATA     2               /* max data size */
#define RLIMIT_STACK    3               /* max stack size 
*/
#define RLIMIT_CORE     4               /* max core file 
size */
#define RLIMIT_RSS      5               /* max resident 
set size */
#define RLIMIT_NPROC    6               /* max number of 
processes */
#define RLIMIT_NOFILE   7               /* max number of 
open files */
#define RLIMIT_MEMLOCK  8               /* max 
locked-in-memory address space */
#define RLIMIT_AS       9               /* address space 
limit */
#define RLIMIT_LOCKS    10              /* maximum file 
locks held */

#define RLIM_NLIMITS    11

/*
 * SuS says limits have to be unsigned.
 * Which makes a ton more sense anyway.
 */
#define RLIM_INFINITY   (~0UL)

#ifdef __KERNEL__

#define INIT_RLIMITS                                    {                                                               { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {      _STK_LIM, RLIM_INFINITY },                       {             0, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {             0,             0 },                       {      INR_OPEN,     INR_OPEN  },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },               }
 
#endif /* __KERNEL__ */

#endif




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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 22:08

Message:
Logged In: YES 
user_id=21627

This is hard to believe: the spaces should have no effect.
Please consider the config.log analysis of the problem:

/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition

Apparently, configure treats these warnings as an indication
that sys/resource.h is absent. config.log also gives the
"program" it tried to compile - if your theory is correct,
changing the spaces should silence the gcc warning. Could
you please verify this theory (i.e. compiling the program

#include <sys/resource.h>

both with the original and the modified resource.h)

It appears that configure should disable warnings in gcc;
I'll try to come up with a patch.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 18:20

Message:
Logged In: YES 
user_id=133413

Think you've led me to the problem.

/usr/include/bits/resource.h has:

/* Value to indicate that there is no limit.  */
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int)(~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif

#ifdef __USE_LARGEFILE64
# define RLIM64_INFINITY 0x7fffffffffffffffLL
#endif

Removing the spaces after "#" before "define" results in 
configure correctly recognizing resource.h. Then the 
question would be: is this a shortcoming of configure, or 
are those spaces actually disabling bugs in this version 
of bits/resource.h? 


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:56

Message:
Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 17:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:02

Message:
Logged In: YES 
user_id=133413

Here it is.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 01:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 01:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 20:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 17:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 16:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470



From noreply@sourceforge.net  Sun Jun  2 13:48:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 02 Jun 2002 05:48:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-557704 ] netrc module can't handle all passwords
Message-ID: <E17EUme-0005mi-00@usw-sf-web2.sourceforge.net>

Bugs item #557704, was opened at 2002-05-18 12:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Bram Moolenaar (vimboss)
Assigned to: Nobody/Anonymous (nobody)
Summary: netrc module can't handle all passwords

Initial Comment:
When a ~/.netrc file has a password with non-word
characters parsing fails.  Since it is recommended to
use punctuation characters in passwords, this means
most netrc files can't be parsed. An example of a line
in ~/.netrc that fails:

machine piet.puk.com  	login foo 	password bar!

Additionally, entries in netrc may not have a login
name (e.g., for mail servers).  These entries should be
silently skipped. An example of a line that fails:

machine mail          password fruit

The included diff is a partial solution.  It allows all
ASCII punctuation characters to be used in passwords. 
Non-ASCII characters should probably also be allowed.

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

>Comment By: Skip Montanaro (montanaro)
Date: 2002-06-02 07:48

Message:
Logged In: YES 
user_id=44345

I think a better solution would be to not use shlex to parse netrc files.  
Netrc files aren't shells.  The whitespace is significant if it occurs inside a 
password.  I'd just use re.split(r'(\s+)') and restore the password when I 
encounterd the "password" keyword.


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-18 20:56

Message:
Logged In: YES 
user_id=80475

Expanding keyspace is generally a good idea; however, the 
significance of meta-characters is bound to bite someone in 
the behind with a hard to find error.  So, please 
reconsider single-quote, double-quote, backslash, 
greaterthan, lessthan, and pipe.

Looking at first part of the patch, consider:
- removing the TODO on line 31
- wrapping the character list in triple-quotes on line 32
- using the r'' form on line 32 to eliminate backslashes in 
the character list

Looking at the second part of the patch, I don't follow (am 
perhaps being daft) why expanding the keyspace necessitates 
changing the login logic.

The idea of allowing non-ASCII characters would be cool if 
the world had already universally accepted Latin-1 coding.  
That conflict is the reason that site.py defaults to ASCII 
encoding instead of handling non-US codings out of the box.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470



From noreply@sourceforge.net  Sun Jun  2 13:49:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 02 Jun 2002 05:49:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-557436 ] TclError is a str should be an Exception
Message-ID: <E17EUnm-0002dp-00@usw-sf-web1.sourceforge.net>

Bugs item #557436, was opened at 2002-05-17 22:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557436&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: TclError is a str should be an Exception

Initial Comment:
Since string exceptions are deprecated, it seems that
TclError (in _tkinter.c) should be changed to derive
from Exception.

It isn't apparent to me how to accomplish this.  If
someone can provide a quick high-level description, I
can make a patch.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 14:49

Message:
Logged In: YES 
user_id=21627

The patch looks good; please apply it. Also add a note in
Misc/NEWS, and send a message to python-dev or amk that this
is potentially an incompatibility.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-25 15:34

Message:
Logged In: YES 
user_id=33168

The attached patch seems to work,
but I'm not sure I'm exercising it appropriately.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-22 18:56

Message:
Logged In: YES 
user_id=21627

The official API is PyErr_NewException, where NULL as the
base class indicates to inherit from Exception.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-18 10:45

Message:
Logged In: YES 
user_id=80475

Try makeclass() in Python/exceptions.c -- the file also 
shows how all the built-in exceptions get created.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557436&group_id=5470



From noreply@sourceforge.net  Sun Jun  2 14:01:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 02 Jun 2002 06:01:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-563491 ] Add separator argument to readline()
Message-ID: <E17EUzY-00062L-00@usw-sf-web4.sourceforge.net>

Bugs item #563491, was opened at 2002-06-02 10:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563491&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Ben Escoto (bescoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add separator argument to readline()

Initial Comment:
This has probably been suggested previously because it
is so simple, but how about adding a second optional
argument to readline()?  If present, the second
argument would be a string (or possibly just a single
character) that marks the end of each line.  The
default is obviously '\n'. 

This scheme seems natural enough to me, and would
really help when parsing files with null terminated
lines.  There must be a lot of other uses too.



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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 15:01

Message:
Logged In: YES 
user_id=21627

That's not simple at all. Python uses the C library's fgets
function on some systems, which does not support this
feature, either, so you cannot implement it on top of fgets.

If you need to deal with different line end conventions on
various systems, Python 2.3 offers a Universal Newline
Support (PEP 278).

For uses beyond that, I recommend to read the entire file,
then do .split on the resulting string. This is the common
solution to your problem, and it works quite well.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563491&group_id=5470



From noreply@sourceforge.net  Sun Jun  2 14:03:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 02 Jun 2002 06:03:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-561047 ] Maximum recursion limit exceeded
Message-ID: <E17EV1V-0005yp-00@usw-sf-web2.sourceforge.net>

Bugs item #561047, was opened at 2002-05-27 07:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561047&group_id=5470

Category: Regular Expressions
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Markus Gritsch (markus_gritsch)
Assigned to: Fredrik Lundh (effbot)
Summary: Maximum recursion limit exceeded

Initial Comment:
Hi!

I think I discovered a limitation of the "new" Regular
Expression engine.  I
have put together an example which shows the behavior at
 
http://stud4.tuwien.ac.at/~e9326522/temporary/re_bug_example.zip
(69kB)

When the script is run with Python 1.5.2 by invoking
  psmergeNS.py *.ps

everything is fine and it produces a merged output file
containing both
PostScript files.

When using Python 2.x the following Exception is raised:

  Traceback (most recent call last):
    File "psmergeNS4.py", line 35, in ?
      pages = theRE.findall(contents)
  RuntimeError: maximum recursion limit exceeded

This behavior is the same with the Linux and the Win32
version of Python.

Markus



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

>Comment By: Skip Montanaro (montanaro)
Date: 2002-06-02 08:03

Message:
Logged In: YES 
user_id=44345

Saving /F the trouble of closing this, since it's a duplicate of 
<http://python.org/sf/493252> and several others.  Read the followups 
there for ways to avoid/workaround the problem.  If you absolutely can't 
modify your regular expression to be less abusive of the stack, you can 
always 

    import pre as re

and deal with the long match times you'll encounter instead.


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

Comment By: Bastian Kleineidam (calvin)
Date: 2002-05-29 07:05

Message:
Logged In: YES 
user_id=9205

I had the same problem, but only when using *? matching
several kB text.
It seems the the *? backtracking function is recursive and
cannot handle several thousand characters...

Greetings

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561047&group_id=5470



From noreply@sourceforge.net  Sun Jun  2 14:05:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 02 Jun 2002 06:05:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E17EV2k-00064k-00@usw-sf-web4.sourceforge.net>

Bugs item #535545, was opened at 2002-03-26 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Martin v. Löwis (loewis)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



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

>Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 09:05

Message:
Logged In: YES 
user_id=133413

Since the problem comes from the way Red Hat 6.0 symlinks
the kernel libraries, which then creates a conflict between
library files if a kernel is compiled from source in the old
standard location of /usr/src/linux (don't think it would
apply to installing kernels from RPM since I don't think Red
Hat ever came up with a path to upgrade 6.0 to a 2.4 kernel
without upgrading the whole distribution) ... hmm, wonder if
that's precise enough for your purposes. There are various
system components upgraded from RPM after the base 6.0
release for security concerns and so on, so if the fix
wouldn't be generic to "6.0 + custom-compiled kernel in
/usr/src/linux" then this system probably couldn't be
defined precisely enough for the purpose.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 08:26

Message:
Logged In: YES 
user_id=21627

Whit, are you still interested in resolving this? If so, I
need to know the precise source distribution that you are
using, so I can produce patches against it.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-02 03:44

Message:
Logged In: YES 
user_id=21627

For 2.2.1, no action is needed - this is a system
configuration problem. 

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-31 15:21

Message:
Logged In: YES 
user_id=6656

Martin, what if anything do you think should be done here?

I'm leery of mucking with configure.in at this point.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 12:12

Message:
Logged In: YES 
user_id=133413

Have autoconf 2.13. Never explicitly used it though, and 
don't know the theory of it. If I patch, then invoke 
autoconf, then invoke configure ... well, that may not be 
what you mean, because it doesn't get around the problem.

If I just use your new configure file, that doesn't work 
either. Please specify the exact steps you require.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 11:35

Message:
Logged In: YES 
user_id=21627

If you have autoconf, you can just use the patch to
configure.in, and invoke 'autoconf'. In case you don't have
autoconf, I'll attach the complete configure file.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 11:30

Message:
Logged In: YES 
user_id=133413

Um ...

# patch -p1 <../conf.txt 
patching file `configure.in'
patching file `configure'
Reversed (or previously applied) patch detected!  Assume -R?
[n] 
Apply anyway? [n] y
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 1428.
2 out of 267 hunks FAILED -- saving rejects to configure.rej

If I say yes to -R, almost all hunks fail.

***************
*** 1,6 ****
  #! /bin/sh

- # From configure.in Revision: 1.288.6.3

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
--- 1,6 ----
  #! /bin/sh

+ # From configure.in Revision: 1.288.6.4

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
***************
*** 1428,1434 ****
          fi      
        case $ac_sys_system in
        AIX*)
-          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $(LINKCC)";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)
--- 1428,1434 ----
          fi      
        case $ac_sys_system in
        AIX*)
+          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $LINKCC";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)

Well, I'll try it as patched - those hunks don't look like
much is lost.

The config.log doesn't look good:

configure:2016: checking for sys/resource.h
configure:2026: gcc -E  conftest.c >/dev/null 2>conftest.out
In file included from /usr/include/sys/resource.h:25,
                 from configure:2022:
/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition
configure: failed program was:
#line 2021 "configure"
#include "confdefs.h"
#include <sys/resource.h>



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 10:58

Message:
Logged In: YES 
user_id=21627

Please try the attached conf.txt with an otherwise
unmodified system, and report whether it solves the problem.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 23:33

Message:
Logged In: YES 
user_id=133413

Probably not wisely, I tried changing the definition of
RLIM_INFINITY in bits/resource.h to match that in the kernel
header.  That took Python through the install, with make
test producing:

166 tests OK.
1 test failed:
    test_mmap
20 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl
test_imgfile
    test_largefile test_linuxaudiodev test_minidom test_nis
    test_ntpath test_pyexpat test_sax test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file
test_winreg
    test_winsound
4 skips unexpected on linux2:
    test_minidom test_linuxaudiodev test_pyexpat test_sax
make: *** [test] Error 1

As I understand all this, the definition to prefer should
probably be the one from glibc rather than the kernel (if it
even makes a difference on this value). Is this the one
which would be in effect if Python's configure were simply
to accept that resource.h is present rather than rejecting
it for this difference? 

RLIM_INFINITY btw is changed to match more recent kernels in
glibc 2.2 - but there's no rpm of that for Red Hat 6.x, and
of course building your own glibc is a good way to break a
system.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 18:03

Message:
Logged In: YES 
user_id=133413

A Google search leads me to a comment from Linus himself 
explaining that all the distributions symlinking like Red 
Hat 6.0 did are broken. I'm sure his theory is right, but 
out here in the real world, as he notes, many distros do 
that and most of us do have the idea that the current 
kernel should be built in /usr/src/linux. (Seems that rpms 
and debs of kernels put new kernel code there too - but 
I've always built kernels from tar.) 

Anyway, Linus's take is at: 
http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:43

Message:
Logged In: YES 
user_id=133413

You have good instincts on what to believe. I was mislead 
because rerunning configure produces a config.log without 
the warnings about resource.h. However running it in a 
freshly openned tar reproduces that warning; and even 
running it twice there (the second time, no warning) 
results in compilation failing at the same place.

So I think you have it - configure takes _any_ gcc warning 
as indicating nonexistence. And I think I see why the 
conflict comes on some systems but not on others. Red Hat 
6.0 sets /usr/include/asm as follows:

asm -> ../src/linux/include/asm/

That directory includes a "resource.h". On this box that 
happens to be code included with kernel 2.4.16, largely 
consisting of a modified definition of RLIM_INFINITY. I'd 
guess if the box still had a 2.2 kernel there would be no 
gcc warning. The whole of that file is:

#ifndef _I386_RESOURCE_H
#define _I386_RESOURCE_H

/*
 * Resource limits
 */

#define RLIMIT_CPU      0               /* CPU time in ms 
*/
#define RLIMIT_FSIZE    1               /* Maximum 
filesize */
#define RLIMIT_DATA     2               /* max data size */
#define RLIMIT_STACK    3               /* max stack size 
*/
#define RLIMIT_CORE     4               /* max core file 
size */
#define RLIMIT_RSS      5               /* max resident 
set size */
#define RLIMIT_NPROC    6               /* max number of 
processes */
#define RLIMIT_NOFILE   7               /* max number of 
open files */
#define RLIMIT_MEMLOCK  8               /* max 
locked-in-memory address space */
#define RLIMIT_AS       9               /* address space 
limit */
#define RLIMIT_LOCKS    10              /* maximum file 
locks held */

#define RLIM_NLIMITS    11

/*
 * SuS says limits have to be unsigned.
 * Which makes a ton more sense anyway.
 */
#define RLIM_INFINITY   (~0UL)

#ifdef __KERNEL__

#define INIT_RLIMITS                                    {                                                               { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {      _STK_LIM, RLIM_INFINITY },                       {             0, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {             0,             0 },                       {      INR_OPEN,     INR_OPEN  },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },               }
 
#endif /* __KERNEL__ */

#endif




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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16:08

Message:
Logged In: YES 
user_id=21627

This is hard to believe: the spaces should have no effect.
Please consider the config.log analysis of the problem:

/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition

Apparently, configure treats these warnings as an indication
that sys/resource.h is absent. config.log also gives the
"program" it tried to compile - if your theory is correct,
changing the spaces should silence the gcc warning. Could
you please verify this theory (i.e. compiling the program

#include <sys/resource.h>

both with the original and the modified resource.h)

It appears that configure should disable warnings in gcc;
I'll try to come up with a patch.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 12:20

Message:
Logged In: YES 
user_id=133413

Think you've led me to the problem.

/usr/include/bits/resource.h has:

/* Value to indicate that there is no limit.  */
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int)(~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif

#ifdef __USE_LARGEFILE64
# define RLIM64_INFINITY 0x7fffffffffffffffLL
#endif

Removing the spaces after "#" before "define" results in 
configure correctly recognizing resource.h. Then the 
question would be: is this a shortcoming of configure, or 
are those spaces actually disabling bugs in this version 
of bits/resource.h? 


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:56

Message:
Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:02

Message:
Logged In: YES 
user_id=133413

Here it is.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 10:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 05:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 19:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 19:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 14:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 11:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 10:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 07:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470



From noreply@sourceforge.net  Sun Jun  2 14:09:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 02 Jun 2002 06:09:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-563338 ] Getting traceback in embedded python.
Message-ID: <E17EV7G-0007t9-00@usw-sf-web3.sourceforge.net>

Bugs item #563338, was opened at 2002-06-01 18:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563338&group_id=5470

Category: Documentation
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Bjorn Pettersen (bpettersen)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Getting traceback in embedded python.

Initial Comment:
It would be nice if there was an API method for getting 
the traceback as a string for use in embedded Python 
applications. Since I couldn't find any such function I 
created the following, maybe it could be added to the 
embedding docs?

class PyException : public std::exception {
  std::string msg;
public:
  PyException(const std::string& m) : msg(m) {}
  const char* what() { return msg.c_str(); }
};

std::string getTraceback() {
  std::string result;
  PyObject *exception, *v, *traceback;
  PyErr_Fetch(&exception, &v, &traceback);
  PyErr_NormalizeException(&exception, &v, 
&traceback);

  /*
    import traceback
    lst = traceback.format_exception(exception, v, 
traceback)
  */
  PyObject* tbstr = PyString_FromString("traceback");
  PyObject* tbmod = PyImport_Import(tbstr);
  if (!tbmod) 
    throw PyException("Unable to import traceback 
module. Is your Python installed?");
  PyObject* tbdict = PyModule_GetDict(tbmod);
  PyObject* formatFunc = PyDict_GetItemString
(tbdict, "format_exception");
  if (!formatFunc) 
    throw PyException("Can't find 
traceback.format_exception");
  if (!traceback) {
    traceback = Py_None;
    Py_INCREF(Py_None);
  }
  PyObject* args = Py_BuildValue("(OOO)", exception, 
v, traceback);
  PyObject* lst = PyObject_CallObject(formatFunc, 
args);

  for (int i=0; i<PyList_GET_SIZE(lst); i++) {
    result += PyString_AsString(PyList_GetItem(lst, i));
  }

  Py_DECREF(args);
  Py_DECREF(lst);
  return result;
}


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 15:09

Message:
Logged In: YES 
user_id=21627

Another approach is to use PyTraceBack_Print, passing a
file-like object of your choice (e.g. a cStringIO object).

I don't think this belongs into the embedding tutorial -
anybody who understands the API can derive code similar to
yours just from the equivalent Python code.

Instead, I recommend that you add your snippet into the
Python Cookbook, at

http://aspn.activestate.com/ASPN/Python/Cookbook/

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563338&group_id=5470



From noreply@sourceforge.net  Sun Jun  2 14:09:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 02 Jun 2002 06:09:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-563338 ] Getting traceback in embedded python.
Message-ID: <E17EV7G-000689-00@usw-sf-web4.sourceforge.net>

Bugs item #563338, was opened at 2002-06-01 18:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563338&group_id=5470

Category: Documentation
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Bjorn Pettersen (bpettersen)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Getting traceback in embedded python.

Initial Comment:
It would be nice if there was an API method for getting 
the traceback as a string for use in embedded Python 
applications. Since I couldn't find any such function I 
created the following, maybe it could be added to the 
embedding docs?

class PyException : public std::exception {
  std::string msg;
public:
  PyException(const std::string& m) : msg(m) {}
  const char* what() { return msg.c_str(); }
};

std::string getTraceback() {
  std::string result;
  PyObject *exception, *v, *traceback;
  PyErr_Fetch(&exception, &v, &traceback);
  PyErr_NormalizeException(&exception, &v, 
&traceback);

  /*
    import traceback
    lst = traceback.format_exception(exception, v, 
traceback)
  */
  PyObject* tbstr = PyString_FromString("traceback");
  PyObject* tbmod = PyImport_Import(tbstr);
  if (!tbmod) 
    throw PyException("Unable to import traceback 
module. Is your Python installed?");
  PyObject* tbdict = PyModule_GetDict(tbmod);
  PyObject* formatFunc = PyDict_GetItemString
(tbdict, "format_exception");
  if (!formatFunc) 
    throw PyException("Can't find 
traceback.format_exception");
  if (!traceback) {
    traceback = Py_None;
    Py_INCREF(Py_None);
  }
  PyObject* args = Py_BuildValue("(OOO)", exception, 
v, traceback);
  PyObject* lst = PyObject_CallObject(formatFunc, 
args);

  for (int i=0; i<PyList_GET_SIZE(lst); i++) {
    result += PyString_AsString(PyList_GetItem(lst, i));
  }

  Py_DECREF(args);
  Py_DECREF(lst);
  return result;
}


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 15:09

Message:
Logged In: YES 
user_id=21627

Another approach is to use PyTraceBack_Print, passing a
file-like object of your choice (e.g. a cStringIO object).

I don't think this belongs into the embedding tutorial -
anybody who understands the API can derive code similar to
yours just from the equivalent Python code.

Instead, I recommend that you add your snippet into the
Python Cookbook, at

http://aspn.activestate.com/ASPN/Python/Cookbook/

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 15:09

Message:
Logged In: YES 
user_id=21627

Another approach is to use PyTraceBack_Print, passing a
file-like object of your choice (e.g. a cStringIO object).

I don't think this belongs into the embedding tutorial -
anybody who understands the API can derive code similar to
yours just from the equivalent Python code.

Instead, I recommend that you add your snippet into the
Python Cookbook, at

http://aspn.activestate.com/ASPN/Python/Cookbook/

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563338&group_id=5470



From noreply@sourceforge.net  Sun Jun  2 14:19:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 02 Jun 2002 06:19:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E17EVH2-00069Q-00@usw-sf-web2.sourceforge.net>

Bugs item #535545, was opened at 2002-03-27 03:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Martin v. Löwis (loewis)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 15:19

Message:
Logged In: YES 
user_id=21627

I'm still trying to find out why you could not apply the
patch I created earlier on. I want to recreate it so that it
works for your copy of the Python source code, but for that
to work, I need to know what version the copy of your Python
source code has.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 15:05

Message:
Logged In: YES 
user_id=133413

Since the problem comes from the way Red Hat 6.0 symlinks
the kernel libraries, which then creates a conflict between
library files if a kernel is compiled from source in the old
standard location of /usr/src/linux (don't think it would
apply to installing kernels from RPM since I don't think Red
Hat ever came up with a path to upgrade 6.0 to a 2.4 kernel
without upgrading the whole distribution) ... hmm, wonder if
that's precise enough for your purposes. There are various
system components upgraded from RPM after the base 6.0
release for security concerns and so on, so if the fix
wouldn't be generic to "6.0 + custom-compiled kernel in
/usr/src/linux" then this system probably couldn't be
defined precisely enough for the purpose.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 14:26

Message:
Logged In: YES 
user_id=21627

Whit, are you still interested in resolving this? If so, I
need to know the precise source distribution that you are
using, so I can produce patches against it.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-02 10:44

Message:
Logged In: YES 
user_id=21627

For 2.2.1, no action is needed - this is a system
configuration problem. 

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-31 22:21

Message:
Logged In: YES 
user_id=6656

Martin, what if anything do you think should be done here?

I'm leery of mucking with configure.in at this point.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 18:12

Message:
Logged In: YES 
user_id=133413

Have autoconf 2.13. Never explicitly used it though, and 
don't know the theory of it. If I patch, then invoke 
autoconf, then invoke configure ... well, that may not be 
what you mean, because it doesn't get around the problem.

If I just use your new configure file, that doesn't work 
either. Please specify the exact steps you require.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 17:35

Message:
Logged In: YES 
user_id=21627

If you have autoconf, you can just use the patch to
configure.in, and invoke 'autoconf'. In case you don't have
autoconf, I'll attach the complete configure file.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 17:30

Message:
Logged In: YES 
user_id=133413

Um ...

# patch -p1 <../conf.txt 
patching file `configure.in'
patching file `configure'
Reversed (or previously applied) patch detected!  Assume -R?
[n] 
Apply anyway? [n] y
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 1428.
2 out of 267 hunks FAILED -- saving rejects to configure.rej

If I say yes to -R, almost all hunks fail.

***************
*** 1,6 ****
  #! /bin/sh

- # From configure.in Revision: 1.288.6.3

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
--- 1,6 ----
  #! /bin/sh

+ # From configure.in Revision: 1.288.6.4

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
***************
*** 1428,1434 ****
          fi      
        case $ac_sys_system in
        AIX*)
-          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $(LINKCC)";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)
--- 1428,1434 ----
          fi      
        case $ac_sys_system in
        AIX*)
+          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $LINKCC";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)

Well, I'll try it as patched - those hunks don't look like
much is lost.

The config.log doesn't look good:

configure:2016: checking for sys/resource.h
configure:2026: gcc -E  conftest.c >/dev/null 2>conftest.out
In file included from /usr/include/sys/resource.h:25,
                 from configure:2022:
/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition
configure: failed program was:
#line 2021 "configure"
#include "confdefs.h"
#include <sys/resource.h>



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 16:58

Message:
Logged In: YES 
user_id=21627

Please try the attached conf.txt with an otherwise
unmodified system, and report whether it solves the problem.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 05:33

Message:
Logged In: YES 
user_id=133413

Probably not wisely, I tried changing the definition of
RLIM_INFINITY in bits/resource.h to match that in the kernel
header.  That took Python through the install, with make
test producing:

166 tests OK.
1 test failed:
    test_mmap
20 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl
test_imgfile
    test_largefile test_linuxaudiodev test_minidom test_nis
    test_ntpath test_pyexpat test_sax test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file
test_winreg
    test_winsound
4 skips unexpected on linux2:
    test_minidom test_linuxaudiodev test_pyexpat test_sax
make: *** [test] Error 1

As I understand all this, the definition to prefer should
probably be the one from glibc rather than the kernel (if it
even makes a difference on this value). Is this the one
which would be in effect if Python's configure were simply
to accept that resource.h is present rather than rejecting
it for this difference? 

RLIM_INFINITY btw is changed to match more recent kernels in
glibc 2.2 - but there's no rpm of that for Red Hat 6.x, and
of course building your own glibc is a good way to break a
system.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 00:03

Message:
Logged In: YES 
user_id=133413

A Google search leads me to a comment from Linus himself 
explaining that all the distributions symlinking like Red 
Hat 6.0 did are broken. I'm sure his theory is right, but 
out here in the real world, as he notes, many distros do 
that and most of us do have the idea that the current 
kernel should be built in /usr/src/linux. (Seems that rpms 
and debs of kernels put new kernel code there too - but 
I've always built kernels from tar.) 

Anyway, Linus's take is at: 
http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 23:43

Message:
Logged In: YES 
user_id=133413

You have good instincts on what to believe. I was mislead 
because rerunning configure produces a config.log without 
the warnings about resource.h. However running it in a 
freshly openned tar reproduces that warning; and even 
running it twice there (the second time, no warning) 
results in compilation failing at the same place.

So I think you have it - configure takes _any_ gcc warning 
as indicating nonexistence. And I think I see why the 
conflict comes on some systems but not on others. Red Hat 
6.0 sets /usr/include/asm as follows:

asm -> ../src/linux/include/asm/

That directory includes a "resource.h". On this box that 
happens to be code included with kernel 2.4.16, largely 
consisting of a modified definition of RLIM_INFINITY. I'd 
guess if the box still had a 2.2 kernel there would be no 
gcc warning. The whole of that file is:

#ifndef _I386_RESOURCE_H
#define _I386_RESOURCE_H

/*
 * Resource limits
 */

#define RLIMIT_CPU      0               /* CPU time in ms 
*/
#define RLIMIT_FSIZE    1               /* Maximum 
filesize */
#define RLIMIT_DATA     2               /* max data size */
#define RLIMIT_STACK    3               /* max stack size 
*/
#define RLIMIT_CORE     4               /* max core file 
size */
#define RLIMIT_RSS      5               /* max resident 
set size */
#define RLIMIT_NPROC    6               /* max number of 
processes */
#define RLIMIT_NOFILE   7               /* max number of 
open files */
#define RLIMIT_MEMLOCK  8               /* max 
locked-in-memory address space */
#define RLIMIT_AS       9               /* address space 
limit */
#define RLIMIT_LOCKS    10              /* maximum file 
locks held */

#define RLIM_NLIMITS    11

/*
 * SuS says limits have to be unsigned.
 * Which makes a ton more sense anyway.
 */
#define RLIM_INFINITY   (~0UL)

#ifdef __KERNEL__

#define INIT_RLIMITS                                    {                                                               { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {      _STK_LIM, RLIM_INFINITY },                       {             0, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {             0,             0 },                       {      INR_OPEN,     INR_OPEN  },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },               }
 
#endif /* __KERNEL__ */

#endif




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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 22:08

Message:
Logged In: YES 
user_id=21627

This is hard to believe: the spaces should have no effect.
Please consider the config.log analysis of the problem:

/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition

Apparently, configure treats these warnings as an indication
that sys/resource.h is absent. config.log also gives the
"program" it tried to compile - if your theory is correct,
changing the spaces should silence the gcc warning. Could
you please verify this theory (i.e. compiling the program

#include <sys/resource.h>

both with the original and the modified resource.h)

It appears that configure should disable warnings in gcc;
I'll try to come up with a patch.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 18:20

Message:
Logged In: YES 
user_id=133413

Think you've led me to the problem.

/usr/include/bits/resource.h has:

/* Value to indicate that there is no limit.  */
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int)(~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif

#ifdef __USE_LARGEFILE64
# define RLIM64_INFINITY 0x7fffffffffffffffLL
#endif

Removing the spaces after "#" before "define" results in 
configure correctly recognizing resource.h. Then the 
question would be: is this a shortcoming of configure, or 
are those spaces actually disabling bugs in this version 
of bits/resource.h? 


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:56

Message:
Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 17:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:02

Message:
Logged In: YES 
user_id=133413

Here it is.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 01:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 01:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 20:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 17:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 16:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470



From noreply@sourceforge.net  Sun Jun  2 14:22:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 02 Jun 2002 06:22:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-563530 ] Missing operator docs
Message-ID: <E17EVJm-0006BM-00@usw-sf-web2.sourceforge.net>

Bugs item #563530, was opened at 2002-06-02 08:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563530&group_id=5470

Category: Documentation
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Missing operator docs

Initial Comment:
I see no mention of the following at 
http://www.python.org/dev/doc/devel/ref/numeric-
types.html:

__rfloordiv__
__rtruediv__
__ifloordiv__
__itruediv__


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563530&group_id=5470



From noreply@sourceforge.net  Sun Jun  2 15:18:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 02 Jun 2002 07:18:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E17EWBO-0006nh-00@usw-sf-web2.sourceforge.net>

Bugs item #535545, was opened at 2002-03-26 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Martin v. Löwis (loewis)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



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

>Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 10:18

Message:
Logged In: YES 
user_id=133413

Oh, Python version. By coincidence I just cleaned that from
the system last week, and don't remember the exact version.
Would it make sense for me to try to compile the latest
Python source, see if it fails the same way?

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 09:19

Message:
Logged In: YES 
user_id=21627

I'm still trying to find out why you could not apply the
patch I created earlier on. I want to recreate it so that it
works for your copy of the Python source code, but for that
to work, I need to know what version the copy of your Python
source code has.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 09:05

Message:
Logged In: YES 
user_id=133413

Since the problem comes from the way Red Hat 6.0 symlinks
the kernel libraries, which then creates a conflict between
library files if a kernel is compiled from source in the old
standard location of /usr/src/linux (don't think it would
apply to installing kernels from RPM since I don't think Red
Hat ever came up with a path to upgrade 6.0 to a 2.4 kernel
without upgrading the whole distribution) ... hmm, wonder if
that's precise enough for your purposes. There are various
system components upgraded from RPM after the base 6.0
release for security concerns and so on, so if the fix
wouldn't be generic to "6.0 + custom-compiled kernel in
/usr/src/linux" then this system probably couldn't be
defined precisely enough for the purpose.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 08:26

Message:
Logged In: YES 
user_id=21627

Whit, are you still interested in resolving this? If so, I
need to know the precise source distribution that you are
using, so I can produce patches against it.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-02 03:44

Message:
Logged In: YES 
user_id=21627

For 2.2.1, no action is needed - this is a system
configuration problem. 

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-31 15:21

Message:
Logged In: YES 
user_id=6656

Martin, what if anything do you think should be done here?

I'm leery of mucking with configure.in at this point.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 12:12

Message:
Logged In: YES 
user_id=133413

Have autoconf 2.13. Never explicitly used it though, and 
don't know the theory of it. If I patch, then invoke 
autoconf, then invoke configure ... well, that may not be 
what you mean, because it doesn't get around the problem.

If I just use your new configure file, that doesn't work 
either. Please specify the exact steps you require.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 11:35

Message:
Logged In: YES 
user_id=21627

If you have autoconf, you can just use the patch to
configure.in, and invoke 'autoconf'. In case you don't have
autoconf, I'll attach the complete configure file.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 11:30

Message:
Logged In: YES 
user_id=133413

Um ...

# patch -p1 <../conf.txt 
patching file `configure.in'
patching file `configure'
Reversed (or previously applied) patch detected!  Assume -R?
[n] 
Apply anyway? [n] y
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 1428.
2 out of 267 hunks FAILED -- saving rejects to configure.rej

If I say yes to -R, almost all hunks fail.

***************
*** 1,6 ****
  #! /bin/sh

- # From configure.in Revision: 1.288.6.3

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
--- 1,6 ----
  #! /bin/sh

+ # From configure.in Revision: 1.288.6.4

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
***************
*** 1428,1434 ****
          fi      
        case $ac_sys_system in
        AIX*)
-          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $(LINKCC)";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)
--- 1428,1434 ----
          fi      
        case $ac_sys_system in
        AIX*)
+          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $LINKCC";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)

Well, I'll try it as patched - those hunks don't look like
much is lost.

The config.log doesn't look good:

configure:2016: checking for sys/resource.h
configure:2026: gcc -E  conftest.c >/dev/null 2>conftest.out
In file included from /usr/include/sys/resource.h:25,
                 from configure:2022:
/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition
configure: failed program was:
#line 2021 "configure"
#include "confdefs.h"
#include <sys/resource.h>



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 10:58

Message:
Logged In: YES 
user_id=21627

Please try the attached conf.txt with an otherwise
unmodified system, and report whether it solves the problem.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 23:33

Message:
Logged In: YES 
user_id=133413

Probably not wisely, I tried changing the definition of
RLIM_INFINITY in bits/resource.h to match that in the kernel
header.  That took Python through the install, with make
test producing:

166 tests OK.
1 test failed:
    test_mmap
20 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl
test_imgfile
    test_largefile test_linuxaudiodev test_minidom test_nis
    test_ntpath test_pyexpat test_sax test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file
test_winreg
    test_winsound
4 skips unexpected on linux2:
    test_minidom test_linuxaudiodev test_pyexpat test_sax
make: *** [test] Error 1

As I understand all this, the definition to prefer should
probably be the one from glibc rather than the kernel (if it
even makes a difference on this value). Is this the one
which would be in effect if Python's configure were simply
to accept that resource.h is present rather than rejecting
it for this difference? 

RLIM_INFINITY btw is changed to match more recent kernels in
glibc 2.2 - but there's no rpm of that for Red Hat 6.x, and
of course building your own glibc is a good way to break a
system.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 18:03

Message:
Logged In: YES 
user_id=133413

A Google search leads me to a comment from Linus himself 
explaining that all the distributions symlinking like Red 
Hat 6.0 did are broken. I'm sure his theory is right, but 
out here in the real world, as he notes, many distros do 
that and most of us do have the idea that the current 
kernel should be built in /usr/src/linux. (Seems that rpms 
and debs of kernels put new kernel code there too - but 
I've always built kernels from tar.) 

Anyway, Linus's take is at: 
http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:43

Message:
Logged In: YES 
user_id=133413

You have good instincts on what to believe. I was mislead 
because rerunning configure produces a config.log without 
the warnings about resource.h. However running it in a 
freshly openned tar reproduces that warning; and even 
running it twice there (the second time, no warning) 
results in compilation failing at the same place.

So I think you have it - configure takes _any_ gcc warning 
as indicating nonexistence. And I think I see why the 
conflict comes on some systems but not on others. Red Hat 
6.0 sets /usr/include/asm as follows:

asm -> ../src/linux/include/asm/

That directory includes a "resource.h". On this box that 
happens to be code included with kernel 2.4.16, largely 
consisting of a modified definition of RLIM_INFINITY. I'd 
guess if the box still had a 2.2 kernel there would be no 
gcc warning. The whole of that file is:

#ifndef _I386_RESOURCE_H
#define _I386_RESOURCE_H

/*
 * Resource limits
 */

#define RLIMIT_CPU      0               /* CPU time in ms 
*/
#define RLIMIT_FSIZE    1               /* Maximum 
filesize */
#define RLIMIT_DATA     2               /* max data size */
#define RLIMIT_STACK    3               /* max stack size 
*/
#define RLIMIT_CORE     4               /* max core file 
size */
#define RLIMIT_RSS      5               /* max resident 
set size */
#define RLIMIT_NPROC    6               /* max number of 
processes */
#define RLIMIT_NOFILE   7               /* max number of 
open files */
#define RLIMIT_MEMLOCK  8               /* max 
locked-in-memory address space */
#define RLIMIT_AS       9               /* address space 
limit */
#define RLIMIT_LOCKS    10              /* maximum file 
locks held */

#define RLIM_NLIMITS    11

/*
 * SuS says limits have to be unsigned.
 * Which makes a ton more sense anyway.
 */
#define RLIM_INFINITY   (~0UL)

#ifdef __KERNEL__

#define INIT_RLIMITS                                    {                                                               { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {      _STK_LIM, RLIM_INFINITY },                       {             0, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {             0,             0 },                       {      INR_OPEN,     INR_OPEN  },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },               }
 
#endif /* __KERNEL__ */

#endif




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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16:08

Message:
Logged In: YES 
user_id=21627

This is hard to believe: the spaces should have no effect.
Please consider the config.log analysis of the problem:

/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition

Apparently, configure treats these warnings as an indication
that sys/resource.h is absent. config.log also gives the
"program" it tried to compile - if your theory is correct,
changing the spaces should silence the gcc warning. Could
you please verify this theory (i.e. compiling the program

#include <sys/resource.h>

both with the original and the modified resource.h)

It appears that configure should disable warnings in gcc;
I'll try to come up with a patch.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 12:20

Message:
Logged In: YES 
user_id=133413

Think you've led me to the problem.

/usr/include/bits/resource.h has:

/* Value to indicate that there is no limit.  */
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int)(~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif

#ifdef __USE_LARGEFILE64
# define RLIM64_INFINITY 0x7fffffffffffffffLL
#endif

Removing the spaces after "#" before "define" results in 
configure correctly recognizing resource.h. Then the 
question would be: is this a shortcoming of configure, or 
are those spaces actually disabling bugs in this version 
of bits/resource.h? 


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:56

Message:
Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:02

Message:
Logged In: YES 
user_id=133413

Here it is.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 10:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 05:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 19:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 19:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 14:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 11:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 10:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 07:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470



From noreply@sourceforge.net  Sun Jun  2 16:12:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 02 Jun 2002 08:12:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E17EX2J-0007SQ-00@usw-sf-web4.sourceforge.net>

Bugs item #535545, was opened at 2002-03-27 03:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Martin v. Löwis (loewis)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 17:12

Message:
Logged In: YES 
user_id=21627

Yes, please: start with a clean 2.2.1 tree. I have
regenerated the configure for 2.2.1, and attached to this
report.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 16:18

Message:
Logged In: YES 
user_id=133413

Oh, Python version. By coincidence I just cleaned that from
the system last week, and don't remember the exact version.
Would it make sense for me to try to compile the latest
Python source, see if it fails the same way?

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 15:19

Message:
Logged In: YES 
user_id=21627

I'm still trying to find out why you could not apply the
patch I created earlier on. I want to recreate it so that it
works for your copy of the Python source code, but for that
to work, I need to know what version the copy of your Python
source code has.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 15:05

Message:
Logged In: YES 
user_id=133413

Since the problem comes from the way Red Hat 6.0 symlinks
the kernel libraries, which then creates a conflict between
library files if a kernel is compiled from source in the old
standard location of /usr/src/linux (don't think it would
apply to installing kernels from RPM since I don't think Red
Hat ever came up with a path to upgrade 6.0 to a 2.4 kernel
without upgrading the whole distribution) ... hmm, wonder if
that's precise enough for your purposes. There are various
system components upgraded from RPM after the base 6.0
release for security concerns and so on, so if the fix
wouldn't be generic to "6.0 + custom-compiled kernel in
/usr/src/linux" then this system probably couldn't be
defined precisely enough for the purpose.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 14:26

Message:
Logged In: YES 
user_id=21627

Whit, are you still interested in resolving this? If so, I
need to know the precise source distribution that you are
using, so I can produce patches against it.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-02 10:44

Message:
Logged In: YES 
user_id=21627

For 2.2.1, no action is needed - this is a system
configuration problem. 

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-31 22:21

Message:
Logged In: YES 
user_id=6656

Martin, what if anything do you think should be done here?

I'm leery of mucking with configure.in at this point.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 18:12

Message:
Logged In: YES 
user_id=133413

Have autoconf 2.13. Never explicitly used it though, and 
don't know the theory of it. If I patch, then invoke 
autoconf, then invoke configure ... well, that may not be 
what you mean, because it doesn't get around the problem.

If I just use your new configure file, that doesn't work 
either. Please specify the exact steps you require.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 17:35

Message:
Logged In: YES 
user_id=21627

If you have autoconf, you can just use the patch to
configure.in, and invoke 'autoconf'. In case you don't have
autoconf, I'll attach the complete configure file.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 17:30

Message:
Logged In: YES 
user_id=133413

Um ...

# patch -p1 <../conf.txt 
patching file `configure.in'
patching file `configure'
Reversed (or previously applied) patch detected!  Assume -R?
[n] 
Apply anyway? [n] y
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 1428.
2 out of 267 hunks FAILED -- saving rejects to configure.rej

If I say yes to -R, almost all hunks fail.

***************
*** 1,6 ****
  #! /bin/sh

- # From configure.in Revision: 1.288.6.3

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
--- 1,6 ----
  #! /bin/sh

+ # From configure.in Revision: 1.288.6.4

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
***************
*** 1428,1434 ****
          fi      
        case $ac_sys_system in
        AIX*)
-          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $(LINKCC)";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)
--- 1428,1434 ----
          fi      
        case $ac_sys_system in
        AIX*)
+          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $LINKCC";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)

Well, I'll try it as patched - those hunks don't look like
much is lost.

The config.log doesn't look good:

configure:2016: checking for sys/resource.h
configure:2026: gcc -E  conftest.c >/dev/null 2>conftest.out
In file included from /usr/include/sys/resource.h:25,
                 from configure:2022:
/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition
configure: failed program was:
#line 2021 "configure"
#include "confdefs.h"
#include <sys/resource.h>



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 16:58

Message:
Logged In: YES 
user_id=21627

Please try the attached conf.txt with an otherwise
unmodified system, and report whether it solves the problem.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 05:33

Message:
Logged In: YES 
user_id=133413

Probably not wisely, I tried changing the definition of
RLIM_INFINITY in bits/resource.h to match that in the kernel
header.  That took Python through the install, with make
test producing:

166 tests OK.
1 test failed:
    test_mmap
20 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl
test_imgfile
    test_largefile test_linuxaudiodev test_minidom test_nis
    test_ntpath test_pyexpat test_sax test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file
test_winreg
    test_winsound
4 skips unexpected on linux2:
    test_minidom test_linuxaudiodev test_pyexpat test_sax
make: *** [test] Error 1

As I understand all this, the definition to prefer should
probably be the one from glibc rather than the kernel (if it
even makes a difference on this value). Is this the one
which would be in effect if Python's configure were simply
to accept that resource.h is present rather than rejecting
it for this difference? 

RLIM_INFINITY btw is changed to match more recent kernels in
glibc 2.2 - but there's no rpm of that for Red Hat 6.x, and
of course building your own glibc is a good way to break a
system.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 00:03

Message:
Logged In: YES 
user_id=133413

A Google search leads me to a comment from Linus himself 
explaining that all the distributions symlinking like Red 
Hat 6.0 did are broken. I'm sure his theory is right, but 
out here in the real world, as he notes, many distros do 
that and most of us do have the idea that the current 
kernel should be built in /usr/src/linux. (Seems that rpms 
and debs of kernels put new kernel code there too - but 
I've always built kernels from tar.) 

Anyway, Linus's take is at: 
http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 23:43

Message:
Logged In: YES 
user_id=133413

You have good instincts on what to believe. I was mislead 
because rerunning configure produces a config.log without 
the warnings about resource.h. However running it in a 
freshly openned tar reproduces that warning; and even 
running it twice there (the second time, no warning) 
results in compilation failing at the same place.

So I think you have it - configure takes _any_ gcc warning 
as indicating nonexistence. And I think I see why the 
conflict comes on some systems but not on others. Red Hat 
6.0 sets /usr/include/asm as follows:

asm -> ../src/linux/include/asm/

That directory includes a "resource.h". On this box that 
happens to be code included with kernel 2.4.16, largely 
consisting of a modified definition of RLIM_INFINITY. I'd 
guess if the box still had a 2.2 kernel there would be no 
gcc warning. The whole of that file is:

#ifndef _I386_RESOURCE_H
#define _I386_RESOURCE_H

/*
 * Resource limits
 */

#define RLIMIT_CPU      0               /* CPU time in ms 
*/
#define RLIMIT_FSIZE    1               /* Maximum 
filesize */
#define RLIMIT_DATA     2               /* max data size */
#define RLIMIT_STACK    3               /* max stack size 
*/
#define RLIMIT_CORE     4               /* max core file 
size */
#define RLIMIT_RSS      5               /* max resident 
set size */
#define RLIMIT_NPROC    6               /* max number of 
processes */
#define RLIMIT_NOFILE   7               /* max number of 
open files */
#define RLIMIT_MEMLOCK  8               /* max 
locked-in-memory address space */
#define RLIMIT_AS       9               /* address space 
limit */
#define RLIMIT_LOCKS    10              /* maximum file 
locks held */

#define RLIM_NLIMITS    11

/*
 * SuS says limits have to be unsigned.
 * Which makes a ton more sense anyway.
 */
#define RLIM_INFINITY   (~0UL)

#ifdef __KERNEL__

#define INIT_RLIMITS                                    {                                                               { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {      _STK_LIM, RLIM_INFINITY },                       {             0, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {             0,             0 },                       {      INR_OPEN,     INR_OPEN  },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },               }
 
#endif /* __KERNEL__ */

#endif




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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 22:08

Message:
Logged In: YES 
user_id=21627

This is hard to believe: the spaces should have no effect.
Please consider the config.log analysis of the problem:

/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition

Apparently, configure treats these warnings as an indication
that sys/resource.h is absent. config.log also gives the
"program" it tried to compile - if your theory is correct,
changing the spaces should silence the gcc warning. Could
you please verify this theory (i.e. compiling the program

#include <sys/resource.h>

both with the original and the modified resource.h)

It appears that configure should disable warnings in gcc;
I'll try to come up with a patch.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 18:20

Message:
Logged In: YES 
user_id=133413

Think you've led me to the problem.

/usr/include/bits/resource.h has:

/* Value to indicate that there is no limit.  */
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int)(~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif

#ifdef __USE_LARGEFILE64
# define RLIM64_INFINITY 0x7fffffffffffffffLL
#endif

Removing the spaces after "#" before "define" results in 
configure correctly recognizing resource.h. Then the 
question would be: is this a shortcoming of configure, or 
are those spaces actually disabling bugs in this version 
of bits/resource.h? 


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:56

Message:
Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 17:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:02

Message:
Logged In: YES 
user_id=133413

Here it is.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 01:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 01:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 20:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 17:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 16:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470



From noreply@sourceforge.net  Sun Jun  2 17:53:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 02 Jun 2002 09:53:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E17EYbd-0005CT-00@usw-sf-web1.sourceforge.net>

Bugs item #535545, was opened at 2002-03-26 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Martin v. Löwis (loewis)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



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

>Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 12:53

Message:
Logged In: YES 
user_id=133413

Works! The standard configure in 2.2.1 comments out
HAVE_SYS_RESOURCE_H, whereas your new configure file on a
clean tree does not. Am testing compile now, but don't
anticipate a problem - will let you know if one kicks up.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 11:12

Message:
Logged In: YES 
user_id=21627

Yes, please: start with a clean 2.2.1 tree. I have
regenerated the configure for 2.2.1, and attached to this
report.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 10:18

Message:
Logged In: YES 
user_id=133413

Oh, Python version. By coincidence I just cleaned that from
the system last week, and don't remember the exact version.
Would it make sense for me to try to compile the latest
Python source, see if it fails the same way?

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 09:19

Message:
Logged In: YES 
user_id=21627

I'm still trying to find out why you could not apply the
patch I created earlier on. I want to recreate it so that it
works for your copy of the Python source code, but for that
to work, I need to know what version the copy of your Python
source code has.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 09:05

Message:
Logged In: YES 
user_id=133413

Since the problem comes from the way Red Hat 6.0 symlinks
the kernel libraries, which then creates a conflict between
library files if a kernel is compiled from source in the old
standard location of /usr/src/linux (don't think it would
apply to installing kernels from RPM since I don't think Red
Hat ever came up with a path to upgrade 6.0 to a 2.4 kernel
without upgrading the whole distribution) ... hmm, wonder if
that's precise enough for your purposes. There are various
system components upgraded from RPM after the base 6.0
release for security concerns and so on, so if the fix
wouldn't be generic to "6.0 + custom-compiled kernel in
/usr/src/linux" then this system probably couldn't be
defined precisely enough for the purpose.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 08:26

Message:
Logged In: YES 
user_id=21627

Whit, are you still interested in resolving this? If so, I
need to know the precise source distribution that you are
using, so I can produce patches against it.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-02 03:44

Message:
Logged In: YES 
user_id=21627

For 2.2.1, no action is needed - this is a system
configuration problem. 

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-31 15:21

Message:
Logged In: YES 
user_id=6656

Martin, what if anything do you think should be done here?

I'm leery of mucking with configure.in at this point.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 12:12

Message:
Logged In: YES 
user_id=133413

Have autoconf 2.13. Never explicitly used it though, and 
don't know the theory of it. If I patch, then invoke 
autoconf, then invoke configure ... well, that may not be 
what you mean, because it doesn't get around the problem.

If I just use your new configure file, that doesn't work 
either. Please specify the exact steps you require.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 11:35

Message:
Logged In: YES 
user_id=21627

If you have autoconf, you can just use the patch to
configure.in, and invoke 'autoconf'. In case you don't have
autoconf, I'll attach the complete configure file.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 11:30

Message:
Logged In: YES 
user_id=133413

Um ...

# patch -p1 <../conf.txt 
patching file `configure.in'
patching file `configure'
Reversed (or previously applied) patch detected!  Assume -R?
[n] 
Apply anyway? [n] y
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 1428.
2 out of 267 hunks FAILED -- saving rejects to configure.rej

If I say yes to -R, almost all hunks fail.

***************
*** 1,6 ****
  #! /bin/sh

- # From configure.in Revision: 1.288.6.3

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
--- 1,6 ----
  #! /bin/sh

+ # From configure.in Revision: 1.288.6.4

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
***************
*** 1428,1434 ****
          fi      
        case $ac_sys_system in
        AIX*)
-          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $(LINKCC)";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)
--- 1428,1434 ----
          fi      
        case $ac_sys_system in
        AIX*)
+          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $LINKCC";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)

Well, I'll try it as patched - those hunks don't look like
much is lost.

The config.log doesn't look good:

configure:2016: checking for sys/resource.h
configure:2026: gcc -E  conftest.c >/dev/null 2>conftest.out
In file included from /usr/include/sys/resource.h:25,
                 from configure:2022:
/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition
configure: failed program was:
#line 2021 "configure"
#include "confdefs.h"
#include <sys/resource.h>



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 10:58

Message:
Logged In: YES 
user_id=21627

Please try the attached conf.txt with an otherwise
unmodified system, and report whether it solves the problem.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 23:33

Message:
Logged In: YES 
user_id=133413

Probably not wisely, I tried changing the definition of
RLIM_INFINITY in bits/resource.h to match that in the kernel
header.  That took Python through the install, with make
test producing:

166 tests OK.
1 test failed:
    test_mmap
20 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl
test_imgfile
    test_largefile test_linuxaudiodev test_minidom test_nis
    test_ntpath test_pyexpat test_sax test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file
test_winreg
    test_winsound
4 skips unexpected on linux2:
    test_minidom test_linuxaudiodev test_pyexpat test_sax
make: *** [test] Error 1

As I understand all this, the definition to prefer should
probably be the one from glibc rather than the kernel (if it
even makes a difference on this value). Is this the one
which would be in effect if Python's configure were simply
to accept that resource.h is present rather than rejecting
it for this difference? 

RLIM_INFINITY btw is changed to match more recent kernels in
glibc 2.2 - but there's no rpm of that for Red Hat 6.x, and
of course building your own glibc is a good way to break a
system.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 18:03

Message:
Logged In: YES 
user_id=133413

A Google search leads me to a comment from Linus himself 
explaining that all the distributions symlinking like Red 
Hat 6.0 did are broken. I'm sure his theory is right, but 
out here in the real world, as he notes, many distros do 
that and most of us do have the idea that the current 
kernel should be built in /usr/src/linux. (Seems that rpms 
and debs of kernels put new kernel code there too - but 
I've always built kernels from tar.) 

Anyway, Linus's take is at: 
http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:43

Message:
Logged In: YES 
user_id=133413

You have good instincts on what to believe. I was mislead 
because rerunning configure produces a config.log without 
the warnings about resource.h. However running it in a 
freshly openned tar reproduces that warning; and even 
running it twice there (the second time, no warning) 
results in compilation failing at the same place.

So I think you have it - configure takes _any_ gcc warning 
as indicating nonexistence. And I think I see why the 
conflict comes on some systems but not on others. Red Hat 
6.0 sets /usr/include/asm as follows:

asm -> ../src/linux/include/asm/

That directory includes a "resource.h". On this box that 
happens to be code included with kernel 2.4.16, largely 
consisting of a modified definition of RLIM_INFINITY. I'd 
guess if the box still had a 2.2 kernel there would be no 
gcc warning. The whole of that file is:

#ifndef _I386_RESOURCE_H
#define _I386_RESOURCE_H

/*
 * Resource limits
 */

#define RLIMIT_CPU      0               /* CPU time in ms 
*/
#define RLIMIT_FSIZE    1               /* Maximum 
filesize */
#define RLIMIT_DATA     2               /* max data size */
#define RLIMIT_STACK    3               /* max stack size 
*/
#define RLIMIT_CORE     4               /* max core file 
size */
#define RLIMIT_RSS      5               /* max resident 
set size */
#define RLIMIT_NPROC    6               /* max number of 
processes */
#define RLIMIT_NOFILE   7               /* max number of 
open files */
#define RLIMIT_MEMLOCK  8               /* max 
locked-in-memory address space */
#define RLIMIT_AS       9               /* address space 
limit */
#define RLIMIT_LOCKS    10              /* maximum file 
locks held */

#define RLIM_NLIMITS    11

/*
 * SuS says limits have to be unsigned.
 * Which makes a ton more sense anyway.
 */
#define RLIM_INFINITY   (~0UL)

#ifdef __KERNEL__

#define INIT_RLIMITS                                    {                                                               { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {      _STK_LIM, RLIM_INFINITY },                       {             0, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {             0,             0 },                       {      INR_OPEN,     INR_OPEN  },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },               }
 
#endif /* __KERNEL__ */

#endif




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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16:08

Message:
Logged In: YES 
user_id=21627

This is hard to believe: the spaces should have no effect.
Please consider the config.log analysis of the problem:

/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition

Apparently, configure treats these warnings as an indication
that sys/resource.h is absent. config.log also gives the
"program" it tried to compile - if your theory is correct,
changing the spaces should silence the gcc warning. Could
you please verify this theory (i.e. compiling the program

#include <sys/resource.h>

both with the original and the modified resource.h)

It appears that configure should disable warnings in gcc;
I'll try to come up with a patch.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 12:20

Message:
Logged In: YES 
user_id=133413

Think you've led me to the problem.

/usr/include/bits/resource.h has:

/* Value to indicate that there is no limit.  */
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int)(~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif

#ifdef __USE_LARGEFILE64
# define RLIM64_INFINITY 0x7fffffffffffffffLL
#endif

Removing the spaces after "#" before "define" results in 
configure correctly recognizing resource.h. Then the 
question would be: is this a shortcoming of configure, or 
are those spaces actually disabling bugs in this version 
of bits/resource.h? 


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:56

Message:
Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:02

Message:
Logged In: YES 
user_id=133413

Here it is.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 10:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 05:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 19:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 19:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 14:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 11:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 10:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 07:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470



From noreply@sourceforge.net  Sun Jun  2 18:06:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 02 Jun 2002 10:06:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E17EYnz-0001rw-00@usw-sf-web3.sourceforge.net>

Bugs item #535545, was opened at 2002-03-26 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Martin v. Löwis (loewis)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



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

>Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 13:06

Message:
Logged In: YES 
user_id=133413

Yargh! Well, at least it gets to a _different_ problem
before compilation fails:

gcc  -Xlinker -export-dynamic -o python \
                Modules/python.o \
                libpython2.2.a -ldl  -lpthread -lutil   -lm  
case $MAKEFLAGS in \
*-s*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3
-Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; \
*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3
-Wall -Wstrict-prototypes' ./python -E ./setup.py build;; \
esac
make: *** [sharedmods] Error 139

Curiously, I believe what I had before was 2.2.1rc ... um, 1
I think. And it compiled fine once the one line in
pyconfig.h was corrected by hand. Is this another bug report
I should submit?


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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 12:53

Message:
Logged In: YES 
user_id=133413

Works! The standard configure in 2.2.1 comments out
HAVE_SYS_RESOURCE_H, whereas your new configure file on a
clean tree does not. Am testing compile now, but don't
anticipate a problem - will let you know if one kicks up.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 11:12

Message:
Logged In: YES 
user_id=21627

Yes, please: start with a clean 2.2.1 tree. I have
regenerated the configure for 2.2.1, and attached to this
report.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 10:18

Message:
Logged In: YES 
user_id=133413

Oh, Python version. By coincidence I just cleaned that from
the system last week, and don't remember the exact version.
Would it make sense for me to try to compile the latest
Python source, see if it fails the same way?

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 09:19

Message:
Logged In: YES 
user_id=21627

I'm still trying to find out why you could not apply the
patch I created earlier on. I want to recreate it so that it
works for your copy of the Python source code, but for that
to work, I need to know what version the copy of your Python
source code has.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 09:05

Message:
Logged In: YES 
user_id=133413

Since the problem comes from the way Red Hat 6.0 symlinks
the kernel libraries, which then creates a conflict between
library files if a kernel is compiled from source in the old
standard location of /usr/src/linux (don't think it would
apply to installing kernels from RPM since I don't think Red
Hat ever came up with a path to upgrade 6.0 to a 2.4 kernel
without upgrading the whole distribution) ... hmm, wonder if
that's precise enough for your purposes. There are various
system components upgraded from RPM after the base 6.0
release for security concerns and so on, so if the fix
wouldn't be generic to "6.0 + custom-compiled kernel in
/usr/src/linux" then this system probably couldn't be
defined precisely enough for the purpose.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 08:26

Message:
Logged In: YES 
user_id=21627

Whit, are you still interested in resolving this? If so, I
need to know the precise source distribution that you are
using, so I can produce patches against it.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-02 03:44

Message:
Logged In: YES 
user_id=21627

For 2.2.1, no action is needed - this is a system
configuration problem. 

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-31 15:21

Message:
Logged In: YES 
user_id=6656

Martin, what if anything do you think should be done here?

I'm leery of mucking with configure.in at this point.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 12:12

Message:
Logged In: YES 
user_id=133413

Have autoconf 2.13. Never explicitly used it though, and 
don't know the theory of it. If I patch, then invoke 
autoconf, then invoke configure ... well, that may not be 
what you mean, because it doesn't get around the problem.

If I just use your new configure file, that doesn't work 
either. Please specify the exact steps you require.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 11:35

Message:
Logged In: YES 
user_id=21627

If you have autoconf, you can just use the patch to
configure.in, and invoke 'autoconf'. In case you don't have
autoconf, I'll attach the complete configure file.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 11:30

Message:
Logged In: YES 
user_id=133413

Um ...

# patch -p1 <../conf.txt 
patching file `configure.in'
patching file `configure'
Reversed (or previously applied) patch detected!  Assume -R?
[n] 
Apply anyway? [n] y
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 1428.
2 out of 267 hunks FAILED -- saving rejects to configure.rej

If I say yes to -R, almost all hunks fail.

***************
*** 1,6 ****
  #! /bin/sh

- # From configure.in Revision: 1.288.6.3

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
--- 1,6 ----
  #! /bin/sh

+ # From configure.in Revision: 1.288.6.4

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
***************
*** 1428,1434 ****
          fi      
        case $ac_sys_system in
        AIX*)
-          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $(LINKCC)";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)
--- 1428,1434 ----
          fi      
        case $ac_sys_system in
        AIX*)
+          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $LINKCC";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)

Well, I'll try it as patched - those hunks don't look like
much is lost.

The config.log doesn't look good:

configure:2016: checking for sys/resource.h
configure:2026: gcc -E  conftest.c >/dev/null 2>conftest.out
In file included from /usr/include/sys/resource.h:25,
                 from configure:2022:
/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition
configure: failed program was:
#line 2021 "configure"
#include "confdefs.h"
#include <sys/resource.h>



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 10:58

Message:
Logged In: YES 
user_id=21627

Please try the attached conf.txt with an otherwise
unmodified system, and report whether it solves the problem.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 23:33

Message:
Logged In: YES 
user_id=133413

Probably not wisely, I tried changing the definition of
RLIM_INFINITY in bits/resource.h to match that in the kernel
header.  That took Python through the install, with make
test producing:

166 tests OK.
1 test failed:
    test_mmap
20 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl
test_imgfile
    test_largefile test_linuxaudiodev test_minidom test_nis
    test_ntpath test_pyexpat test_sax test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file
test_winreg
    test_winsound
4 skips unexpected on linux2:
    test_minidom test_linuxaudiodev test_pyexpat test_sax
make: *** [test] Error 1

As I understand all this, the definition to prefer should
probably be the one from glibc rather than the kernel (if it
even makes a difference on this value). Is this the one
which would be in effect if Python's configure were simply
to accept that resource.h is present rather than rejecting
it for this difference? 

RLIM_INFINITY btw is changed to match more recent kernels in
glibc 2.2 - but there's no rpm of that for Red Hat 6.x, and
of course building your own glibc is a good way to break a
system.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 18:03

Message:
Logged In: YES 
user_id=133413

A Google search leads me to a comment from Linus himself 
explaining that all the distributions symlinking like Red 
Hat 6.0 did are broken. I'm sure his theory is right, but 
out here in the real world, as he notes, many distros do 
that and most of us do have the idea that the current 
kernel should be built in /usr/src/linux. (Seems that rpms 
and debs of kernels put new kernel code there too - but 
I've always built kernels from tar.) 

Anyway, Linus's take is at: 
http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:43

Message:
Logged In: YES 
user_id=133413

You have good instincts on what to believe. I was mislead 
because rerunning configure produces a config.log without 
the warnings about resource.h. However running it in a 
freshly openned tar reproduces that warning; and even 
running it twice there (the second time, no warning) 
results in compilation failing at the same place.

So I think you have it - configure takes _any_ gcc warning 
as indicating nonexistence. And I think I see why the 
conflict comes on some systems but not on others. Red Hat 
6.0 sets /usr/include/asm as follows:

asm -> ../src/linux/include/asm/

That directory includes a "resource.h". On this box that 
happens to be code included with kernel 2.4.16, largely 
consisting of a modified definition of RLIM_INFINITY. I'd 
guess if the box still had a 2.2 kernel there would be no 
gcc warning. The whole of that file is:

#ifndef _I386_RESOURCE_H
#define _I386_RESOURCE_H

/*
 * Resource limits
 */

#define RLIMIT_CPU      0               /* CPU time in ms 
*/
#define RLIMIT_FSIZE    1               /* Maximum 
filesize */
#define RLIMIT_DATA     2               /* max data size */
#define RLIMIT_STACK    3               /* max stack size 
*/
#define RLIMIT_CORE     4               /* max core file 
size */
#define RLIMIT_RSS      5               /* max resident 
set size */
#define RLIMIT_NPROC    6               /* max number of 
processes */
#define RLIMIT_NOFILE   7               /* max number of 
open files */
#define RLIMIT_MEMLOCK  8               /* max 
locked-in-memory address space */
#define RLIMIT_AS       9               /* address space 
limit */
#define RLIMIT_LOCKS    10              /* maximum file 
locks held */

#define RLIM_NLIMITS    11

/*
 * SuS says limits have to be unsigned.
 * Which makes a ton more sense anyway.
 */
#define RLIM_INFINITY   (~0UL)

#ifdef __KERNEL__

#define INIT_RLIMITS                                    {                                                               { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {      _STK_LIM, RLIM_INFINITY },                       {             0, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {             0,             0 },                       {      INR_OPEN,     INR_OPEN  },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },               }
 
#endif /* __KERNEL__ */

#endif




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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16:08

Message:
Logged In: YES 
user_id=21627

This is hard to believe: the spaces should have no effect.
Please consider the config.log analysis of the problem:

/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition

Apparently, configure treats these warnings as an indication
that sys/resource.h is absent. config.log also gives the
"program" it tried to compile - if your theory is correct,
changing the spaces should silence the gcc warning. Could
you please verify this theory (i.e. compiling the program

#include <sys/resource.h>

both with the original and the modified resource.h)

It appears that configure should disable warnings in gcc;
I'll try to come up with a patch.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 12:20

Message:
Logged In: YES 
user_id=133413

Think you've led me to the problem.

/usr/include/bits/resource.h has:

/* Value to indicate that there is no limit.  */
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int)(~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif

#ifdef __USE_LARGEFILE64
# define RLIM64_INFINITY 0x7fffffffffffffffLL
#endif

Removing the spaces after "#" before "define" results in 
configure correctly recognizing resource.h. Then the 
question would be: is this a shortcoming of configure, or 
are those spaces actually disabling bugs in this version 
of bits/resource.h? 


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:56

Message:
Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:02

Message:
Logged In: YES 
user_id=133413

Here it is.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 10:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 05:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 19:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 19:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 14:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 11:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 10:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 07:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470



From noreply@sourceforge.net  Sun Jun  2 18:16:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 02 Jun 2002 10:16:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-555360 ] UTF-16 BOM handling counterintuitive
Message-ID: <E17EYy3-0000IT-00@usw-sf-web4.sourceforge.net>

Bugs item #555360, was opened at 2002-05-13 09:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
>Priority: 3
Submitted By: Stephen J. Turnbull (yaseppochi)
Assigned to: M.-A. Lemburg (lemburg)
Summary: UTF-16 BOM handling counterintuitive

Initial Comment:
A search on "Unicode BOM" doesn't turn up anything related.

Sorry, I don't have a 2.2 or CVS to hand.  Easy enough
to replicate, anyway.  The UTF-16 codec happily
corrupts files by appending a BOM before writing
encoded text to the file:

bash-2.05a$ python
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import codecs
>>> f = codecs.open("/tmp/utf16","w","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = codecs.open("/tmp/utf16","a","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = open("/tmp/utf16","r") 
>>> f.read()
'\xff\xfea\x00\xff\xfea\x00'

Oops.

Also, dir(codecs) shows BOM64* constants are defined
(to what purpose, I have no idea---Microsoft Word files
on Alpha, maybe?), but no BOM8, which actually has some
basis in the standards.  (I think the idea of a UTF-8
signature is a abomination, so you can leave it
out<wink>, but people who do use the BOM as signature
in UTF-8 files would find it useful.)  Hmm ...

>>> codecs.BOM_BE
'\xfe\xff'
>>> codecs.BOM64_BE
'\x00\x00\xfe\xff'
>>> codecs.BOM32_BE
'\xfe\xff'
>>> 

Urk!  I only count 32 bits in BOM64 and 16 bits in
BOM32!  Maybe BOM32_* was intended as an alias for
BOM_*, and BOM64_* was a continuation of the typo, as
it were?

I wonder if this is the right interface, actually. 
Wouldn't prefixBOM() and checkBOM() methods for streams
and strings make more sense?  prefixBOM should be
idempotent, and checkBOM would return either a codec
(with size and endianness determined) or a codec.BOM*
constant.

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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-02 17:16

Message:
Logged In: YES 
user_id=38388

I agree that opening a file in append mode should 
probably be smarter in the sense that the BOM is
only written in case file.seek() points to the beginning
of the file; patches are welcome.

On the other points:
* I don't see the point of adding an 8-bit BOM mark
  (UTF-8 does not depend on byte order).
* The 32 vs. 16 refer to the number of bits in the
  Unicode internal type; they don't refer to the number of 
  bits in the mark.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-05-13 20:43

Message:
Logged In: YES 
user_id=89016

And if you're using a different encoding for the second 
open call, the data will really be corrupted:
f = codecs.open("/tmp/foo","w","utf-8")
f.write("ää")
f = codecs.open("/tmp/foo","a","latin-1")
f.write("ää")

But how should codec.open be able to determine that the 
file is always opened with the same encoding, or which 
encoding was used for the open call last time? And if it 
could would it have to read the content using the old 
encoding and rewrite it using the new encoding to keep the 
file consistent?

I agree that the BOM names are broken.

> I wonder if this is the right interface, actually. 
> Wouldn't prefixBOM() and checkBOM() methods for streams 
> and strings make more sense? prefixBOM should be 
> idempotent, and checkBOM would return either a codec 
> (with size and endianness determined) or a codec.BOM* 
> constant.

You should consider UTF-16 to be a stateful encoding, so if 
you want to do your output in multiple pieces you have to 
use a stateful encoder, i.e. a StreamWriter:

>>> import codecs, cStringIO as StringIO
>>> stream = StringIO.StringIO()
>>> writer = codecs.getwriter("utf-16")(stream)
>>> writer.write(u"a")
>>> writer.write(u"b") 
>>> stream.getvalue()
'\xff\xfea\x00b\x00'


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470



From noreply@sourceforge.net  Sun Jun  2 18:37:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 02 Jun 2002 10:37:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E17EZIT-0000Ut-00@usw-sf-web4.sourceforge.net>

Bugs item #535545, was opened at 2002-03-27 03:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Martin v. Löwis (loewis)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 19:37

Message:
Logged In: YES 
user_id=21627

This is very strange indeed. It does look like a different
bug, so I would like to close this one. I have committed
this change as

configure 1.279.6.6
configure.in 1.288.6.6

Please report the remaining problem as a new bug report. It
would be good if you could analyse it with more detail, e.g.
by invoking ./python ... manually (with the same variables
that make sets); if it still fails, I recommend to run the
newly-built python in gdb, to produce a backtrace.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 19:06

Message:
Logged In: YES 
user_id=133413

Yargh! Well, at least it gets to a _different_ problem
before compilation fails:

gcc  -Xlinker -export-dynamic -o python \
                Modules/python.o \
                libpython2.2.a -ldl  -lpthread -lutil   -lm  
case $MAKEFLAGS in \
*-s*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3
-Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; \
*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3
-Wall -Wstrict-prototypes' ./python -E ./setup.py build;; \
esac
make: *** [sharedmods] Error 139

Curiously, I believe what I had before was 2.2.1rc ... um, 1
I think. And it compiled fine once the one line in
pyconfig.h was corrected by hand. Is this another bug report
I should submit?


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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 18:53

Message:
Logged In: YES 
user_id=133413

Works! The standard configure in 2.2.1 comments out
HAVE_SYS_RESOURCE_H, whereas your new configure file on a
clean tree does not. Am testing compile now, but don't
anticipate a problem - will let you know if one kicks up.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 17:12

Message:
Logged In: YES 
user_id=21627

Yes, please: start with a clean 2.2.1 tree. I have
regenerated the configure for 2.2.1, and attached to this
report.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 16:18

Message:
Logged In: YES 
user_id=133413

Oh, Python version. By coincidence I just cleaned that from
the system last week, and don't remember the exact version.
Would it make sense for me to try to compile the latest
Python source, see if it fails the same way?

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 15:19

Message:
Logged In: YES 
user_id=21627

I'm still trying to find out why you could not apply the
patch I created earlier on. I want to recreate it so that it
works for your copy of the Python source code, but for that
to work, I need to know what version the copy of your Python
source code has.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 15:05

Message:
Logged In: YES 
user_id=133413

Since the problem comes from the way Red Hat 6.0 symlinks
the kernel libraries, which then creates a conflict between
library files if a kernel is compiled from source in the old
standard location of /usr/src/linux (don't think it would
apply to installing kernels from RPM since I don't think Red
Hat ever came up with a path to upgrade 6.0 to a 2.4 kernel
without upgrading the whole distribution) ... hmm, wonder if
that's precise enough for your purposes. There are various
system components upgraded from RPM after the base 6.0
release for security concerns and so on, so if the fix
wouldn't be generic to "6.0 + custom-compiled kernel in
/usr/src/linux" then this system probably couldn't be
defined precisely enough for the purpose.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 14:26

Message:
Logged In: YES 
user_id=21627

Whit, are you still interested in resolving this? If so, I
need to know the precise source distribution that you are
using, so I can produce patches against it.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-02 10:44

Message:
Logged In: YES 
user_id=21627

For 2.2.1, no action is needed - this is a system
configuration problem. 

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-31 22:21

Message:
Logged In: YES 
user_id=6656

Martin, what if anything do you think should be done here?

I'm leery of mucking with configure.in at this point.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 18:12

Message:
Logged In: YES 
user_id=133413

Have autoconf 2.13. Never explicitly used it though, and 
don't know the theory of it. If I patch, then invoke 
autoconf, then invoke configure ... well, that may not be 
what you mean, because it doesn't get around the problem.

If I just use your new configure file, that doesn't work 
either. Please specify the exact steps you require.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 17:35

Message:
Logged In: YES 
user_id=21627

If you have autoconf, you can just use the patch to
configure.in, and invoke 'autoconf'. In case you don't have
autoconf, I'll attach the complete configure file.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 17:30

Message:
Logged In: YES 
user_id=133413

Um ...

# patch -p1 <../conf.txt 
patching file `configure.in'
patching file `configure'
Reversed (or previously applied) patch detected!  Assume -R?
[n] 
Apply anyway? [n] y
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 1428.
2 out of 267 hunks FAILED -- saving rejects to configure.rej

If I say yes to -R, almost all hunks fail.

***************
*** 1,6 ****
  #! /bin/sh

- # From configure.in Revision: 1.288.6.3

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
--- 1,6 ----
  #! /bin/sh

+ # From configure.in Revision: 1.288.6.4

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
***************
*** 1428,1434 ****
          fi      
        case $ac_sys_system in
        AIX*)
-          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $(LINKCC)";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)
--- 1428,1434 ----
          fi      
        case $ac_sys_system in
        AIX*)
+          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $LINKCC";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)

Well, I'll try it as patched - those hunks don't look like
much is lost.

The config.log doesn't look good:

configure:2016: checking for sys/resource.h
configure:2026: gcc -E  conftest.c >/dev/null 2>conftest.out
In file included from /usr/include/sys/resource.h:25,
                 from configure:2022:
/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition
configure: failed program was:
#line 2021 "configure"
#include "confdefs.h"
#include <sys/resource.h>



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 16:58

Message:
Logged In: YES 
user_id=21627

Please try the attached conf.txt with an otherwise
unmodified system, and report whether it solves the problem.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 05:33

Message:
Logged In: YES 
user_id=133413

Probably not wisely, I tried changing the definition of
RLIM_INFINITY in bits/resource.h to match that in the kernel
header.  That took Python through the install, with make
test producing:

166 tests OK.
1 test failed:
    test_mmap
20 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl
test_imgfile
    test_largefile test_linuxaudiodev test_minidom test_nis
    test_ntpath test_pyexpat test_sax test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file
test_winreg
    test_winsound
4 skips unexpected on linux2:
    test_minidom test_linuxaudiodev test_pyexpat test_sax
make: *** [test] Error 1

As I understand all this, the definition to prefer should
probably be the one from glibc rather than the kernel (if it
even makes a difference on this value). Is this the one
which would be in effect if Python's configure were simply
to accept that resource.h is present rather than rejecting
it for this difference? 

RLIM_INFINITY btw is changed to match more recent kernels in
glibc 2.2 - but there's no rpm of that for Red Hat 6.x, and
of course building your own glibc is a good way to break a
system.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 00:03

Message:
Logged In: YES 
user_id=133413

A Google search leads me to a comment from Linus himself 
explaining that all the distributions symlinking like Red 
Hat 6.0 did are broken. I'm sure his theory is right, but 
out here in the real world, as he notes, many distros do 
that and most of us do have the idea that the current 
kernel should be built in /usr/src/linux. (Seems that rpms 
and debs of kernels put new kernel code there too - but 
I've always built kernels from tar.) 

Anyway, Linus's take is at: 
http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 23:43

Message:
Logged In: YES 
user_id=133413

You have good instincts on what to believe. I was mislead 
because rerunning configure produces a config.log without 
the warnings about resource.h. However running it in a 
freshly openned tar reproduces that warning; and even 
running it twice there (the second time, no warning) 
results in compilation failing at the same place.

So I think you have it - configure takes _any_ gcc warning 
as indicating nonexistence. And I think I see why the 
conflict comes on some systems but not on others. Red Hat 
6.0 sets /usr/include/asm as follows:

asm -> ../src/linux/include/asm/

That directory includes a "resource.h". On this box that 
happens to be code included with kernel 2.4.16, largely 
consisting of a modified definition of RLIM_INFINITY. I'd 
guess if the box still had a 2.2 kernel there would be no 
gcc warning. The whole of that file is:

#ifndef _I386_RESOURCE_H
#define _I386_RESOURCE_H

/*
 * Resource limits
 */

#define RLIMIT_CPU      0               /* CPU time in ms 
*/
#define RLIMIT_FSIZE    1               /* Maximum 
filesize */
#define RLIMIT_DATA     2               /* max data size */
#define RLIMIT_STACK    3               /* max stack size 
*/
#define RLIMIT_CORE     4               /* max core file 
size */
#define RLIMIT_RSS      5               /* max resident 
set size */
#define RLIMIT_NPROC    6               /* max number of 
processes */
#define RLIMIT_NOFILE   7               /* max number of 
open files */
#define RLIMIT_MEMLOCK  8               /* max 
locked-in-memory address space */
#define RLIMIT_AS       9               /* address space 
limit */
#define RLIMIT_LOCKS    10              /* maximum file 
locks held */

#define RLIM_NLIMITS    11

/*
 * SuS says limits have to be unsigned.
 * Which makes a ton more sense anyway.
 */
#define RLIM_INFINITY   (~0UL)

#ifdef __KERNEL__

#define INIT_RLIMITS                                    {                                                               { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {      _STK_LIM, RLIM_INFINITY },                       {             0, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {             0,             0 },                       {      INR_OPEN,     INR_OPEN  },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },               }
 
#endif /* __KERNEL__ */

#endif




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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 22:08

Message:
Logged In: YES 
user_id=21627

This is hard to believe: the spaces should have no effect.
Please consider the config.log analysis of the problem:

/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition

Apparently, configure treats these warnings as an indication
that sys/resource.h is absent. config.log also gives the
"program" it tried to compile - if your theory is correct,
changing the spaces should silence the gcc warning. Could
you please verify this theory (i.e. compiling the program

#include <sys/resource.h>

both with the original and the modified resource.h)

It appears that configure should disable warnings in gcc;
I'll try to come up with a patch.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 18:20

Message:
Logged In: YES 
user_id=133413

Think you've led me to the problem.

/usr/include/bits/resource.h has:

/* Value to indicate that there is no limit.  */
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int)(~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif

#ifdef __USE_LARGEFILE64
# define RLIM64_INFINITY 0x7fffffffffffffffLL
#endif

Removing the spaces after "#" before "define" results in 
configure correctly recognizing resource.h. Then the 
question would be: is this a shortcoming of configure, or 
are those spaces actually disabling bugs in this version 
of bits/resource.h? 


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:56

Message:
Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 17:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:02

Message:
Logged In: YES 
user_id=133413

Here it is.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 01:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 01:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 20:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 17:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 16:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470



From noreply@sourceforge.net  Sun Jun  2 18:47:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 02 Jun 2002 10:47:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E17EZSI-0000WW-00@usw-sf-web2.sourceforge.net>

Bugs item #535545, was opened at 2002-03-26 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2
>Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Martin v. Löwis (loewis)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



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

>Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 13:47

Message:
Logged In: YES 
user_id=133413

Yes, close this one. Not sure how to analyze this:

# ./python -E ./setup.py build
Segmentation fault (core dumped)

Never have learned the tools for analyzing the dumped core. 

Even just ./python dumps core. My current kernel is
2.4.19-pre9-ac3 - updated since this bug report was
submitted - if that can be pertinent.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 13:37

Message:
Logged In: YES 
user_id=21627

This is very strange indeed. It does look like a different
bug, so I would like to close this one. I have committed
this change as

configure 1.279.6.6
configure.in 1.288.6.6

Please report the remaining problem as a new bug report. It
would be good if you could analyse it with more detail, e.g.
by invoking ./python ... manually (with the same variables
that make sets); if it still fails, I recommend to run the
newly-built python in gdb, to produce a backtrace.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 13:06

Message:
Logged In: YES 
user_id=133413

Yargh! Well, at least it gets to a _different_ problem
before compilation fails:

gcc  -Xlinker -export-dynamic -o python \
                Modules/python.o \
                libpython2.2.a -ldl  -lpthread -lutil   -lm  
case $MAKEFLAGS in \
*-s*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3
-Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; \
*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3
-Wall -Wstrict-prototypes' ./python -E ./setup.py build;; \
esac
make: *** [sharedmods] Error 139

Curiously, I believe what I had before was 2.2.1rc ... um, 1
I think. And it compiled fine once the one line in
pyconfig.h was corrected by hand. Is this another bug report
I should submit?


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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 12:53

Message:
Logged In: YES 
user_id=133413

Works! The standard configure in 2.2.1 comments out
HAVE_SYS_RESOURCE_H, whereas your new configure file on a
clean tree does not. Am testing compile now, but don't
anticipate a problem - will let you know if one kicks up.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 11:12

Message:
Logged In: YES 
user_id=21627

Yes, please: start with a clean 2.2.1 tree. I have
regenerated the configure for 2.2.1, and attached to this
report.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 10:18

Message:
Logged In: YES 
user_id=133413

Oh, Python version. By coincidence I just cleaned that from
the system last week, and don't remember the exact version.
Would it make sense for me to try to compile the latest
Python source, see if it fails the same way?

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 09:19

Message:
Logged In: YES 
user_id=21627

I'm still trying to find out why you could not apply the
patch I created earlier on. I want to recreate it so that it
works for your copy of the Python source code, but for that
to work, I need to know what version the copy of your Python
source code has.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 09:05

Message:
Logged In: YES 
user_id=133413

Since the problem comes from the way Red Hat 6.0 symlinks
the kernel libraries, which then creates a conflict between
library files if a kernel is compiled from source in the old
standard location of /usr/src/linux (don't think it would
apply to installing kernels from RPM since I don't think Red
Hat ever came up with a path to upgrade 6.0 to a 2.4 kernel
without upgrading the whole distribution) ... hmm, wonder if
that's precise enough for your purposes. There are various
system components upgraded from RPM after the base 6.0
release for security concerns and so on, so if the fix
wouldn't be generic to "6.0 + custom-compiled kernel in
/usr/src/linux" then this system probably couldn't be
defined precisely enough for the purpose.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 08:26

Message:
Logged In: YES 
user_id=21627

Whit, are you still interested in resolving this? If so, I
need to know the precise source distribution that you are
using, so I can produce patches against it.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-02 03:44

Message:
Logged In: YES 
user_id=21627

For 2.2.1, no action is needed - this is a system
configuration problem. 

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-31 15:21

Message:
Logged In: YES 
user_id=6656

Martin, what if anything do you think should be done here?

I'm leery of mucking with configure.in at this point.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 12:12

Message:
Logged In: YES 
user_id=133413

Have autoconf 2.13. Never explicitly used it though, and 
don't know the theory of it. If I patch, then invoke 
autoconf, then invoke configure ... well, that may not be 
what you mean, because it doesn't get around the problem.

If I just use your new configure file, that doesn't work 
either. Please specify the exact steps you require.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 11:35

Message:
Logged In: YES 
user_id=21627

If you have autoconf, you can just use the patch to
configure.in, and invoke 'autoconf'. In case you don't have
autoconf, I'll attach the complete configure file.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 11:30

Message:
Logged In: YES 
user_id=133413

Um ...

# patch -p1 <../conf.txt 
patching file `configure.in'
patching file `configure'
Reversed (or previously applied) patch detected!  Assume -R?
[n] 
Apply anyway? [n] y
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 1428.
2 out of 267 hunks FAILED -- saving rejects to configure.rej

If I say yes to -R, almost all hunks fail.

***************
*** 1,6 ****
  #! /bin/sh

- # From configure.in Revision: 1.288.6.3

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
--- 1,6 ----
  #! /bin/sh

+ # From configure.in Revision: 1.288.6.4

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
***************
*** 1428,1434 ****
          fi      
        case $ac_sys_system in
        AIX*)
-          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $(LINKCC)";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)
--- 1428,1434 ----
          fi      
        case $ac_sys_system in
        AIX*)
+          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $LINKCC";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)

Well, I'll try it as patched - those hunks don't look like
much is lost.

The config.log doesn't look good:

configure:2016: checking for sys/resource.h
configure:2026: gcc -E  conftest.c >/dev/null 2>conftest.out
In file included from /usr/include/sys/resource.h:25,
                 from configure:2022:
/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition
configure: failed program was:
#line 2021 "configure"
#include "confdefs.h"
#include <sys/resource.h>



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 10:58

Message:
Logged In: YES 
user_id=21627

Please try the attached conf.txt with an otherwise
unmodified system, and report whether it solves the problem.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 23:33

Message:
Logged In: YES 
user_id=133413

Probably not wisely, I tried changing the definition of
RLIM_INFINITY in bits/resource.h to match that in the kernel
header.  That took Python through the install, with make
test producing:

166 tests OK.
1 test failed:
    test_mmap
20 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl
test_imgfile
    test_largefile test_linuxaudiodev test_minidom test_nis
    test_ntpath test_pyexpat test_sax test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file
test_winreg
    test_winsound
4 skips unexpected on linux2:
    test_minidom test_linuxaudiodev test_pyexpat test_sax
make: *** [test] Error 1

As I understand all this, the definition to prefer should
probably be the one from glibc rather than the kernel (if it
even makes a difference on this value). Is this the one
which would be in effect if Python's configure were simply
to accept that resource.h is present rather than rejecting
it for this difference? 

RLIM_INFINITY btw is changed to match more recent kernels in
glibc 2.2 - but there's no rpm of that for Red Hat 6.x, and
of course building your own glibc is a good way to break a
system.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 18:03

Message:
Logged In: YES 
user_id=133413

A Google search leads me to a comment from Linus himself 
explaining that all the distributions symlinking like Red 
Hat 6.0 did are broken. I'm sure his theory is right, but 
out here in the real world, as he notes, many distros do 
that and most of us do have the idea that the current 
kernel should be built in /usr/src/linux. (Seems that rpms 
and debs of kernels put new kernel code there too - but 
I've always built kernels from tar.) 

Anyway, Linus's take is at: 
http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:43

Message:
Logged In: YES 
user_id=133413

You have good instincts on what to believe. I was mislead 
because rerunning configure produces a config.log without 
the warnings about resource.h. However running it in a 
freshly openned tar reproduces that warning; and even 
running it twice there (the second time, no warning) 
results in compilation failing at the same place.

So I think you have it - configure takes _any_ gcc warning 
as indicating nonexistence. And I think I see why the 
conflict comes on some systems but not on others. Red Hat 
6.0 sets /usr/include/asm as follows:

asm -> ../src/linux/include/asm/

That directory includes a "resource.h". On this box that 
happens to be code included with kernel 2.4.16, largely 
consisting of a modified definition of RLIM_INFINITY. I'd 
guess if the box still had a 2.2 kernel there would be no 
gcc warning. The whole of that file is:

#ifndef _I386_RESOURCE_H
#define _I386_RESOURCE_H

/*
 * Resource limits
 */

#define RLIMIT_CPU      0               /* CPU time in ms 
*/
#define RLIMIT_FSIZE    1               /* Maximum 
filesize */
#define RLIMIT_DATA     2               /* max data size */
#define RLIMIT_STACK    3               /* max stack size 
*/
#define RLIMIT_CORE     4               /* max core file 
size */
#define RLIMIT_RSS      5               /* max resident 
set size */
#define RLIMIT_NPROC    6               /* max number of 
processes */
#define RLIMIT_NOFILE   7               /* max number of 
open files */
#define RLIMIT_MEMLOCK  8               /* max 
locked-in-memory address space */
#define RLIMIT_AS       9               /* address space 
limit */
#define RLIMIT_LOCKS    10              /* maximum file 
locks held */

#define RLIM_NLIMITS    11

/*
 * SuS says limits have to be unsigned.
 * Which makes a ton more sense anyway.
 */
#define RLIM_INFINITY   (~0UL)

#ifdef __KERNEL__

#define INIT_RLIMITS                                    {                                                               { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {      _STK_LIM, RLIM_INFINITY },                       {             0, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {             0,             0 },                       {      INR_OPEN,     INR_OPEN  },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },               }
 
#endif /* __KERNEL__ */

#endif




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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16:08

Message:
Logged In: YES 
user_id=21627

This is hard to believe: the spaces should have no effect.
Please consider the config.log analysis of the problem:

/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition

Apparently, configure treats these warnings as an indication
that sys/resource.h is absent. config.log also gives the
"program" it tried to compile - if your theory is correct,
changing the spaces should silence the gcc warning. Could
you please verify this theory (i.e. compiling the program

#include <sys/resource.h>

both with the original and the modified resource.h)

It appears that configure should disable warnings in gcc;
I'll try to come up with a patch.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 12:20

Message:
Logged In: YES 
user_id=133413

Think you've led me to the problem.

/usr/include/bits/resource.h has:

/* Value to indicate that there is no limit.  */
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int)(~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif

#ifdef __USE_LARGEFILE64
# define RLIM64_INFINITY 0x7fffffffffffffffLL
#endif

Removing the spaces after "#" before "define" results in 
configure correctly recognizing resource.h. Then the 
question would be: is this a shortcoming of configure, or 
are those spaces actually disabling bugs in this version 
of bits/resource.h? 


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:56

Message:
Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:02

Message:
Logged In: YES 
user_id=133413

Here it is.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 10:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 05:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 19:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 19:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 14:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 11:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 10:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 07:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470



From noreply@sourceforge.net  Sun Jun  2 18:51:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 02 Jun 2002 10:51:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E17EZW8-0000e0-00@usw-sf-web4.sourceforge.net>

Bugs item #535545, was opened at 2002-03-26 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Martin v. Löwis (loewis)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



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

>Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 13:51

Message:
Logged In: YES 
user_id=133413

Okay, this probably shows something. I add it here in case
you have a comment on how to submit the bug. But if you
don't, I'll just put in a report on a "dumps core" bug with
this included:

gdb ./python ./core
GNU gdb 4.17.0.11 with Linux support
...
This GDB was configured as "i386-redhat-linux"...
Core was generated by `./python'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libpthread.so.0...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.
#0  0x8075732 in eval_frame (f=0x8124f94) at Python/ceval.c:1310
1310                            Py_DECREF(u);


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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 13:47

Message:
Logged In: YES 
user_id=133413

Yes, close this one. Not sure how to analyze this:

# ./python -E ./setup.py build
Segmentation fault (core dumped)

Never have learned the tools for analyzing the dumped core. 

Even just ./python dumps core. My current kernel is
2.4.19-pre9-ac3 - updated since this bug report was
submitted - if that can be pertinent.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 13:37

Message:
Logged In: YES 
user_id=21627

This is very strange indeed. It does look like a different
bug, so I would like to close this one. I have committed
this change as

configure 1.279.6.6
configure.in 1.288.6.6

Please report the remaining problem as a new bug report. It
would be good if you could analyse it with more detail, e.g.
by invoking ./python ... manually (with the same variables
that make sets); if it still fails, I recommend to run the
newly-built python in gdb, to produce a backtrace.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 13:06

Message:
Logged In: YES 
user_id=133413

Yargh! Well, at least it gets to a _different_ problem
before compilation fails:

gcc  -Xlinker -export-dynamic -o python \
                Modules/python.o \
                libpython2.2.a -ldl  -lpthread -lutil   -lm  
case $MAKEFLAGS in \
*-s*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3
-Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; \
*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3
-Wall -Wstrict-prototypes' ./python -E ./setup.py build;; \
esac
make: *** [sharedmods] Error 139

Curiously, I believe what I had before was 2.2.1rc ... um, 1
I think. And it compiled fine once the one line in
pyconfig.h was corrected by hand. Is this another bug report
I should submit?


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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 12:53

Message:
Logged In: YES 
user_id=133413

Works! The standard configure in 2.2.1 comments out
HAVE_SYS_RESOURCE_H, whereas your new configure file on a
clean tree does not. Am testing compile now, but don't
anticipate a problem - will let you know if one kicks up.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 11:12

Message:
Logged In: YES 
user_id=21627

Yes, please: start with a clean 2.2.1 tree. I have
regenerated the configure for 2.2.1, and attached to this
report.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 10:18

Message:
Logged In: YES 
user_id=133413

Oh, Python version. By coincidence I just cleaned that from
the system last week, and don't remember the exact version.
Would it make sense for me to try to compile the latest
Python source, see if it fails the same way?

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 09:19

Message:
Logged In: YES 
user_id=21627

I'm still trying to find out why you could not apply the
patch I created earlier on. I want to recreate it so that it
works for your copy of the Python source code, but for that
to work, I need to know what version the copy of your Python
source code has.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 09:05

Message:
Logged In: YES 
user_id=133413

Since the problem comes from the way Red Hat 6.0 symlinks
the kernel libraries, which then creates a conflict between
library files if a kernel is compiled from source in the old
standard location of /usr/src/linux (don't think it would
apply to installing kernels from RPM since I don't think Red
Hat ever came up with a path to upgrade 6.0 to a 2.4 kernel
without upgrading the whole distribution) ... hmm, wonder if
that's precise enough for your purposes. There are various
system components upgraded from RPM after the base 6.0
release for security concerns and so on, so if the fix
wouldn't be generic to "6.0 + custom-compiled kernel in
/usr/src/linux" then this system probably couldn't be
defined precisely enough for the purpose.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 08:26

Message:
Logged In: YES 
user_id=21627

Whit, are you still interested in resolving this? If so, I
need to know the precise source distribution that you are
using, so I can produce patches against it.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-02 03:44

Message:
Logged In: YES 
user_id=21627

For 2.2.1, no action is needed - this is a system
configuration problem. 

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-31 15:21

Message:
Logged In: YES 
user_id=6656

Martin, what if anything do you think should be done here?

I'm leery of mucking with configure.in at this point.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 12:12

Message:
Logged In: YES 
user_id=133413

Have autoconf 2.13. Never explicitly used it though, and 
don't know the theory of it. If I patch, then invoke 
autoconf, then invoke configure ... well, that may not be 
what you mean, because it doesn't get around the problem.

If I just use your new configure file, that doesn't work 
either. Please specify the exact steps you require.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 11:35

Message:
Logged In: YES 
user_id=21627

If you have autoconf, you can just use the patch to
configure.in, and invoke 'autoconf'. In case you don't have
autoconf, I'll attach the complete configure file.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 11:30

Message:
Logged In: YES 
user_id=133413

Um ...

# patch -p1 <../conf.txt 
patching file `configure.in'
patching file `configure'
Reversed (or previously applied) patch detected!  Assume -R?
[n] 
Apply anyway? [n] y
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 1428.
2 out of 267 hunks FAILED -- saving rejects to configure.rej

If I say yes to -R, almost all hunks fail.

***************
*** 1,6 ****
  #! /bin/sh

- # From configure.in Revision: 1.288.6.3

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
--- 1,6 ----
  #! /bin/sh

+ # From configure.in Revision: 1.288.6.4

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
***************
*** 1428,1434 ****
          fi      
        case $ac_sys_system in
        AIX*)
-          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $(LINKCC)";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)
--- 1428,1434 ----
          fi      
        case $ac_sys_system in
        AIX*)
+          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $LINKCC";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)

Well, I'll try it as patched - those hunks don't look like
much is lost.

The config.log doesn't look good:

configure:2016: checking for sys/resource.h
configure:2026: gcc -E  conftest.c >/dev/null 2>conftest.out
In file included from /usr/include/sys/resource.h:25,
                 from configure:2022:
/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition
configure: failed program was:
#line 2021 "configure"
#include "confdefs.h"
#include <sys/resource.h>



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 10:58

Message:
Logged In: YES 
user_id=21627

Please try the attached conf.txt with an otherwise
unmodified system, and report whether it solves the problem.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 23:33

Message:
Logged In: YES 
user_id=133413

Probably not wisely, I tried changing the definition of
RLIM_INFINITY in bits/resource.h to match that in the kernel
header.  That took Python through the install, with make
test producing:

166 tests OK.
1 test failed:
    test_mmap
20 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl
test_imgfile
    test_largefile test_linuxaudiodev test_minidom test_nis
    test_ntpath test_pyexpat test_sax test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file
test_winreg
    test_winsound
4 skips unexpected on linux2:
    test_minidom test_linuxaudiodev test_pyexpat test_sax
make: *** [test] Error 1

As I understand all this, the definition to prefer should
probably be the one from glibc rather than the kernel (if it
even makes a difference on this value). Is this the one
which would be in effect if Python's configure were simply
to accept that resource.h is present rather than rejecting
it for this difference? 

RLIM_INFINITY btw is changed to match more recent kernels in
glibc 2.2 - but there's no rpm of that for Red Hat 6.x, and
of course building your own glibc is a good way to break a
system.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 18:03

Message:
Logged In: YES 
user_id=133413

A Google search leads me to a comment from Linus himself 
explaining that all the distributions symlinking like Red 
Hat 6.0 did are broken. I'm sure his theory is right, but 
out here in the real world, as he notes, many distros do 
that and most of us do have the idea that the current 
kernel should be built in /usr/src/linux. (Seems that rpms 
and debs of kernels put new kernel code there too - but 
I've always built kernels from tar.) 

Anyway, Linus's take is at: 
http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:43

Message:
Logged In: YES 
user_id=133413

You have good instincts on what to believe. I was mislead 
because rerunning configure produces a config.log without 
the warnings about resource.h. However running it in a 
freshly openned tar reproduces that warning; and even 
running it twice there (the second time, no warning) 
results in compilation failing at the same place.

So I think you have it - configure takes _any_ gcc warning 
as indicating nonexistence. And I think I see why the 
conflict comes on some systems but not on others. Red Hat 
6.0 sets /usr/include/asm as follows:

asm -> ../src/linux/include/asm/

That directory includes a "resource.h". On this box that 
happens to be code included with kernel 2.4.16, largely 
consisting of a modified definition of RLIM_INFINITY. I'd 
guess if the box still had a 2.2 kernel there would be no 
gcc warning. The whole of that file is:

#ifndef _I386_RESOURCE_H
#define _I386_RESOURCE_H

/*
 * Resource limits
 */

#define RLIMIT_CPU      0               /* CPU time in ms 
*/
#define RLIMIT_FSIZE    1               /* Maximum 
filesize */
#define RLIMIT_DATA     2               /* max data size */
#define RLIMIT_STACK    3               /* max stack size 
*/
#define RLIMIT_CORE     4               /* max core file 
size */
#define RLIMIT_RSS      5               /* max resident 
set size */
#define RLIMIT_NPROC    6               /* max number of 
processes */
#define RLIMIT_NOFILE   7               /* max number of 
open files */
#define RLIMIT_MEMLOCK  8               /* max 
locked-in-memory address space */
#define RLIMIT_AS       9               /* address space 
limit */
#define RLIMIT_LOCKS    10              /* maximum file 
locks held */

#define RLIM_NLIMITS    11

/*
 * SuS says limits have to be unsigned.
 * Which makes a ton more sense anyway.
 */
#define RLIM_INFINITY   (~0UL)

#ifdef __KERNEL__

#define INIT_RLIMITS                                    {                                                               { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {      _STK_LIM, RLIM_INFINITY },                       {             0, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {             0,             0 },                       {      INR_OPEN,     INR_OPEN  },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },               }
 
#endif /* __KERNEL__ */

#endif




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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16:08

Message:
Logged In: YES 
user_id=21627

This is hard to believe: the spaces should have no effect.
Please consider the config.log analysis of the problem:

/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition

Apparently, configure treats these warnings as an indication
that sys/resource.h is absent. config.log also gives the
"program" it tried to compile - if your theory is correct,
changing the spaces should silence the gcc warning. Could
you please verify this theory (i.e. compiling the program

#include <sys/resource.h>

both with the original and the modified resource.h)

It appears that configure should disable warnings in gcc;
I'll try to come up with a patch.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 12:20

Message:
Logged In: YES 
user_id=133413

Think you've led me to the problem.

/usr/include/bits/resource.h has:

/* Value to indicate that there is no limit.  */
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int)(~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif

#ifdef __USE_LARGEFILE64
# define RLIM64_INFINITY 0x7fffffffffffffffLL
#endif

Removing the spaces after "#" before "define" results in 
configure correctly recognizing resource.h. Then the 
question would be: is this a shortcoming of configure, or 
are those spaces actually disabling bugs in this version 
of bits/resource.h? 


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:56

Message:
Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:02

Message:
Logged In: YES 
user_id=133413

Here it is.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 10:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 05:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 19:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 19:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 14:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 11:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 10:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 07:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470



From noreply@sourceforge.net  Sun Jun  2 18:57:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 02 Jun 2002 10:57:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E17EZbx-0002M1-00@usw-sf-web3.sourceforge.net>

Bugs item #535545, was opened at 2002-03-27 03:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Martin v. Löwis (loewis)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 19:57

Message:
Logged In: YES 
user_id=21627

Type 'bt' at the gdb prompt to get a backtrace. In the
specific case, it is also helpful to type 'print u' to get
the value of u at the time of the crash.

Closing this report again.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 19:51

Message:
Logged In: YES 
user_id=133413

Okay, this probably shows something. I add it here in case
you have a comment on how to submit the bug. But if you
don't, I'll just put in a report on a "dumps core" bug with
this included:

gdb ./python ./core
GNU gdb 4.17.0.11 with Linux support
...
This GDB was configured as "i386-redhat-linux"...
Core was generated by `./python'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libpthread.so.0...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.
#0  0x8075732 in eval_frame (f=0x8124f94) at Python/ceval.c:1310
1310                            Py_DECREF(u);


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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 19:47

Message:
Logged In: YES 
user_id=133413

Yes, close this one. Not sure how to analyze this:

# ./python -E ./setup.py build
Segmentation fault (core dumped)

Never have learned the tools for analyzing the dumped core. 

Even just ./python dumps core. My current kernel is
2.4.19-pre9-ac3 - updated since this bug report was
submitted - if that can be pertinent.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 19:37

Message:
Logged In: YES 
user_id=21627

This is very strange indeed. It does look like a different
bug, so I would like to close this one. I have committed
this change as

configure 1.279.6.6
configure.in 1.288.6.6

Please report the remaining problem as a new bug report. It
would be good if you could analyse it with more detail, e.g.
by invoking ./python ... manually (with the same variables
that make sets); if it still fails, I recommend to run the
newly-built python in gdb, to produce a backtrace.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 19:06

Message:
Logged In: YES 
user_id=133413

Yargh! Well, at least it gets to a _different_ problem
before compilation fails:

gcc  -Xlinker -export-dynamic -o python \
                Modules/python.o \
                libpython2.2.a -ldl  -lpthread -lutil   -lm  
case $MAKEFLAGS in \
*-s*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3
-Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; \
*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3
-Wall -Wstrict-prototypes' ./python -E ./setup.py build;; \
esac
make: *** [sharedmods] Error 139

Curiously, I believe what I had before was 2.2.1rc ... um, 1
I think. And it compiled fine once the one line in
pyconfig.h was corrected by hand. Is this another bug report
I should submit?


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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 18:53

Message:
Logged In: YES 
user_id=133413

Works! The standard configure in 2.2.1 comments out
HAVE_SYS_RESOURCE_H, whereas your new configure file on a
clean tree does not. Am testing compile now, but don't
anticipate a problem - will let you know if one kicks up.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 17:12

Message:
Logged In: YES 
user_id=21627

Yes, please: start with a clean 2.2.1 tree. I have
regenerated the configure for 2.2.1, and attached to this
report.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 16:18

Message:
Logged In: YES 
user_id=133413

Oh, Python version. By coincidence I just cleaned that from
the system last week, and don't remember the exact version.
Would it make sense for me to try to compile the latest
Python source, see if it fails the same way?

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 15:19

Message:
Logged In: YES 
user_id=21627

I'm still trying to find out why you could not apply the
patch I created earlier on. I want to recreate it so that it
works for your copy of the Python source code, but for that
to work, I need to know what version the copy of your Python
source code has.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 15:05

Message:
Logged In: YES 
user_id=133413

Since the problem comes from the way Red Hat 6.0 symlinks
the kernel libraries, which then creates a conflict between
library files if a kernel is compiled from source in the old
standard location of /usr/src/linux (don't think it would
apply to installing kernels from RPM since I don't think Red
Hat ever came up with a path to upgrade 6.0 to a 2.4 kernel
without upgrading the whole distribution) ... hmm, wonder if
that's precise enough for your purposes. There are various
system components upgraded from RPM after the base 6.0
release for security concerns and so on, so if the fix
wouldn't be generic to "6.0 + custom-compiled kernel in
/usr/src/linux" then this system probably couldn't be
defined precisely enough for the purpose.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 14:26

Message:
Logged In: YES 
user_id=21627

Whit, are you still interested in resolving this? If so, I
need to know the precise source distribution that you are
using, so I can produce patches against it.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-02 10:44

Message:
Logged In: YES 
user_id=21627

For 2.2.1, no action is needed - this is a system
configuration problem. 

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-31 22:21

Message:
Logged In: YES 
user_id=6656

Martin, what if anything do you think should be done here?

I'm leery of mucking with configure.in at this point.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 18:12

Message:
Logged In: YES 
user_id=133413

Have autoconf 2.13. Never explicitly used it though, and 
don't know the theory of it. If I patch, then invoke 
autoconf, then invoke configure ... well, that may not be 
what you mean, because it doesn't get around the problem.

If I just use your new configure file, that doesn't work 
either. Please specify the exact steps you require.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 17:35

Message:
Logged In: YES 
user_id=21627

If you have autoconf, you can just use the patch to
configure.in, and invoke 'autoconf'. In case you don't have
autoconf, I'll attach the complete configure file.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 17:30

Message:
Logged In: YES 
user_id=133413

Um ...

# patch -p1 <../conf.txt 
patching file `configure.in'
patching file `configure'
Reversed (or previously applied) patch detected!  Assume -R?
[n] 
Apply anyway? [n] y
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 1428.
2 out of 267 hunks FAILED -- saving rejects to configure.rej

If I say yes to -R, almost all hunks fail.

***************
*** 1,6 ****
  #! /bin/sh

- # From configure.in Revision: 1.288.6.3

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
--- 1,6 ----
  #! /bin/sh

+ # From configure.in Revision: 1.288.6.4

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
***************
*** 1428,1434 ****
          fi      
        case $ac_sys_system in
        AIX*)
-          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $(LINKCC)";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)
--- 1428,1434 ----
          fi      
        case $ac_sys_system in
        AIX*)
+          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $LINKCC";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)

Well, I'll try it as patched - those hunks don't look like
much is lost.

The config.log doesn't look good:

configure:2016: checking for sys/resource.h
configure:2026: gcc -E  conftest.c >/dev/null 2>conftest.out
In file included from /usr/include/sys/resource.h:25,
                 from configure:2022:
/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition
configure: failed program was:
#line 2021 "configure"
#include "confdefs.h"
#include <sys/resource.h>



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 16:58

Message:
Logged In: YES 
user_id=21627

Please try the attached conf.txt with an otherwise
unmodified system, and report whether it solves the problem.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 05:33

Message:
Logged In: YES 
user_id=133413

Probably not wisely, I tried changing the definition of
RLIM_INFINITY in bits/resource.h to match that in the kernel
header.  That took Python through the install, with make
test producing:

166 tests OK.
1 test failed:
    test_mmap
20 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl
test_imgfile
    test_largefile test_linuxaudiodev test_minidom test_nis
    test_ntpath test_pyexpat test_sax test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file
test_winreg
    test_winsound
4 skips unexpected on linux2:
    test_minidom test_linuxaudiodev test_pyexpat test_sax
make: *** [test] Error 1

As I understand all this, the definition to prefer should
probably be the one from glibc rather than the kernel (if it
even makes a difference on this value). Is this the one
which would be in effect if Python's configure were simply
to accept that resource.h is present rather than rejecting
it for this difference? 

RLIM_INFINITY btw is changed to match more recent kernels in
glibc 2.2 - but there's no rpm of that for Red Hat 6.x, and
of course building your own glibc is a good way to break a
system.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 00:03

Message:
Logged In: YES 
user_id=133413

A Google search leads me to a comment from Linus himself 
explaining that all the distributions symlinking like Red 
Hat 6.0 did are broken. I'm sure his theory is right, but 
out here in the real world, as he notes, many distros do 
that and most of us do have the idea that the current 
kernel should be built in /usr/src/linux. (Seems that rpms 
and debs of kernels put new kernel code there too - but 
I've always built kernels from tar.) 

Anyway, Linus's take is at: 
http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 23:43

Message:
Logged In: YES 
user_id=133413

You have good instincts on what to believe. I was mislead 
because rerunning configure produces a config.log without 
the warnings about resource.h. However running it in a 
freshly openned tar reproduces that warning; and even 
running it twice there (the second time, no warning) 
results in compilation failing at the same place.

So I think you have it - configure takes _any_ gcc warning 
as indicating nonexistence. And I think I see why the 
conflict comes on some systems but not on others. Red Hat 
6.0 sets /usr/include/asm as follows:

asm -> ../src/linux/include/asm/

That directory includes a "resource.h". On this box that 
happens to be code included with kernel 2.4.16, largely 
consisting of a modified definition of RLIM_INFINITY. I'd 
guess if the box still had a 2.2 kernel there would be no 
gcc warning. The whole of that file is:

#ifndef _I386_RESOURCE_H
#define _I386_RESOURCE_H

/*
 * Resource limits
 */

#define RLIMIT_CPU      0               /* CPU time in ms 
*/
#define RLIMIT_FSIZE    1               /* Maximum 
filesize */
#define RLIMIT_DATA     2               /* max data size */
#define RLIMIT_STACK    3               /* max stack size 
*/
#define RLIMIT_CORE     4               /* max core file 
size */
#define RLIMIT_RSS      5               /* max resident 
set size */
#define RLIMIT_NPROC    6               /* max number of 
processes */
#define RLIMIT_NOFILE   7               /* max number of 
open files */
#define RLIMIT_MEMLOCK  8               /* max 
locked-in-memory address space */
#define RLIMIT_AS       9               /* address space 
limit */
#define RLIMIT_LOCKS    10              /* maximum file 
locks held */

#define RLIM_NLIMITS    11

/*
 * SuS says limits have to be unsigned.
 * Which makes a ton more sense anyway.
 */
#define RLIM_INFINITY   (~0UL)

#ifdef __KERNEL__

#define INIT_RLIMITS                                    {                                                               { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {      _STK_LIM, RLIM_INFINITY },                       {             0, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {             0,             0 },                       {      INR_OPEN,     INR_OPEN  },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },               }
 
#endif /* __KERNEL__ */

#endif




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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 22:08

Message:
Logged In: YES 
user_id=21627

This is hard to believe: the spaces should have no effect.
Please consider the config.log analysis of the problem:

/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition

Apparently, configure treats these warnings as an indication
that sys/resource.h is absent. config.log also gives the
"program" it tried to compile - if your theory is correct,
changing the spaces should silence the gcc warning. Could
you please verify this theory (i.e. compiling the program

#include <sys/resource.h>

both with the original and the modified resource.h)

It appears that configure should disable warnings in gcc;
I'll try to come up with a patch.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 18:20

Message:
Logged In: YES 
user_id=133413

Think you've led me to the problem.

/usr/include/bits/resource.h has:

/* Value to indicate that there is no limit.  */
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int)(~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif

#ifdef __USE_LARGEFILE64
# define RLIM64_INFINITY 0x7fffffffffffffffLL
#endif

Removing the spaces after "#" before "define" results in 
configure correctly recognizing resource.h. Then the 
question would be: is this a shortcoming of configure, or 
are those spaces actually disabling bugs in this version 
of bits/resource.h? 


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:56

Message:
Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 17:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:02

Message:
Logged In: YES 
user_id=133413

Here it is.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 01:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 01:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 20:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 17:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 16:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470



From noreply@sourceforge.net  Sun Jun  2 19:09:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 02 Jun 2002 11:09:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-563598 ] Core dump with newly built Python
Message-ID: <E17EZn5-0005um-00@usw-sf-web1.sourceforge.net>

Bugs item #563598, was opened at 2002-06-02 14:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563598&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Nobody/Anonymous (nobody)
Summary: Core dump with newly built Python

Initial Comment:
This is on what started as a Red Hat 6.0 box currently
running a 2.4.19-pre9-ac3 kernel:

# gdb ./python ./core
GNU gdb 4.17.0.11 with Linux support
...
This GDB was configured as "i386-redhat-linux"...
Core was generated by `./python -E ./setup.py build'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libpthread.so.0...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.
#0  0x8075732 in eval_frame (f=0x812504c) at
Python/ceval.c:1310
1310                            Py_DECREF(u);

(gdb) bt 
#0  0x8075732 in eval_frame (f=0x812504c) at
Python/ceval.c:1310
#1  0x8077bee in PyEval_EvalCodeEx (co=0x81245c0,
globals=0x811ec6c, locals=0x811ec6c, args=0x0,
argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at
Python/ceval.c:2585
#2  0x8079c60 in PyEval_EvalCode (co=0x81245c0,
globals=0x811ec6c, locals=0x811ec6c) at Python/ceval.c:483
#3  0x808b53d in PyImport_ExecCodeModuleEx
(name=0xbfffe4f4 "os", co=0x81245c0, 
    pathname=0xbfffdbf4
"/usr/src/Python-2.2.1/Lib/os.pyc") at Python/import.c:502
#4  0x808ba59 in load_source_module (name=0xbfffe4f4
"os", pathname=0xbfffe064
"/usr/src/Python-2.2.1/Lib/os.py", 
    fp=0x810f710) at Python/import.c:772
#5  0x808c380 in load_module (name=0xbfffe4f4 "os",
fp=0x810f710, buf=0xbfffe064
"/usr/src/Python-2.2.1/Lib/os.py", 
    type=1) at Python/import.c:1356
#6  0x808d015 in import_submodule (mod=0x80e105c,
subname=0xbfffe4f4 "os", fullname=0xbfffe4f4 "os")
    at Python/import.c:1895
#7  0x808cbbd in load_next (mod=0x80e105c,
altmod=0x80e105c, p_name=0xbfffe900, buf=0xbfffe4f4 "os", 
    p_buflen=0xbfffe4f0) at Python/import.c:1751
#8  0x808c7eb in import_module_ex (name=0x0,
globals=0x81151cc, locals=0x81151cc, fromlist=0x80e105c)
    at Python/import.c:1602
#9  0x808dd14 in PyImport_ImportModuleEx
(name=0x8110854 "os", globals=0x81151cc,
locals=0x81151cc, fromlist=0x80e105c)
    at Python/import.c:1643
#10 0x80ca8ac in builtin___import__ (self=0x0,
args=0x81153fc) at Python/bltinmodule.c:40
#11 0x80c6e7d in PyCFunction_Call (func=0x8102998,
arg=0x81153fc, kw=0x0) at Objects/methodobject.c:80
#12 0x80a956e in PyObject_Call (func=0x8102998,
arg=0x81153fc, kw=0x0) at Objects/abstract.c:1684
#13 0x80783e0 in PyEval_CallObjectWithKeywords
(func=0x8102998, arg=0x81153fc, kw=0x0) at
Python/ceval.c:3049
#14 0x8076793 in eval_frame (f=0x8115554) at
Python/ceval.c:1839
#15 0x8077bee in PyEval_EvalCodeEx (co=0x81051d0,
globals=0x81151cc, locals=0x81151cc, args=0x0,
argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at
Python/ceval.c:2585
#16 0x8079c60 in PyEval_EvalCode (co=0x81051d0,
globals=0x81151cc, locals=0x81151cc) at Python/ceval.c:483
#17 0x808b53d in PyImport_ExecCodeModuleEx
(name=0xbffff494 "site", co=0x81051d0, 
    pathname=0xbfffeb94
"/usr/src/Python-2.2.1/Lib/site.pyc") at
Python/import.c:502
#18 0x808ba59 in load_source_module (name=0xbffff494
"site", pathname=0xbffff004
"/usr/src/Python-2.2.1/Lib/site.py", 
    fp=0x810f658) at Python/import.c:772
#19 0x808c380 in load_module (name=0xbffff494 "site",
fp=0x810f658, 
    buf=0xbffff004 "/usr/src/Python-2.2.1/Lib/site.py",
type=1) at Python/import.c:1356
#20 0x808d015 in import_submodule (mod=0x80e105c,
subname=0xbffff494 "site", fullname=0xbffff494 "site")
    at Python/import.c:1895
#21 0x808cbbd in load_next (mod=0x80e105c,
altmod=0x80e105c, p_name=0xbffff8a0, buf=0xbffff494
"site", 
    p_buflen=0xbffff490) at Python/import.c:1751
#22 0x808c7eb in import_module_ex (name=0x0,
globals=0x810f5d4, locals=0x810f5d4, fromlist=0x8107adc)
    at Python/import.c:1602
#23 0x808dd14 in PyImport_ImportModuleEx
(name=0x810f5bc "site", globals=0x810f5d4,
locals=0x810f5d4, 
    fromlist=0x8107adc) at Python/import.c:1643
#24 0x80ca8ac in builtin___import__ (self=0x0,
args=0x8107edc) at Python/bltinmodule.c:40
#25 0x80c6e7d in PyCFunction_Call (func=0x8102998,
arg=0x8107edc, kw=0x0) at Objects/methodobject.c:80
#26 0x80a956e in PyObject_Call (func=0x8102998,
arg=0x8107edc, kw=0x0) at Objects/abstract.c:1684
#27 0x80783e0 in PyEval_CallObjectWithKeywords
(func=0x8102998, arg=0x8107edc, kw=0x0) at
Python/ceval.c:3049
#28 0x80a8bee in PyObject_CallFunction
(callable=0x8102998, format=0x80d5707 "OOOO") at
Objects/abstract.c:1725
#29 0x808d4e6 in PyImport_Import
(module_name=0x810f5a8) at Python/import.c:2048
#30 0x808dc53 in PyImport_ImportModule (name=0x80d6ea3
"site") at Python/import.c:1574
#31 0x809448b in initsite () at Python/pythonrun.c:443
#32 0x8092812 in Py_Initialize () at Python/pythonrun.c:173
#33 0x8053387 in Py_Main (argc=4, argv=0xbffffb54) at
Modules/main.c:322
#34 0x8052dca in main (argc=4, argv=0xbffffb54) at
Modules/python.c:10
#35 0x400699cb in __libc_start_main (main=0x8052db4
<main>, argc=4, argv=0xbffffb54, init=0x80521e4 <_init>, 
    fini=0x80cbed4 <_fini>, rtld_fini=0x4000aea0
<_dl_fini>, stack_end=0xbffffb4c)
    at ../sysdeps/generic/libc-start.c:92
y_Initialize () at Python/pythonrun.c:173

(gdb) print u
$1 = (PyObject *) 0x0


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563598&group_id=5470



From noreply@sourceforge.net  Sun Jun  2 23:28:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 02 Jun 2002 15:28:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-563665 ] urllib2 fails on redirects (again?)
Message-ID: <E17EdqL-0002ta-00@usw-sf-web2.sourceforge.net>

Bugs item #563665, was opened at 2002-06-02 18:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563665&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Demaine (edemaine)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 fails on redirects (again?)

Initial Comment:
This looks similar to SF bug 216649, but with somewhat
different symptoms.  Redirection seems to cause an
AttributeError (attempt to access self.fp.read when
self.fp is None).  Simple example:

python -c "import urllib2; urllib2.urlopen
('http://www.yahoo.com/promotions/mom_com97/supermom.html')"

Traceback from Python 2.2.1 attached.  Same behavior
appears with Python 2.2.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563665&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 05:00:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 02 Jun 2002 21:00:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-563730 ] isinstance() fails to identify obj class
Message-ID: <E17Ej0v-0005ms-00@usw-sf-web4.sourceforge.net>

Bugs item #563730, was opened at 2002-06-03 14:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563730&group_id=5470

Category: None
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Jessica Preston (jesspreston)
Assigned to: Nobody/Anonymous (nobody)
Summary: isinstance() fails to identify obj class

Initial Comment:
The problem seems to be that if I create two objects
using the same class
constructor, but having imported the class differently,
the isinstance() method
fails to identify them as being the same. The problem
only occurs (I think)
when cPickle is used, at least, that was how I managed
to reproduce it.

I have attached an example which includes a README and
a couple of directories:

SampleDir contains
- Simple.py (a simple class that has a compare() method
that uses isinstance)
- Main.py

SampleDir/NestedDir contains
- CreatePickle.py (which creates a Simple() object and
pickles it into the cwd)

Main.py unpickles the Simple object created by
CreatePickle.py, then compares it against a newly
created Simple() object using the Simple.compare()
method. It should raise as Assertion error claiming
that the passed object was not a Simple object.
However, it is.

I looked through existing bug reports and found a very
similar one from 2001 with tracking number 467267 -
this was marked as invalid, I think, but I'm not sure
whether this resolves my problem.

The README contains instructions on running the
example, plus my system information.

I am running RedHat7.1, with kernel 2.4.18 (if
relevant) and
the version of python I am using is Python 2.2.1

I hope that this will demonstrate the problem.

Thanks
-jess

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563730&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 06:17:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 02 Jun 2002 22:17:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-563740 ] complex() doesn't use __complex__
Message-ID: <E17EkDi-0006gG-00@usw-sf-web2.sourceforge.net>

Bugs item #563740, was opened at 2002-06-03 01:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563740&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Raymond Hettinger (rhettinger)
Summary: complex() doesn't use __complex__

Initial Comment:
complex() with a new-style instance of a class that
implements __complex__ doesn't work, because it only
looks for __complex__ when the argument is a classic
instance.  It should always look for __complex__ (but
probably after checking for a complex instance).

See
http://mail.python.org/pipermail/python-dev/2002-June/024898.html
and my reply.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563740&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 06:59:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 02 Jun 2002 22:59:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-563750 ] os.tmpfile should use w+b, not w+
Message-ID: <E17EksJ-00070N-00@usw-sf-web2.sourceforge.net>

Bugs item #563750, was opened at 2002-06-03 07:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563750&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex Martelli (aleax)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.tmpfile should use w+b, not w+

Initial Comment:
os.tmpfile is only present on Unix and Windows, and on 
Unix it makes no difference.  On Windows, Microsoft's
docs indicate tmpfile uses mode w+b -- which makes a lot 
of sense as it lets you shunt temporarily to disk binary 
stuff without any ill effect for text stuff.  Unfortunately the 
implementation of os.tmpfile in Modules/posixmodule.c 
calls PyFile_FromFile with 'w+', not 'w+b', so that's what 
gets recorded as the mode attribute of the file object.

So, a careful function which receives a file object 
argument
and checks that its mode contains a 'b' (because it needs
to to binary I/O on the file) will diagnose inexistent 
problems
when it's called with an argument that's a file object 
returned
from os.tmpfile().

Suggested fix: change 'w+' to 'w+b' in posixmodule.c and
in the docs for module os, function tmpfile in each case.

This could only possibly break carelessly coded functions
that check the mode attribute and require it to be identical
to 'w+' when they actually can work perfectly well with
'w+b' (because w+b is what they actually GET, though it
falsely claims to be w+).  I think this hypothetical 
breakage
(I know of no such function, and anybody careful enough 
to
check the mode is likely also careful enough to do the 
RIGHT check) is quite tolerable in exchange for having 
the
os.tmpfile function reflect reality and let careful well-coded
functions work naturally and correctly.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563750&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 12:54:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 04:54:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-555360 ] UTF-16 BOM handling counterintuitive
Message-ID: <E17EqPR-0001cc-00@usw-sf-web2.sourceforge.net>

Bugs item #555360, was opened at 2002-05-13 11:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Stephen J. Turnbull (yaseppochi)
Assigned to: M.-A. Lemburg (lemburg)
Summary: UTF-16 BOM handling counterintuitive

Initial Comment:
A search on "Unicode BOM" doesn't turn up anything related.

Sorry, I don't have a 2.2 or CVS to hand.  Easy enough
to replicate, anyway.  The UTF-16 codec happily
corrupts files by appending a BOM before writing
encoded text to the file:

bash-2.05a$ python
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import codecs
>>> f = codecs.open("/tmp/utf16","w","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = codecs.open("/tmp/utf16","a","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = open("/tmp/utf16","r") 
>>> f.read()
'\xff\xfea\x00\xff\xfea\x00'

Oops.

Also, dir(codecs) shows BOM64* constants are defined
(to what purpose, I have no idea---Microsoft Word files
on Alpha, maybe?), but no BOM8, which actually has some
basis in the standards.  (I think the idea of a UTF-8
signature is a abomination, so you can leave it
out<wink>, but people who do use the BOM as signature
in UTF-8 files would find it useful.)  Hmm ...

>>> codecs.BOM_BE
'\xfe\xff'
>>> codecs.BOM64_BE
'\x00\x00\xfe\xff'
>>> codecs.BOM32_BE
'\xfe\xff'
>>> 

Urk!  I only count 32 bits in BOM64 and 16 bits in
BOM32!  Maybe BOM32_* was intended as an alias for
BOM_*, and BOM64_* was a continuation of the typo, as
it were?

I wonder if this is the right interface, actually. 
Wouldn't prefixBOM() and checkBOM() methods for streams
and strings make more sense?  prefixBOM should be
idempotent, and checkBOM would return either a codec
(with size and endianness determined) or a codec.BOM*
constant.

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

>Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 13:54

Message:
Logged In: YES 
user_id=89016

> The 32 vs. 16 refer to the number of bits in the
> Unicode internal type; they don't refer to the number of
> bits in the mark.

Yes, but unfortunately the constants in codecs are *not*
BOM32_?? and BOM16_??, but BOM64_?? and BOM32_??.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-02 19:16

Message:
Logged In: YES 
user_id=38388

I agree that opening a file in append mode should 
probably be smarter in the sense that the BOM is
only written in case file.seek() points to the beginning
of the file; patches are welcome.

On the other points:
* I don't see the point of adding an 8-bit BOM mark
  (UTF-8 does not depend on byte order).
* The 32 vs. 16 refer to the number of bits in the
  Unicode internal type; they don't refer to the number of 
  bits in the mark.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-05-13 22:43

Message:
Logged In: YES 
user_id=89016

And if you're using a different encoding for the second 
open call, the data will really be corrupted:
f = codecs.open("/tmp/foo","w","utf-8")
f.write("ää")
f = codecs.open("/tmp/foo","a","latin-1")
f.write("ää")

But how should codec.open be able to determine that the 
file is always opened with the same encoding, or which 
encoding was used for the open call last time? And if it 
could would it have to read the content using the old 
encoding and rewrite it using the new encoding to keep the 
file consistent?

I agree that the BOM names are broken.

> I wonder if this is the right interface, actually. 
> Wouldn't prefixBOM() and checkBOM() methods for streams 
> and strings make more sense? prefixBOM should be 
> idempotent, and checkBOM would return either a codec 
> (with size and endianness determined) or a codec.BOM* 
> constant.

You should consider UTF-16 to be a stateful encoding, so if 
you want to do your output in multiple pieces you have to 
use a stateful encoder, i.e. a StreamWriter:

>>> import codecs, cStringIO as StringIO
>>> stream = StringIO.StringIO()
>>> writer = codecs.getwriter("utf-16")(stream)
>>> writer.write(u"a")
>>> writer.write(u"b") 
>>> stream.getvalue()
'\xff\xfea\x00b\x00'


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 13:10:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 05:10:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-555360 ] UTF-16 BOM handling counterintuitive
Message-ID: <E17EqfO-0001lk-00@usw-sf-web2.sourceforge.net>

Bugs item #555360, was opened at 2002-05-13 09:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Stephen J. Turnbull (yaseppochi)
Assigned to: M.-A. Lemburg (lemburg)
Summary: UTF-16 BOM handling counterintuitive

Initial Comment:
A search on "Unicode BOM" doesn't turn up anything related.

Sorry, I don't have a 2.2 or CVS to hand.  Easy enough
to replicate, anyway.  The UTF-16 codec happily
corrupts files by appending a BOM before writing
encoded text to the file:

bash-2.05a$ python
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import codecs
>>> f = codecs.open("/tmp/utf16","w","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = codecs.open("/tmp/utf16","a","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = open("/tmp/utf16","r") 
>>> f.read()
'\xff\xfea\x00\xff\xfea\x00'

Oops.

Also, dir(codecs) shows BOM64* constants are defined
(to what purpose, I have no idea---Microsoft Word files
on Alpha, maybe?), but no BOM8, which actually has some
basis in the standards.  (I think the idea of a UTF-8
signature is a abomination, so you can leave it
out<wink>, but people who do use the BOM as signature
in UTF-8 files would find it useful.)  Hmm ...

>>> codecs.BOM_BE
'\xfe\xff'
>>> codecs.BOM64_BE
'\x00\x00\xfe\xff'
>>> codecs.BOM32_BE
'\xfe\xff'
>>> 

Urk!  I only count 32 bits in BOM64 and 16 bits in
BOM32!  Maybe BOM32_* was intended as an alias for
BOM_*, and BOM64_* was a continuation of the typo, as
it were?

I wonder if this is the right interface, actually. 
Wouldn't prefixBOM() and checkBOM() methods for streams
and strings make more sense?  prefixBOM should be
idempotent, and checkBOM would return either a codec
(with size and endianness determined) or a codec.BOM*
constant.

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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 12:10

Message:
Logged In: YES 
user_id=38388

Hmm, you're right. Something is wrong here.

Perhaps we should add aliases called BOM_UCS2_*
and BOM_UCS4_* and update the documentation
accordingly ?

About the append mode: is file.mode considered to
be part of the file interface or not... I think that a patch
for the UTF-16 codec should check for this attribute
on the stream object to tell whether or not to prepend
the BOM mark.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 11:54

Message:
Logged In: YES 
user_id=89016

> The 32 vs. 16 refer to the number of bits in the
> Unicode internal type; they don't refer to the number of
> bits in the mark.

Yes, but unfortunately the constants in codecs are *not*
BOM32_?? and BOM16_??, but BOM64_?? and BOM32_??.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-02 17:16

Message:
Logged In: YES 
user_id=38388

I agree that opening a file in append mode should 
probably be smarter in the sense that the BOM is
only written in case file.seek() points to the beginning
of the file; patches are welcome.

On the other points:
* I don't see the point of adding an 8-bit BOM mark
  (UTF-8 does not depend on byte order).
* The 32 vs. 16 refer to the number of bits in the
  Unicode internal type; they don't refer to the number of 
  bits in the mark.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-05-13 20:43

Message:
Logged In: YES 
user_id=89016

And if you're using a different encoding for the second 
open call, the data will really be corrupted:
f = codecs.open("/tmp/foo","w","utf-8")
f.write("ää")
f = codecs.open("/tmp/foo","a","latin-1")
f.write("ää")

But how should codec.open be able to determine that the 
file is always opened with the same encoding, or which 
encoding was used for the open call last time? And if it 
could would it have to read the content using the old 
encoding and rewrite it using the new encoding to keep the 
file consistent?

I agree that the BOM names are broken.

> I wonder if this is the right interface, actually. 
> Wouldn't prefixBOM() and checkBOM() methods for streams 
> and strings make more sense? prefixBOM should be 
> idempotent, and checkBOM would return either a codec 
> (with size and endianness determined) or a codec.BOM* 
> constant.

You should consider UTF-16 to be a stateful encoding, so if 
you want to do your output in multiple pieces you have to 
use a stateful encoder, i.e. a StreamWriter:

>>> import codecs, cStringIO as StringIO
>>> stream = StringIO.StringIO()
>>> writer = codecs.getwriter("utf-16")(stream)
>>> writer.write(u"a")
>>> writer.write(u"b") 
>>> stream.getvalue()
'\xff\xfea\x00b\x00'


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 13:38:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 05:38:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-555360 ] UTF-16 BOM handling counterintuitive
Message-ID: <E17Er6S-00025D-00@usw-sf-web2.sourceforge.net>

Bugs item #555360, was opened at 2002-05-13 11:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Stephen J. Turnbull (yaseppochi)
Assigned to: M.-A. Lemburg (lemburg)
Summary: UTF-16 BOM handling counterintuitive

Initial Comment:
A search on "Unicode BOM" doesn't turn up anything related.

Sorry, I don't have a 2.2 or CVS to hand.  Easy enough
to replicate, anyway.  The UTF-16 codec happily
corrupts files by appending a BOM before writing
encoded text to the file:

bash-2.05a$ python
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import codecs
>>> f = codecs.open("/tmp/utf16","w","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = codecs.open("/tmp/utf16","a","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = open("/tmp/utf16","r") 
>>> f.read()
'\xff\xfea\x00\xff\xfea\x00'

Oops.

Also, dir(codecs) shows BOM64* constants are defined
(to what purpose, I have no idea---Microsoft Word files
on Alpha, maybe?), but no BOM8, which actually has some
basis in the standards.  (I think the idea of a UTF-8
signature is a abomination, so you can leave it
out<wink>, but people who do use the BOM as signature
in UTF-8 files would find it useful.)  Hmm ...

>>> codecs.BOM_BE
'\xfe\xff'
>>> codecs.BOM64_BE
'\x00\x00\xfe\xff'
>>> codecs.BOM32_BE
'\xfe\xff'
>>> 

Urk!  I only count 32 bits in BOM64 and 16 bits in
BOM32!  Maybe BOM32_* was intended as an alias for
BOM_*, and BOM64_* was a continuation of the typo, as
it were?

I wonder if this is the right interface, actually. 
Wouldn't prefixBOM() and checkBOM() methods for streams
and strings make more sense?  prefixBOM should be
idempotent, and checkBOM would return either a codec
(with size and endianness determined) or a codec.BOM*
constant.

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

>Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 14:38

Message:
Logged In: YES 
user_id=89016

> Perhaps we should add aliases called BOM_UCS2_*
> and BOM_UCS4_* and update the documentation
> accordingly ?

Sounds reasonable!

If you want, I'll change it (including documentation)

About the append mode: I don't think it's a good idea to try
to fix this. There is much that can go wrong: seeking an odd
number of bytes, mixed endianness on writes, using a
different encoding on the second write. And what about UTF-8
and UTF-7? What should happen if the user seeks into the
middle of a UTF-[78] byte sequence and starts to write?


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 14:10

Message:
Logged In: YES 
user_id=38388

Hmm, you're right. Something is wrong here.

Perhaps we should add aliases called BOM_UCS2_*
and BOM_UCS4_* and update the documentation
accordingly ?

About the append mode: is file.mode considered to
be part of the file interface or not... I think that a patch
for the UTF-16 codec should check for this attribute
on the stream object to tell whether or not to prepend
the BOM mark.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 13:54

Message:
Logged In: YES 
user_id=89016

> The 32 vs. 16 refer to the number of bits in the
> Unicode internal type; they don't refer to the number of
> bits in the mark.

Yes, but unfortunately the constants in codecs are *not*
BOM32_?? and BOM16_??, but BOM64_?? and BOM32_??.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-02 19:16

Message:
Logged In: YES 
user_id=38388

I agree that opening a file in append mode should 
probably be smarter in the sense that the BOM is
only written in case file.seek() points to the beginning
of the file; patches are welcome.

On the other points:
* I don't see the point of adding an 8-bit BOM mark
  (UTF-8 does not depend on byte order).
* The 32 vs. 16 refer to the number of bits in the
  Unicode internal type; they don't refer to the number of 
  bits in the mark.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-05-13 22:43

Message:
Logged In: YES 
user_id=89016

And if you're using a different encoding for the second 
open call, the data will really be corrupted:
f = codecs.open("/tmp/foo","w","utf-8")
f.write("ää")
f = codecs.open("/tmp/foo","a","latin-1")
f.write("ää")

But how should codec.open be able to determine that the 
file is always opened with the same encoding, or which 
encoding was used for the open call last time? And if it 
could would it have to read the content using the old 
encoding and rewrite it using the new encoding to keep the 
file consistent?

I agree that the BOM names are broken.

> I wonder if this is the right interface, actually. 
> Wouldn't prefixBOM() and checkBOM() methods for streams 
> and strings make more sense? prefixBOM should be 
> idempotent, and checkBOM would return either a codec 
> (with size and endianness determined) or a codec.BOM* 
> constant.

You should consider UTF-16 to be a stateful encoding, so if 
you want to do your output in multiple pieces you have to 
use a stateful encoder, i.e. a StreamWriter:

>>> import codecs, cStringIO as StringIO
>>> stream = StringIO.StringIO()
>>> writer = codecs.getwriter("utf-16")(stream)
>>> writer.write(u"a")
>>> writer.write(u"b") 
>>> stream.getvalue()
'\xff\xfea\x00b\x00'


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 13:57:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 05:57:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-555360 ] UTF-16 BOM handling counterintuitive
Message-ID: <E17ErP4-0001zx-00@usw-sf-web4.sourceforge.net>

Bugs item #555360, was opened at 2002-05-13 09:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Stephen J. Turnbull (yaseppochi)
>Assigned to: Walter Dörwald (doerwalter)
Summary: UTF-16 BOM handling counterintuitive

Initial Comment:
A search on "Unicode BOM" doesn't turn up anything related.

Sorry, I don't have a 2.2 or CVS to hand.  Easy enough
to replicate, anyway.  The UTF-16 codec happily
corrupts files by appending a BOM before writing
encoded text to the file:

bash-2.05a$ python
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import codecs
>>> f = codecs.open("/tmp/utf16","w","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = codecs.open("/tmp/utf16","a","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = open("/tmp/utf16","r") 
>>> f.read()
'\xff\xfea\x00\xff\xfea\x00'

Oops.

Also, dir(codecs) shows BOM64* constants are defined
(to what purpose, I have no idea---Microsoft Word files
on Alpha, maybe?), but no BOM8, which actually has some
basis in the standards.  (I think the idea of a UTF-8
signature is a abomination, so you can leave it
out<wink>, but people who do use the BOM as signature
in UTF-8 files would find it useful.)  Hmm ...

>>> codecs.BOM_BE
'\xfe\xff'
>>> codecs.BOM64_BE
'\x00\x00\xfe\xff'
>>> codecs.BOM32_BE
'\xfe\xff'
>>> 

Urk!  I only count 32 bits in BOM64 and 16 bits in
BOM32!  Maybe BOM32_* was intended as an alias for
BOM_*, and BOM64_* was a continuation of the typo, as
it were?

I wonder if this is the right interface, actually. 
Wouldn't prefixBOM() and checkBOM() methods for streams
and strings make more sense?  prefixBOM should be
idempotent, and checkBOM would return either a codec
(with size and endianness determined) or a codec.BOM*
constant.

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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 12:57

Message:
Logged In: YES 
user_id=38388

Ok, please do and then close the bug.

About the append mode: I think you're right. It's
not worth the trouble. Applications can easily figure
this out for themselves (and then use the proper
non-BOM prepending codec name).

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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 12:38

Message:
Logged In: YES 
user_id=89016

> Perhaps we should add aliases called BOM_UCS2_*
> and BOM_UCS4_* and update the documentation
> accordingly ?

Sounds reasonable!

If you want, I'll change it (including documentation)

About the append mode: I don't think it's a good idea to try
to fix this. There is much that can go wrong: seeking an odd
number of bytes, mixed endianness on writes, using a
different encoding on the second write. And what about UTF-8
and UTF-7? What should happen if the user seeks into the
middle of a UTF-[78] byte sequence and starts to write?


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 12:10

Message:
Logged In: YES 
user_id=38388

Hmm, you're right. Something is wrong here.

Perhaps we should add aliases called BOM_UCS2_*
and BOM_UCS4_* and update the documentation
accordingly ?

About the append mode: is file.mode considered to
be part of the file interface or not... I think that a patch
for the UTF-16 codec should check for this attribute
on the stream object to tell whether or not to prepend
the BOM mark.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 11:54

Message:
Logged In: YES 
user_id=89016

> The 32 vs. 16 refer to the number of bits in the
> Unicode internal type; they don't refer to the number of
> bits in the mark.

Yes, but unfortunately the constants in codecs are *not*
BOM32_?? and BOM16_??, but BOM64_?? and BOM32_??.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-02 17:16

Message:
Logged In: YES 
user_id=38388

I agree that opening a file in append mode should 
probably be smarter in the sense that the BOM is
only written in case file.seek() points to the beginning
of the file; patches are welcome.

On the other points:
* I don't see the point of adding an 8-bit BOM mark
  (UTF-8 does not depend on byte order).
* The 32 vs. 16 refer to the number of bits in the
  Unicode internal type; they don't refer to the number of 
  bits in the mark.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-05-13 20:43

Message:
Logged In: YES 
user_id=89016

And if you're using a different encoding for the second 
open call, the data will really be corrupted:
f = codecs.open("/tmp/foo","w","utf-8")
f.write("ää")
f = codecs.open("/tmp/foo","a","latin-1")
f.write("ää")

But how should codec.open be able to determine that the 
file is always opened with the same encoding, or which 
encoding was used for the open call last time? And if it 
could would it have to read the content using the old 
encoding and rewrite it using the new encoding to keep the 
file consistent?

I agree that the BOM names are broken.

> I wonder if this is the right interface, actually. 
> Wouldn't prefixBOM() and checkBOM() methods for streams 
> and strings make more sense? prefixBOM should be 
> idempotent, and checkBOM would return either a codec 
> (with size and endianness determined) or a codec.BOM* 
> constant.

You should consider UTF-16 to be a stateful encoding, so if 
you want to do your output in multiple pieces you have to 
use a stateful encoder, i.e. a StreamWriter:

>>> import codecs, cStringIO as StringIO
>>> stream = StringIO.StringIO()
>>> writer = codecs.getwriter("utf-16")(stream)
>>> writer.write(u"a")
>>> writer.write(u"b") 
>>> stream.getvalue()
'\xff\xfea\x00b\x00'


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 14:35:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 06:35:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-555360 ] UTF-16 BOM handling counterintuitive
Message-ID: <E17ErzL-0004Hk-00@usw-sf-web3.sourceforge.net>

Bugs item #555360, was opened at 2002-05-13 11:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Stephen J. Turnbull (yaseppochi)
Assigned to: Walter Dörwald (doerwalter)
Summary: UTF-16 BOM handling counterintuitive

Initial Comment:
A search on "Unicode BOM" doesn't turn up anything related.

Sorry, I don't have a 2.2 or CVS to hand.  Easy enough
to replicate, anyway.  The UTF-16 codec happily
corrupts files by appending a BOM before writing
encoded text to the file:

bash-2.05a$ python
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import codecs
>>> f = codecs.open("/tmp/utf16","w","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = codecs.open("/tmp/utf16","a","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = open("/tmp/utf16","r") 
>>> f.read()
'\xff\xfea\x00\xff\xfea\x00'

Oops.

Also, dir(codecs) shows BOM64* constants are defined
(to what purpose, I have no idea---Microsoft Word files
on Alpha, maybe?), but no BOM8, which actually has some
basis in the standards.  (I think the idea of a UTF-8
signature is a abomination, so you can leave it
out<wink>, but people who do use the BOM as signature
in UTF-8 files would find it useful.)  Hmm ...

>>> codecs.BOM_BE
'\xfe\xff'
>>> codecs.BOM64_BE
'\x00\x00\xfe\xff'
>>> codecs.BOM32_BE
'\xfe\xff'
>>> 

Urk!  I only count 32 bits in BOM64 and 16 bits in
BOM32!  Maybe BOM32_* was intended as an alias for
BOM_*, and BOM64_* was a continuation of the typo, as
it were?

I wonder if this is the right interface, actually. 
Wouldn't prefixBOM() and checkBOM() methods for streams
and strings make more sense?  prefixBOM should be
idempotent, and checkBOM would return either a codec
(with size and endianness determined) or a codec.BOM*
constant.

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

>Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 15:35

Message:
Logged In: YES 
user_id=89016

codecs.py says:
BOM = struct.pack('=H', 0xFEFF)
this is not correct in wide build. Should this be changed to
if sys.maxunicode>0xffff:
   BOM = struct.pack('=L', 0x0000FEFF)
else:
   BOM = struct.pack('=H', 0xFEFF)
(with two additional constants BOM_UCS2 and BOM_UCS4?)

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 14:57

Message:
Logged In: YES 
user_id=38388

Ok, please do and then close the bug.

About the append mode: I think you're right. It's
not worth the trouble. Applications can easily figure
this out for themselves (and then use the proper
non-BOM prepending codec name).

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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 14:38

Message:
Logged In: YES 
user_id=89016

> Perhaps we should add aliases called BOM_UCS2_*
> and BOM_UCS4_* and update the documentation
> accordingly ?

Sounds reasonable!

If you want, I'll change it (including documentation)

About the append mode: I don't think it's a good idea to try
to fix this. There is much that can go wrong: seeking an odd
number of bytes, mixed endianness on writes, using a
different encoding on the second write. And what about UTF-8
and UTF-7? What should happen if the user seeks into the
middle of a UTF-[78] byte sequence and starts to write?


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 14:10

Message:
Logged In: YES 
user_id=38388

Hmm, you're right. Something is wrong here.

Perhaps we should add aliases called BOM_UCS2_*
and BOM_UCS4_* and update the documentation
accordingly ?

About the append mode: is file.mode considered to
be part of the file interface or not... I think that a patch
for the UTF-16 codec should check for this attribute
on the stream object to tell whether or not to prepend
the BOM mark.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 13:54

Message:
Logged In: YES 
user_id=89016

> The 32 vs. 16 refer to the number of bits in the
> Unicode internal type; they don't refer to the number of
> bits in the mark.

Yes, but unfortunately the constants in codecs are *not*
BOM32_?? and BOM16_??, but BOM64_?? and BOM32_??.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-02 19:16

Message:
Logged In: YES 
user_id=38388

I agree that opening a file in append mode should 
probably be smarter in the sense that the BOM is
only written in case file.seek() points to the beginning
of the file; patches are welcome.

On the other points:
* I don't see the point of adding an 8-bit BOM mark
  (UTF-8 does not depend on byte order).
* The 32 vs. 16 refer to the number of bits in the
  Unicode internal type; they don't refer to the number of 
  bits in the mark.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-05-13 22:43

Message:
Logged In: YES 
user_id=89016

And if you're using a different encoding for the second 
open call, the data will really be corrupted:
f = codecs.open("/tmp/foo","w","utf-8")
f.write("ää")
f = codecs.open("/tmp/foo","a","latin-1")
f.write("ää")

But how should codec.open be able to determine that the 
file is always opened with the same encoding, or which 
encoding was used for the open call last time? And if it 
could would it have to read the content using the old 
encoding and rewrite it using the new encoding to keep the 
file consistent?

I agree that the BOM names are broken.

> I wonder if this is the right interface, actually. 
> Wouldn't prefixBOM() and checkBOM() methods for streams 
> and strings make more sense? prefixBOM should be 
> idempotent, and checkBOM would return either a codec 
> (with size and endianness determined) or a codec.BOM* 
> constant.

You should consider UTF-16 to be a stateful encoding, so if 
you want to do your output in multiple pieces you have to 
use a stateful encoder, i.e. a StreamWriter:

>>> import codecs, cStringIO as StringIO
>>> stream = StringIO.StringIO()
>>> writer = codecs.getwriter("utf-16")(stream)
>>> writer.write(u"a")
>>> writer.write(u"b") 
>>> stream.getvalue()
'\xff\xfea\x00b\x00'


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 14:58:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 06:58:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-555360 ] UTF-16 BOM handling counterintuitive
Message-ID: <E17EsLt-0007aO-00@usw-sf-web1.sourceforge.net>

Bugs item #555360, was opened at 2002-05-13 09:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Stephen J. Turnbull (yaseppochi)
Assigned to: Walter Dörwald (doerwalter)
Summary: UTF-16 BOM handling counterintuitive

Initial Comment:
A search on "Unicode BOM" doesn't turn up anything related.

Sorry, I don't have a 2.2 or CVS to hand.  Easy enough
to replicate, anyway.  The UTF-16 codec happily
corrupts files by appending a BOM before writing
encoded text to the file:

bash-2.05a$ python
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import codecs
>>> f = codecs.open("/tmp/utf16","w","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = codecs.open("/tmp/utf16","a","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = open("/tmp/utf16","r") 
>>> f.read()
'\xff\xfea\x00\xff\xfea\x00'

Oops.

Also, dir(codecs) shows BOM64* constants are defined
(to what purpose, I have no idea---Microsoft Word files
on Alpha, maybe?), but no BOM8, which actually has some
basis in the standards.  (I think the idea of a UTF-8
signature is a abomination, so you can leave it
out<wink>, but people who do use the BOM as signature
in UTF-8 files would find it useful.)  Hmm ...

>>> codecs.BOM_BE
'\xfe\xff'
>>> codecs.BOM64_BE
'\x00\x00\xfe\xff'
>>> codecs.BOM32_BE
'\xfe\xff'
>>> 

Urk!  I only count 32 bits in BOM64 and 16 bits in
BOM32!  Maybe BOM32_* was intended as an alias for
BOM_*, and BOM64_* was a continuation of the typo, as
it were?

I wonder if this is the right interface, actually. 
Wouldn't prefixBOM() and checkBOM() methods for streams
and strings make more sense?  prefixBOM should be
idempotent, and checkBOM would return either a codec
(with size and endianness determined) or a codec.BOM*
constant.

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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 13:58

Message:
Logged In: YES 
user_id=38388

The only requirement we have for BOM is that it matches
the BOM mark which actually gets written to the file.
The purpose of BOM_UCS2_ and BOM_UCS4_ is
to be able to figure out which underlying Unicode
version was used.

I'm not even sure whether there's a standard for this on
64-bit machines; could be that Microsoft invented something
here... (maybe that's also where the old names originated,
I don't know)

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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 13:35

Message:
Logged In: YES 
user_id=89016

codecs.py says:
BOM = struct.pack('=H', 0xFEFF)
this is not correct in wide build. Should this be changed to
if sys.maxunicode>0xffff:
   BOM = struct.pack('=L', 0x0000FEFF)
else:
   BOM = struct.pack('=H', 0xFEFF)
(with two additional constants BOM_UCS2 and BOM_UCS4?)

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 12:57

Message:
Logged In: YES 
user_id=38388

Ok, please do and then close the bug.

About the append mode: I think you're right. It's
not worth the trouble. Applications can easily figure
this out for themselves (and then use the proper
non-BOM prepending codec name).

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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 12:38

Message:
Logged In: YES 
user_id=89016

> Perhaps we should add aliases called BOM_UCS2_*
> and BOM_UCS4_* and update the documentation
> accordingly ?

Sounds reasonable!

If you want, I'll change it (including documentation)

About the append mode: I don't think it's a good idea to try
to fix this. There is much that can go wrong: seeking an odd
number of bytes, mixed endianness on writes, using a
different encoding on the second write. And what about UTF-8
and UTF-7? What should happen if the user seeks into the
middle of a UTF-[78] byte sequence and starts to write?


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 12:10

Message:
Logged In: YES 
user_id=38388

Hmm, you're right. Something is wrong here.

Perhaps we should add aliases called BOM_UCS2_*
and BOM_UCS4_* and update the documentation
accordingly ?

About the append mode: is file.mode considered to
be part of the file interface or not... I think that a patch
for the UTF-16 codec should check for this attribute
on the stream object to tell whether or not to prepend
the BOM mark.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 11:54

Message:
Logged In: YES 
user_id=89016

> The 32 vs. 16 refer to the number of bits in the
> Unicode internal type; they don't refer to the number of
> bits in the mark.

Yes, but unfortunately the constants in codecs are *not*
BOM32_?? and BOM16_??, but BOM64_?? and BOM32_??.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-02 17:16

Message:
Logged In: YES 
user_id=38388

I agree that opening a file in append mode should 
probably be smarter in the sense that the BOM is
only written in case file.seek() points to the beginning
of the file; patches are welcome.

On the other points:
* I don't see the point of adding an 8-bit BOM mark
  (UTF-8 does not depend on byte order).
* The 32 vs. 16 refer to the number of bits in the
  Unicode internal type; they don't refer to the number of 
  bits in the mark.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-05-13 20:43

Message:
Logged In: YES 
user_id=89016

And if you're using a different encoding for the second 
open call, the data will really be corrupted:
f = codecs.open("/tmp/foo","w","utf-8")
f.write("ää")
f = codecs.open("/tmp/foo","a","latin-1")
f.write("ää")

But how should codec.open be able to determine that the 
file is always opened with the same encoding, or which 
encoding was used for the open call last time? And if it 
could would it have to read the content using the old 
encoding and rewrite it using the new encoding to keep the 
file consistent?

I agree that the BOM names are broken.

> I wonder if this is the right interface, actually. 
> Wouldn't prefixBOM() and checkBOM() methods for streams 
> and strings make more sense? prefixBOM should be 
> idempotent, and checkBOM would return either a codec 
> (with size and endianness determined) or a codec.BOM* 
> constant.

You should consider UTF-16 to be a stateful encoding, so if 
you want to do your output in multiple pieces you have to 
use a stateful encoder, i.e. a StreamWriter:

>>> import codecs, cStringIO as StringIO
>>> stream = StringIO.StringIO()
>>> writer = codecs.getwriter("utf-16")(stream)
>>> writer.write(u"a")
>>> writer.write(u"b") 
>>> stream.getvalue()
'\xff\xfea\x00b\x00'


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 15:54:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 07:54:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-555360 ] UTF-16 BOM handling counterintuitive
Message-ID: <E17EtEU-0004nK-00@usw-sf-web3.sourceforge.net>

Bugs item #555360, was opened at 2002-05-13 11:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Stephen J. Turnbull (yaseppochi)
Assigned to: Walter Dörwald (doerwalter)
Summary: UTF-16 BOM handling counterintuitive

Initial Comment:
A search on "Unicode BOM" doesn't turn up anything related.

Sorry, I don't have a 2.2 or CVS to hand.  Easy enough
to replicate, anyway.  The UTF-16 codec happily
corrupts files by appending a BOM before writing
encoded text to the file:

bash-2.05a$ python
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import codecs
>>> f = codecs.open("/tmp/utf16","w","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = codecs.open("/tmp/utf16","a","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = open("/tmp/utf16","r") 
>>> f.read()
'\xff\xfea\x00\xff\xfea\x00'

Oops.

Also, dir(codecs) shows BOM64* constants are defined
(to what purpose, I have no idea---Microsoft Word files
on Alpha, maybe?), but no BOM8, which actually has some
basis in the standards.  (I think the idea of a UTF-8
signature is a abomination, so you can leave it
out<wink>, but people who do use the BOM as signature
in UTF-8 files would find it useful.)  Hmm ...

>>> codecs.BOM_BE
'\xfe\xff'
>>> codecs.BOM64_BE
'\x00\x00\xfe\xff'
>>> codecs.BOM32_BE
'\xfe\xff'
>>> 

Urk!  I only count 32 bits in BOM64 and 16 bits in
BOM32!  Maybe BOM32_* was intended as an alias for
BOM_*, and BOM64_* was a continuation of the typo, as
it were?

I wonder if this is the right interface, actually. 
Wouldn't prefixBOM() and checkBOM() methods for streams
and strings make more sense?  prefixBOM should be
idempotent, and checkBOM would return either a codec
(with size and endianness determined) or a codec.BOM*
constant.

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

>Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 16:54

Message:
Logged In: YES 
user_id=89016

> The only requirement we have for BOM is that it matches
> the BOM mark which actually gets written to the file.

But this is independent from the internal byte size of the
character type. UTF-16 always writes two bytes (except for
surrogates).

The attached diff.txt shows what I think the BOM stuff
should look like.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 15:58

Message:
Logged In: YES 
user_id=38388

The only requirement we have for BOM is that it matches
the BOM mark which actually gets written to the file.
The purpose of BOM_UCS2_ and BOM_UCS4_ is
to be able to figure out which underlying Unicode
version was used.

I'm not even sure whether there's a standard for this on
64-bit machines; could be that Microsoft invented something
here... (maybe that's also where the old names originated,
I don't know)

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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 15:35

Message:
Logged In: YES 
user_id=89016

codecs.py says:
BOM = struct.pack('=H', 0xFEFF)
this is not correct in wide build. Should this be changed to
if sys.maxunicode>0xffff:
   BOM = struct.pack('=L', 0x0000FEFF)
else:
   BOM = struct.pack('=H', 0xFEFF)
(with two additional constants BOM_UCS2 and BOM_UCS4?)

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 14:57

Message:
Logged In: YES 
user_id=38388

Ok, please do and then close the bug.

About the append mode: I think you're right. It's
not worth the trouble. Applications can easily figure
this out for themselves (and then use the proper
non-BOM prepending codec name).

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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 14:38

Message:
Logged In: YES 
user_id=89016

> Perhaps we should add aliases called BOM_UCS2_*
> and BOM_UCS4_* and update the documentation
> accordingly ?

Sounds reasonable!

If you want, I'll change it (including documentation)

About the append mode: I don't think it's a good idea to try
to fix this. There is much that can go wrong: seeking an odd
number of bytes, mixed endianness on writes, using a
different encoding on the second write. And what about UTF-8
and UTF-7? What should happen if the user seeks into the
middle of a UTF-[78] byte sequence and starts to write?


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 14:10

Message:
Logged In: YES 
user_id=38388

Hmm, you're right. Something is wrong here.

Perhaps we should add aliases called BOM_UCS2_*
and BOM_UCS4_* and update the documentation
accordingly ?

About the append mode: is file.mode considered to
be part of the file interface or not... I think that a patch
for the UTF-16 codec should check for this attribute
on the stream object to tell whether or not to prepend
the BOM mark.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 13:54

Message:
Logged In: YES 
user_id=89016

> The 32 vs. 16 refer to the number of bits in the
> Unicode internal type; they don't refer to the number of
> bits in the mark.

Yes, but unfortunately the constants in codecs are *not*
BOM32_?? and BOM16_??, but BOM64_?? and BOM32_??.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-02 19:16

Message:
Logged In: YES 
user_id=38388

I agree that opening a file in append mode should 
probably be smarter in the sense that the BOM is
only written in case file.seek() points to the beginning
of the file; patches are welcome.

On the other points:
* I don't see the point of adding an 8-bit BOM mark
  (UTF-8 does not depend on byte order).
* The 32 vs. 16 refer to the number of bits in the
  Unicode internal type; they don't refer to the number of 
  bits in the mark.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-05-13 22:43

Message:
Logged In: YES 
user_id=89016

And if you're using a different encoding for the second 
open call, the data will really be corrupted:
f = codecs.open("/tmp/foo","w","utf-8")
f.write("ää")
f = codecs.open("/tmp/foo","a","latin-1")
f.write("ää")

But how should codec.open be able to determine that the 
file is always opened with the same encoding, or which 
encoding was used for the open call last time? And if it 
could would it have to read the content using the old 
encoding and rewrite it using the new encoding to keep the 
file consistent?

I agree that the BOM names are broken.

> I wonder if this is the right interface, actually. 
> Wouldn't prefixBOM() and checkBOM() methods for streams 
> and strings make more sense? prefixBOM should be 
> idempotent, and checkBOM would return either a codec 
> (with size and endianness determined) or a codec.BOM* 
> constant.

You should consider UTF-16 to be a stateful encoding, so if 
you want to do your output in multiple pieces you have to 
use a stateful encoder, i.e. a StreamWriter:

>>> import codecs, cStringIO as StringIO
>>> stream = StringIO.StringIO()
>>> writer = codecs.getwriter("utf-16")(stream)
>>> writer.write(u"a")
>>> writer.write(u"b") 
>>> stream.getvalue()
'\xff\xfea\x00b\x00'


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 16:09:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 08:09:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-563915 ] getttext defaults with unicode
Message-ID: <E17EtSm-0003Nv-00@usw-sf-web2.sourceforge.net>

Bugs item #563915, was opened at 2002-06-03 15:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563915&group_id=5470

Category: Unicode
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Rikard Anglerud (anglerud)
Assigned to: M.-A. Lemburg (lemburg)
Summary: getttext defaults with unicode

Initial Comment:
When using gettext, and a token is not translated, for
example:
print _('Foo')
the output will be 'Foo', as expected. 
However, if that entry is:
print _(u'Foo')
we get:
Traceback (most recent call last):
  File "./translation.py", line 12, in ?
    print _(u'Foo')
  File "/usr/lib/python2.2/gettext.py", line 195, in
ugettext
    return unicode(tmsg, self._charset)
TypeError: decoding Unicode is not supported

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563915&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 16:41:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 08:41:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-555360 ] UTF-16 BOM handling counterintuitive
Message-ID: <E17Etxe-0003Z1-00@usw-sf-web2.sourceforge.net>

Bugs item #555360, was opened at 2002-05-13 11:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Stephen J. Turnbull (yaseppochi)
Assigned to: Walter Dörwald (doerwalter)
Summary: UTF-16 BOM handling counterintuitive

Initial Comment:
A search on "Unicode BOM" doesn't turn up anything related.

Sorry, I don't have a 2.2 or CVS to hand.  Easy enough
to replicate, anyway.  The UTF-16 codec happily
corrupts files by appending a BOM before writing
encoded text to the file:

bash-2.05a$ python
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import codecs
>>> f = codecs.open("/tmp/utf16","w","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = codecs.open("/tmp/utf16","a","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = open("/tmp/utf16","r") 
>>> f.read()
'\xff\xfea\x00\xff\xfea\x00'

Oops.

Also, dir(codecs) shows BOM64* constants are defined
(to what purpose, I have no idea---Microsoft Word files
on Alpha, maybe?), but no BOM8, which actually has some
basis in the standards.  (I think the idea of a UTF-8
signature is a abomination, so you can leave it
out<wink>, but people who do use the BOM as signature
in UTF-8 files would find it useful.)  Hmm ...

>>> codecs.BOM_BE
'\xfe\xff'
>>> codecs.BOM64_BE
'\x00\x00\xfe\xff'
>>> codecs.BOM32_BE
'\xfe\xff'
>>> 

Urk!  I only count 32 bits in BOM64 and 16 bits in
BOM32!  Maybe BOM32_* was intended as an alias for
BOM_*, and BOM64_* was a continuation of the typo, as
it were?

I wonder if this is the right interface, actually. 
Wouldn't prefixBOM() and checkBOM() methods for streams
and strings make more sense?  prefixBOM should be
idempotent, and checkBOM would return either a codec
(with size and endianness determined) or a codec.BOM*
constant.

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

>Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 17:41

Message:
Logged In: YES 
user_id=89016

In old code BOM, BOM_LE and BOM_BE are all 16bit, so to be
backwards compatible maybe the attached path diff2.txt
should be applied instead.

But this feels strange, because I'd expect that for a
--enable-unicode=ucs2 build codecs.BOM==codecs.BOM_UCS2 and
for an --enable-unicode=ucs4 build codecs.BOM==codecs.BOM_UCS4.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 16:54

Message:
Logged In: YES 
user_id=89016

> The only requirement we have for BOM is that it matches
> the BOM mark which actually gets written to the file.

But this is independent from the internal byte size of the
character type. UTF-16 always writes two bytes (except for
surrogates).

The attached diff.txt shows what I think the BOM stuff
should look like.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 15:58

Message:
Logged In: YES 
user_id=38388

The only requirement we have for BOM is that it matches
the BOM mark which actually gets written to the file.
The purpose of BOM_UCS2_ and BOM_UCS4_ is
to be able to figure out which underlying Unicode
version was used.

I'm not even sure whether there's a standard for this on
64-bit machines; could be that Microsoft invented something
here... (maybe that's also where the old names originated,
I don't know)

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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 15:35

Message:
Logged In: YES 
user_id=89016

codecs.py says:
BOM = struct.pack('=H', 0xFEFF)
this is not correct in wide build. Should this be changed to
if sys.maxunicode>0xffff:
   BOM = struct.pack('=L', 0x0000FEFF)
else:
   BOM = struct.pack('=H', 0xFEFF)
(with two additional constants BOM_UCS2 and BOM_UCS4?)

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 14:57

Message:
Logged In: YES 
user_id=38388

Ok, please do and then close the bug.

About the append mode: I think you're right. It's
not worth the trouble. Applications can easily figure
this out for themselves (and then use the proper
non-BOM prepending codec name).

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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 14:38

Message:
Logged In: YES 
user_id=89016

> Perhaps we should add aliases called BOM_UCS2_*
> and BOM_UCS4_* and update the documentation
> accordingly ?

Sounds reasonable!

If you want, I'll change it (including documentation)

About the append mode: I don't think it's a good idea to try
to fix this. There is much that can go wrong: seeking an odd
number of bytes, mixed endianness on writes, using a
different encoding on the second write. And what about UTF-8
and UTF-7? What should happen if the user seeks into the
middle of a UTF-[78] byte sequence and starts to write?


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 14:10

Message:
Logged In: YES 
user_id=38388

Hmm, you're right. Something is wrong here.

Perhaps we should add aliases called BOM_UCS2_*
and BOM_UCS4_* and update the documentation
accordingly ?

About the append mode: is file.mode considered to
be part of the file interface or not... I think that a patch
for the UTF-16 codec should check for this attribute
on the stream object to tell whether or not to prepend
the BOM mark.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 13:54

Message:
Logged In: YES 
user_id=89016

> The 32 vs. 16 refer to the number of bits in the
> Unicode internal type; they don't refer to the number of
> bits in the mark.

Yes, but unfortunately the constants in codecs are *not*
BOM32_?? and BOM16_??, but BOM64_?? and BOM32_??.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-02 19:16

Message:
Logged In: YES 
user_id=38388

I agree that opening a file in append mode should 
probably be smarter in the sense that the BOM is
only written in case file.seek() points to the beginning
of the file; patches are welcome.

On the other points:
* I don't see the point of adding an 8-bit BOM mark
  (UTF-8 does not depend on byte order).
* The 32 vs. 16 refer to the number of bits in the
  Unicode internal type; they don't refer to the number of 
  bits in the mark.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-05-13 22:43

Message:
Logged In: YES 
user_id=89016

And if you're using a different encoding for the second 
open call, the data will really be corrupted:
f = codecs.open("/tmp/foo","w","utf-8")
f.write("ää")
f = codecs.open("/tmp/foo","a","latin-1")
f.write("ää")

But how should codec.open be able to determine that the 
file is always opened with the same encoding, or which 
encoding was used for the open call last time? And if it 
could would it have to read the content using the old 
encoding and rewrite it using the new encoding to keep the 
file consistent?

I agree that the BOM names are broken.

> I wonder if this is the right interface, actually. 
> Wouldn't prefixBOM() and checkBOM() methods for streams 
> and strings make more sense? prefixBOM should be 
> idempotent, and checkBOM would return either a codec 
> (with size and endianness determined) or a codec.BOM* 
> constant.

You should consider UTF-16 to be a stateful encoding, so if 
you want to do your output in multiple pieces you have to 
use a stateful encoder, i.e. a StreamWriter:

>>> import codecs, cStringIO as StringIO
>>> stream = StringIO.StringIO()
>>> writer = codecs.getwriter("utf-16")(stream)
>>> writer.write(u"a")
>>> writer.write(u"b") 
>>> stream.getvalue()
'\xff\xfea\x00b\x00'


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 17:17:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 09:17:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-563665 ] urllib2 can't cope with error response
Message-ID: <E17EuVy-0003lc-00@usw-sf-web2.sourceforge.net>

Bugs item #563665, was opened at 2002-06-02 22:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563665&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Demaine (edemaine)
>Assigned to: Jeremy Hylton (jhylton)
>Summary: urllib2 can't cope with error response

Initial Comment:
This looks similar to SF bug 216649, but with somewhat
different symptoms.  Redirection seems to cause an
AttributeError (attempt to access self.fp.read when
self.fp is None).  Simple example:

python -c "import urllib2; urllib2.urlopen
('http://www.yahoo.com/promotions/mom_com97/supermom.html')"

Traceback from Python 2.2.1 attached.  Same behavior
appears with Python 2.2.

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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-03 16:17

Message:
Logged In: YES 
user_id=31392

I haven't looked at 216649 yet, but this particular
traceback is caused by a problem loading the redirected url.
 If you load 
http://promotions.yahoo.com/promotions/mom_com97/supermom.html,
you'll see the same failure without invoking an redirect
machinery.

My first guess is that the yahoo server is sending an
invalid response and the httplib isn't being generous enough
in skipping the garbage and looking for the valid response
data.  Here's a brief trace of httplib activity:
>>> import httplib
>>> h = httplib.HTTP('promotions.yahoo.com')
>>> h.set_debuglevel(2)
>>> h.putrequest("GET /promotions/mom_com97/supermom.html")   
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: putrequest() takes at least 3 arguments (2 given)
>>> h.putrequest("GET", "/promotions/mom_com97/supermom.html")
connect: (promotions.yahoo.com, 80)
send: 'GET /promotions/mom_com97/supermom.html HTTP/1.0\r\n'
>>> h.endheaders()
send: '\r\n'
>>> h.getreply()
reply: '#\x0f\x01yhh00000011\x010\x01HTTP/1.0 200 OK\n'
(-1, '#\x0f\x01yhh00000011\x010\x01HTTP/1.0 200 OK\n', None)

Not sure what the text starting with a hash is all about.

Of course, urllib2 has a bug that prevents it from reporting
anything useful about this error.  That needs to be fixed.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563665&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 17:49:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 09:49:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E17Ev0u-0005Th-00@usw-sf-web3.sourceforge.net>

Bugs item #535545, was opened at 2002-03-27 03:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Martin v. Löwis (loewis)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



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

Comment By: Paul Boddie (pboddie)
Date: 2002-06-03 18:49

Message:
Logged In: YES 
user_id=226443

This can be fixed by a rearrangement of the conditional 
preprocessor statements at around line 1236 of 
Modules/posixmodule.c as indicated by a patch file I'm going 
to try and attach.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 19:57

Message:
Logged In: YES 
user_id=21627

Type 'bt' at the gdb prompt to get a backtrace. In the
specific case, it is also helpful to type 'print u' to get
the value of u at the time of the crash.

Closing this report again.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 19:51

Message:
Logged In: YES 
user_id=133413

Okay, this probably shows something. I add it here in case
you have a comment on how to submit the bug. But if you
don't, I'll just put in a report on a "dumps core" bug with
this included:

gdb ./python ./core
GNU gdb 4.17.0.11 with Linux support
...
This GDB was configured as "i386-redhat-linux"...
Core was generated by `./python'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libpthread.so.0...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.
#0  0x8075732 in eval_frame (f=0x8124f94) at Python/ceval.c:1310
1310                            Py_DECREF(u);


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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 19:47

Message:
Logged In: YES 
user_id=133413

Yes, close this one. Not sure how to analyze this:

# ./python -E ./setup.py build
Segmentation fault (core dumped)

Never have learned the tools for analyzing the dumped core. 

Even just ./python dumps core. My current kernel is
2.4.19-pre9-ac3 - updated since this bug report was
submitted - if that can be pertinent.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 19:37

Message:
Logged In: YES 
user_id=21627

This is very strange indeed. It does look like a different
bug, so I would like to close this one. I have committed
this change as

configure 1.279.6.6
configure.in 1.288.6.6

Please report the remaining problem as a new bug report. It
would be good if you could analyse it with more detail, e.g.
by invoking ./python ... manually (with the same variables
that make sets); if it still fails, I recommend to run the
newly-built python in gdb, to produce a backtrace.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 19:06

Message:
Logged In: YES 
user_id=133413

Yargh! Well, at least it gets to a _different_ problem
before compilation fails:

gcc  -Xlinker -export-dynamic -o python \
                Modules/python.o \
                libpython2.2.a -ldl  -lpthread -lutil   -lm  
case $MAKEFLAGS in \
*-s*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3
-Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; \
*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3
-Wall -Wstrict-prototypes' ./python -E ./setup.py build;; \
esac
make: *** [sharedmods] Error 139

Curiously, I believe what I had before was 2.2.1rc ... um, 1
I think. And it compiled fine once the one line in
pyconfig.h was corrected by hand. Is this another bug report
I should submit?


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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 18:53

Message:
Logged In: YES 
user_id=133413

Works! The standard configure in 2.2.1 comments out
HAVE_SYS_RESOURCE_H, whereas your new configure file on a
clean tree does not. Am testing compile now, but don't
anticipate a problem - will let you know if one kicks up.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 17:12

Message:
Logged In: YES 
user_id=21627

Yes, please: start with a clean 2.2.1 tree. I have
regenerated the configure for 2.2.1, and attached to this
report.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 16:18

Message:
Logged In: YES 
user_id=133413

Oh, Python version. By coincidence I just cleaned that from
the system last week, and don't remember the exact version.
Would it make sense for me to try to compile the latest
Python source, see if it fails the same way?

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 15:19

Message:
Logged In: YES 
user_id=21627

I'm still trying to find out why you could not apply the
patch I created earlier on. I want to recreate it so that it
works for your copy of the Python source code, but for that
to work, I need to know what version the copy of your Python
source code has.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 15:05

Message:
Logged In: YES 
user_id=133413

Since the problem comes from the way Red Hat 6.0 symlinks
the kernel libraries, which then creates a conflict between
library files if a kernel is compiled from source in the old
standard location of /usr/src/linux (don't think it would
apply to installing kernels from RPM since I don't think Red
Hat ever came up with a path to upgrade 6.0 to a 2.4 kernel
without upgrading the whole distribution) ... hmm, wonder if
that's precise enough for your purposes. There are various
system components upgraded from RPM after the base 6.0
release for security concerns and so on, so if the fix
wouldn't be generic to "6.0 + custom-compiled kernel in
/usr/src/linux" then this system probably couldn't be
defined precisely enough for the purpose.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 14:26

Message:
Logged In: YES 
user_id=21627

Whit, are you still interested in resolving this? If so, I
need to know the precise source distribution that you are
using, so I can produce patches against it.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-02 10:44

Message:
Logged In: YES 
user_id=21627

For 2.2.1, no action is needed - this is a system
configuration problem. 

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-31 22:21

Message:
Logged In: YES 
user_id=6656

Martin, what if anything do you think should be done here?

I'm leery of mucking with configure.in at this point.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 18:12

Message:
Logged In: YES 
user_id=133413

Have autoconf 2.13. Never explicitly used it though, and 
don't know the theory of it. If I patch, then invoke 
autoconf, then invoke configure ... well, that may not be 
what you mean, because it doesn't get around the problem.

If I just use your new configure file, that doesn't work 
either. Please specify the exact steps you require.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 17:35

Message:
Logged In: YES 
user_id=21627

If you have autoconf, you can just use the patch to
configure.in, and invoke 'autoconf'. In case you don't have
autoconf, I'll attach the complete configure file.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 17:30

Message:
Logged In: YES 
user_id=133413

Um ...

# patch -p1 <../conf.txt 
patching file `configure.in'
patching file `configure'
Reversed (or previously applied) patch detected!  Assume -R?
[n] 
Apply anyway? [n] y
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 1428.
2 out of 267 hunks FAILED -- saving rejects to configure.rej

If I say yes to -R, almost all hunks fail.

***************
*** 1,6 ****
  #! /bin/sh

- # From configure.in Revision: 1.288.6.3

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
--- 1,6 ----
  #! /bin/sh

+ # From configure.in Revision: 1.288.6.4

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
***************
*** 1428,1434 ****
          fi      
        case $ac_sys_system in
        AIX*)
-          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $(LINKCC)";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)
--- 1428,1434 ----
          fi      
        case $ac_sys_system in
        AIX*)
+          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $LINKCC";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)

Well, I'll try it as patched - those hunks don't look like
much is lost.

The config.log doesn't look good:

configure:2016: checking for sys/resource.h
configure:2026: gcc -E  conftest.c >/dev/null 2>conftest.out
In file included from /usr/include/sys/resource.h:25,
                 from configure:2022:
/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition
configure: failed program was:
#line 2021 "configure"
#include "confdefs.h"
#include <sys/resource.h>



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 16:58

Message:
Logged In: YES 
user_id=21627

Please try the attached conf.txt with an otherwise
unmodified system, and report whether it solves the problem.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 05:33

Message:
Logged In: YES 
user_id=133413

Probably not wisely, I tried changing the definition of
RLIM_INFINITY in bits/resource.h to match that in the kernel
header.  That took Python through the install, with make
test producing:

166 tests OK.
1 test failed:
    test_mmap
20 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl
test_imgfile
    test_largefile test_linuxaudiodev test_minidom test_nis
    test_ntpath test_pyexpat test_sax test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file
test_winreg
    test_winsound
4 skips unexpected on linux2:
    test_minidom test_linuxaudiodev test_pyexpat test_sax
make: *** [test] Error 1

As I understand all this, the definition to prefer should
probably be the one from glibc rather than the kernel (if it
even makes a difference on this value). Is this the one
which would be in effect if Python's configure were simply
to accept that resource.h is present rather than rejecting
it for this difference? 

RLIM_INFINITY btw is changed to match more recent kernels in
glibc 2.2 - but there's no rpm of that for Red Hat 6.x, and
of course building your own glibc is a good way to break a
system.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 00:03

Message:
Logged In: YES 
user_id=133413

A Google search leads me to a comment from Linus himself 
explaining that all the distributions symlinking like Red 
Hat 6.0 did are broken. I'm sure his theory is right, but 
out here in the real world, as he notes, many distros do 
that and most of us do have the idea that the current 
kernel should be built in /usr/src/linux. (Seems that rpms 
and debs of kernels put new kernel code there too - but 
I've always built kernels from tar.) 

Anyway, Linus's take is at: 
http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 23:43

Message:
Logged In: YES 
user_id=133413

You have good instincts on what to believe. I was mislead 
because rerunning configure produces a config.log without 
the warnings about resource.h. However running it in a 
freshly openned tar reproduces that warning; and even 
running it twice there (the second time, no warning) 
results in compilation failing at the same place.

So I think you have it - configure takes _any_ gcc warning 
as indicating nonexistence. And I think I see why the 
conflict comes on some systems but not on others. Red Hat 
6.0 sets /usr/include/asm as follows:

asm -> ../src/linux/include/asm/

That directory includes a "resource.h". On this box that 
happens to be code included with kernel 2.4.16, largely 
consisting of a modified definition of RLIM_INFINITY. I'd 
guess if the box still had a 2.2 kernel there would be no 
gcc warning. The whole of that file is:

#ifndef _I386_RESOURCE_H
#define _I386_RESOURCE_H

/*
 * Resource limits
 */

#define RLIMIT_CPU      0               /* CPU time in ms 
*/
#define RLIMIT_FSIZE    1               /* Maximum 
filesize */
#define RLIMIT_DATA     2               /* max data size */
#define RLIMIT_STACK    3               /* max stack size 
*/
#define RLIMIT_CORE     4               /* max core file 
size */
#define RLIMIT_RSS      5               /* max resident 
set size */
#define RLIMIT_NPROC    6               /* max number of 
processes */
#define RLIMIT_NOFILE   7               /* max number of 
open files */
#define RLIMIT_MEMLOCK  8               /* max 
locked-in-memory address space */
#define RLIMIT_AS       9               /* address space 
limit */
#define RLIMIT_LOCKS    10              /* maximum file 
locks held */

#define RLIM_NLIMITS    11

/*
 * SuS says limits have to be unsigned.
 * Which makes a ton more sense anyway.
 */
#define RLIM_INFINITY   (~0UL)

#ifdef __KERNEL__

#define INIT_RLIMITS                                    {                                                               { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {      _STK_LIM, RLIM_INFINITY },                       {             0, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {             0,             0 },                       {      INR_OPEN,     INR_OPEN  },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },               }
 
#endif /* __KERNEL__ */

#endif




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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 22:08

Message:
Logged In: YES 
user_id=21627

This is hard to believe: the spaces should have no effect.
Please consider the config.log analysis of the problem:

/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition

Apparently, configure treats these warnings as an indication
that sys/resource.h is absent. config.log also gives the
"program" it tried to compile - if your theory is correct,
changing the spaces should silence the gcc warning. Could
you please verify this theory (i.e. compiling the program

#include <sys/resource.h>

both with the original and the modified resource.h)

It appears that configure should disable warnings in gcc;
I'll try to come up with a patch.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 18:20

Message:
Logged In: YES 
user_id=133413

Think you've led me to the problem.

/usr/include/bits/resource.h has:

/* Value to indicate that there is no limit.  */
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int)(~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif

#ifdef __USE_LARGEFILE64
# define RLIM64_INFINITY 0x7fffffffffffffffLL
#endif

Removing the spaces after "#" before "define" results in 
configure correctly recognizing resource.h. Then the 
question would be: is this a shortcoming of configure, or 
are those spaces actually disabling bugs in this version 
of bits/resource.h? 


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:56

Message:
Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 17:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:02

Message:
Logged In: YES 
user_id=133413

Here it is.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 01:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 01:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 20:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 17:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 16:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 17:50:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 09:50:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-563303 ] Heap corruption in debug
Message-ID: <E17Ev2d-000426-00@usw-sf-web2.sourceforge.net>

Bugs item #563303, was opened at 2002-06-01 10:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563303&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Cliff Owen (cliffo)
Assigned to: Tim Peters (tim_one)
Summary: Heap corruption in debug

Initial Comment:
PyObject_DebugMalloc() returns a pointer that is +8 
bytes to detect for underwriting the pointer.

Sometimes, PyObject_Free() is called instead of going 
through PyObject_DebugFree(). This means the pointer 
is off by 8. PyObject_Free() takes the pointer passed in 
as being valid, and will update the pool to indicate the 
passed pointer is a pointer to the new free block.

Corruption of the heap occurs when 
PyObject_DebugMalloc() is called and there are 
multiple free blocks in a row that are properly aligned. 
Writing the FORBIDDENBYTE set to the end of the 
newly allocated block may stomp the next free pointer.

2 more allocations later on this arena, and you will AV.

Why is PyObject_Free() being called instead of 
PyObject_DebugFree() (from ste_dealloc)? I'm 
assuming it was built incorrectly or there's an ordering 
issue in objimpl.h where PyObject_Free() is defined 
before the macro, and referenced by PyObject_Del.

The fact remains that a simple alignment check in 
PyObject_Free() will handle any misaligned pointer.

If I've got this completely screwed up and it is in fact 
building incorrectly, please let me know. I've traced 
through it about 100 times. I'm fairly certain I understand 
how/why it works the way it does, but I could be wrong.

This problem would only show up in debug mode.

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

>Comment By: Tim Peters (tim_one)
Date: 2002-06-03 12:50

Message:
Logged In: YES 
user_id=31435

Offline, it was determined that:

+ The OP was compiling Python as well as his app.

+ Some Python modules weren't getting compiled with 
_DEBUG, via an accident in his build setup.

So closing as invalid -- the problem was due to a flawed 
custom build setup.

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

Comment By: Tim Peters (tim_one)
Date: 2002-06-01 19:56

Message:
Logged In: YES 
user_id=31435

Could you try to describe exactly how the problem arises, 
holding off on speculation about causes and cures?  What I 
still don't grasp at all is how you get into this situation to 
begin with:  it should be impossible to enter PyObject_Free
() in a pymalloc debug build *except* when 
_PyObject_DebugFree() calls it.  Your report begins with

"""
Sometimes, PyObject_Free() is called instead of going 
through PyObject_DebugFree(). 
"""

and I'm still lost on that sentence:  it shouldn't be possible 
to do that in a debug build.  If there is a way to do it, it's a 
serious problem, and your suggested code won't fix it (it 
may hide bad symptoms by accident for a while, but the 
problem still exists and will come back to bite you later).

It's unclear to me why you mentioned ste_dealloc, but I've 
stepped thru that in the MSVC 6 debugger and it does call 
_PyObject_DebugFree in a debug build.  It's doing what it's 
supposed to do. 

1. Is it your claim that ste_dealloc actually calls 
PyObject_Free directly in *your* debug build?  "Yes" or "no" 
would be more helpful than outrage <wink>.

2. What does "a snapshot of the python 2.3 build" mean, 
exactly?  Did you compile it yourself?  If not, from where did 
you get it?

3. Are you writing your own C extensions?  If so, are you 
mixing _DEBUG with non-_DEBUG between Python and 
your own code?  If you are so mixing, it's never going to 
work (Python and extension modules on Windows must 
both be built with _DEBUG, or neither).

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

Comment By: Cliff Owen (cliffo)
Date: 2002-06-01 18:22

Message:
Logged In: YES 
user_id=556609

Yes, I do have a program which demonstrates the problem. 
However, I cannot send it in because it is commercial in 
nature. :( I understand this poses a bit of a problem for 
debugging, but I'm hoping you understand. I do have other 
things that require more of my time than browsing the Python 
sources and making speculations on what I see. This did AV, 
and I did spend a while debugging it, with a debugger. Being 
the nice developer who's using a free product that's not being 
maintained by me, I thought I'd report this.

Yes, I also have seen what happens inside of objimpl.h, and 
do know that PyObject_Del is called in ste_dealloc. These 
are details I didn't think necessary to mention because you 
would obviously be familiar with the code and since I 
mentioned ste_dealloc, you might assume I would be familiar 
with these mappings as well since ste_dealloc() clearly calls 
PyObject_Del, which is nothing but a macro to 
PyObject_Free.

Regardless and bickering aside, I have added the following 
line to PyObject_Free() in my own code and it resolves the 
problem by assuring that any pointer passed in is properly 
aligned on the correct block size. This one line covers a 
multitude of sins from the caller.

p = (char *) p - ((char *)p - ((char *)pool + 
POOL_OVERHEAD)) % INDEX2SIZE(pool->szidx);

Right after:

if (ADDRESS_IN_RANGE(p, pool->arenaindex))

If you choose to use this line or not is up to you. If the user 
passes in a pointer that is aligned, this line does nothing. If 
the user passes in a pointer which resides anywhere in a 
valid block, that block is released. Is this the correct 
behavior? Probably not. It should probably raise an exception 
rather than allow the user to get away with it. This would at 
least force the user to figure out why they were passing in a 
bogus pointer in the first place.

Some additional information: I am building with MSVC 6.x 
(SP3), using a snapshot of the python 2.3 build. I am 
compiling into a static library using these defines only.

WIN32,_DEBUG,_MBCS,_LIB,USE_DL_EXPORT

If you need additional information, let me know. I'm not sure 
what else I can tell you.


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

Comment By: Tim Peters (tim_one)
Date: 2002-06-01 12:35

Message:
Logged In: YES 
user_id=31435

Do you have an actual program that shows corruption, or 
are you speculating?

Note that in a debug build, it's not possible to call 
PyObject_Free:  the name PyObject_Free is remapped to 
_PyObject_DebugFree by objimpl.h then.  In a debug build 
when pymalloc is enabled, all calls to all PyMem_XYZ and 
PyObject_XYZ memory functions are redirected to 
_PyObject_DebugXYZ, except within obmalloc.c itself 
(which #undefs some name substitutions).

ste_dealloc doesn't call PyObject_Free.  It calls 
PyObject_Del.  In a debug pymalloc build, that ends up 
calling _PyObject_DebugFree.  Step through it in a 
debugger if you don't believe it <wink>.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563303&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 17:51:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 09:51:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-563730 ] isinstance() fails to identify obj class
Message-ID: <E17Ev3N-0003Wq-00@usw-sf-web4.sourceforge.net>

Bugs item #563730, was opened at 2002-06-03 06:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563730&group_id=5470

Category: None
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Jessica Preston (jesspreston)
Assigned to: Nobody/Anonymous (nobody)
Summary: isinstance() fails to identify obj class

Initial Comment:
The problem seems to be that if I create two objects
using the same class
constructor, but having imported the class differently,
the isinstance() method
fails to identify them as being the same. The problem
only occurs (I think)
when cPickle is used, at least, that was how I managed
to reproduce it.

I have attached an example which includes a README and
a couple of directories:

SampleDir contains
- Simple.py (a simple class that has a compare() method
that uses isinstance)
- Main.py

SampleDir/NestedDir contains
- CreatePickle.py (which creates a Simple() object and
pickles it into the cwd)

Main.py unpickles the Simple object created by
CreatePickle.py, then compares it against a newly
created Simple() object using the Simple.compare()
method. It should raise as Assertion error claiming
that the passed object was not a Simple object.
However, it is.

I looked through existing bug reports and found a very
similar one from 2001 with tracking number 467267 -
this was marked as invalid, I think, but I'm not sure
whether this resolves my problem.

The README contains instructions on running the
example, plus my system information.

I am running RedHat7.1, with kernel 2.4.18 (if
relevant) and
the version of python I am using is Python 2.2.1

I hope that this will demonstrate the problem.

Thanks
-jess

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

>Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 18:51

Message:
Logged In: YES 
user_id=89016

This has nothing to do with cPickle directly. Bug #467267
seems to report exactly the same problem. Adding the
following code to Simple.compare demonstrates that the
Simple module was imported twice and generated two different
module objects:
		import sys
		print id(sys.modules["Simple"])
		print id(sys.modules["SampleDir.Simple"])

The pickle file includes the module name SampleDir.Simple,
which will implicitly be imported. But Main.py does an
"import Simple".

The simplest example that provokes this error is the
following script (which should be named test.py and started
with "python test.py")
class Foo:
    pass
# reimport the module under a different name
import test
assert isinstance(Foo(), test.Foo)

Moving the CreatePickle.py file from NestedDir to SampleDir
and changing the import from "from SampleDir.Simple import
Simple
" to "from Simple import Simple" fixes the problem.

Maybe Python should use absolute file/package names as keys
for sys.modules?


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563730&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 17:55:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 09:55:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-563665 ] urllib2 can't cope with error response
Message-ID: <E17Ev73-00043f-00@usw-sf-web2.sourceforge.net>

Bugs item #563665, was opened at 2002-06-02 22:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563665&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Demaine (edemaine)
Assigned to: Jeremy Hylton (jhylton)
Summary: urllib2 can't cope with error response

Initial Comment:
This looks similar to SF bug 216649, but with somewhat
different symptoms.  Redirection seems to cause an
AttributeError (attempt to access self.fp.read when
self.fp is None).  Simple example:

python -c "import urllib2; urllib2.urlopen
('http://www.yahoo.com/promotions/mom_com97/supermom.html')"

Traceback from Python 2.2.1 attached.  Same behavior
appears with Python 2.2.

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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-03 16:55

Message:
Logged In: YES 
user_id=31392

Fixed the urllib2 part of the problem in CVS as rev 1.31 of
urllib2.py.  You'll now get a better error message about
what went wrong.

Still not sure what httplib should do differently.  I notice
that Mozilla renders this page with the HTTP response in the
text, including junk at the very beginning of the response.
 (The server is clearly broken.)

It would probably be best if httplib treated this as an
HTTP/0.9 response if there appears to be a valid message
body.  It looks like that's what Mozilla is doing.


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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-03 16:17

Message:
Logged In: YES 
user_id=31392

I haven't looked at 216649 yet, but this particular
traceback is caused by a problem loading the redirected url.
 If you load 
http://promotions.yahoo.com/promotions/mom_com97/supermom.html,
you'll see the same failure without invoking an redirect
machinery.

My first guess is that the yahoo server is sending an
invalid response and the httplib isn't being generous enough
in skipping the garbage and looking for the valid response
data.  Here's a brief trace of httplib activity:
>>> import httplib
>>> h = httplib.HTTP('promotions.yahoo.com')
>>> h.set_debuglevel(2)
>>> h.putrequest("GET /promotions/mom_com97/supermom.html")   
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: putrequest() takes at least 3 arguments (2 given)
>>> h.putrequest("GET", "/promotions/mom_com97/supermom.html")
connect: (promotions.yahoo.com, 80)
send: 'GET /promotions/mom_com97/supermom.html HTTP/1.0\r\n'
>>> h.endheaders()
send: '\r\n'
>>> h.getreply()
reply: '#\x0f\x01yhh00000011\x010\x01HTTP/1.0 200 OK\n'
(-1, '#\x0f\x01yhh00000011\x010\x01HTTP/1.0 200 OK\n', None)

Not sure what the text starting with a hash is all about.

Of course, urllib2 has a bug that prevents it from reporting
anything useful about this error.  That needs to be fixed.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563665&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 17:56:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 09:56:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E17Ev7r-0005Wq-00@usw-sf-web3.sourceforge.net>

Bugs item #535545, was opened at 2002-03-27 03:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Martin v. Löwis (loewis)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



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

Comment By: Paul Boddie (pboddie)
Date: 2002-06-03 18:56

Message:
Logged In: YES 
user_id=226443

Right. Since it wasn't obvious how I should attach the file, 
take a look at patch #563954 for details of how I fixed the 
problem. Note that this patch only prevents the compiler 
error - it has *not* been tested at all.

It would be interesting to know why the conditional 
statements were nested, as that was the reason why the 
identifier in question could not be found.

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

Comment By: Paul Boddie (pboddie)
Date: 2002-06-03 18:49

Message:
Logged In: YES 
user_id=226443

This can be fixed by a rearrangement of the conditional 
preprocessor statements at around line 1236 of 
Modules/posixmodule.c as indicated by a patch file I'm going 
to try and attach.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 19:57

Message:
Logged In: YES 
user_id=21627

Type 'bt' at the gdb prompt to get a backtrace. In the
specific case, it is also helpful to type 'print u' to get
the value of u at the time of the crash.

Closing this report again.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 19:51

Message:
Logged In: YES 
user_id=133413

Okay, this probably shows something. I add it here in case
you have a comment on how to submit the bug. But if you
don't, I'll just put in a report on a "dumps core" bug with
this included:

gdb ./python ./core
GNU gdb 4.17.0.11 with Linux support
...
This GDB was configured as "i386-redhat-linux"...
Core was generated by `./python'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libpthread.so.0...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.
#0  0x8075732 in eval_frame (f=0x8124f94) at Python/ceval.c:1310
1310                            Py_DECREF(u);


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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 19:47

Message:
Logged In: YES 
user_id=133413

Yes, close this one. Not sure how to analyze this:

# ./python -E ./setup.py build
Segmentation fault (core dumped)

Never have learned the tools for analyzing the dumped core. 

Even just ./python dumps core. My current kernel is
2.4.19-pre9-ac3 - updated since this bug report was
submitted - if that can be pertinent.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 19:37

Message:
Logged In: YES 
user_id=21627

This is very strange indeed. It does look like a different
bug, so I would like to close this one. I have committed
this change as

configure 1.279.6.6
configure.in 1.288.6.6

Please report the remaining problem as a new bug report. It
would be good if you could analyse it with more detail, e.g.
by invoking ./python ... manually (with the same variables
that make sets); if it still fails, I recommend to run the
newly-built python in gdb, to produce a backtrace.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 19:06

Message:
Logged In: YES 
user_id=133413

Yargh! Well, at least it gets to a _different_ problem
before compilation fails:

gcc  -Xlinker -export-dynamic -o python \
                Modules/python.o \
                libpython2.2.a -ldl  -lpthread -lutil   -lm  
case $MAKEFLAGS in \
*-s*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3
-Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; \
*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3
-Wall -Wstrict-prototypes' ./python -E ./setup.py build;; \
esac
make: *** [sharedmods] Error 139

Curiously, I believe what I had before was 2.2.1rc ... um, 1
I think. And it compiled fine once the one line in
pyconfig.h was corrected by hand. Is this another bug report
I should submit?


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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 18:53

Message:
Logged In: YES 
user_id=133413

Works! The standard configure in 2.2.1 comments out
HAVE_SYS_RESOURCE_H, whereas your new configure file on a
clean tree does not. Am testing compile now, but don't
anticipate a problem - will let you know if one kicks up.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 17:12

Message:
Logged In: YES 
user_id=21627

Yes, please: start with a clean 2.2.1 tree. I have
regenerated the configure for 2.2.1, and attached to this
report.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 16:18

Message:
Logged In: YES 
user_id=133413

Oh, Python version. By coincidence I just cleaned that from
the system last week, and don't remember the exact version.
Would it make sense for me to try to compile the latest
Python source, see if it fails the same way?

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 15:19

Message:
Logged In: YES 
user_id=21627

I'm still trying to find out why you could not apply the
patch I created earlier on. I want to recreate it so that it
works for your copy of the Python source code, but for that
to work, I need to know what version the copy of your Python
source code has.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-06-02 15:05

Message:
Logged In: YES 
user_id=133413

Since the problem comes from the way Red Hat 6.0 symlinks
the kernel libraries, which then creates a conflict between
library files if a kernel is compiled from source in the old
standard location of /usr/src/linux (don't think it would
apply to installing kernels from RPM since I don't think Red
Hat ever came up with a path to upgrade 6.0 to a 2.4 kernel
without upgrading the whole distribution) ... hmm, wonder if
that's precise enough for your purposes. There are various
system components upgraded from RPM after the base 6.0
release for security concerns and so on, so if the fix
wouldn't be generic to "6.0 + custom-compiled kernel in
/usr/src/linux" then this system probably couldn't be
defined precisely enough for the purpose.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 14:26

Message:
Logged In: YES 
user_id=21627

Whit, are you still interested in resolving this? If so, I
need to know the precise source distribution that you are
using, so I can produce patches against it.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-02 10:44

Message:
Logged In: YES 
user_id=21627

For 2.2.1, no action is needed - this is a system
configuration problem. 

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-31 22:21

Message:
Logged In: YES 
user_id=6656

Martin, what if anything do you think should be done here?

I'm leery of mucking with configure.in at this point.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 18:12

Message:
Logged In: YES 
user_id=133413

Have autoconf 2.13. Never explicitly used it though, and 
don't know the theory of it. If I patch, then invoke 
autoconf, then invoke configure ... well, that may not be 
what you mean, because it doesn't get around the problem.

If I just use your new configure file, that doesn't work 
either. Please specify the exact steps you require.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 17:35

Message:
Logged In: YES 
user_id=21627

If you have autoconf, you can just use the patch to
configure.in, and invoke 'autoconf'. In case you don't have
autoconf, I'll attach the complete configure file.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 17:30

Message:
Logged In: YES 
user_id=133413

Um ...

# patch -p1 <../conf.txt 
patching file `configure.in'
patching file `configure'
Reversed (or previously applied) patch detected!  Assume -R?
[n] 
Apply anyway? [n] y
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 1428.
2 out of 267 hunks FAILED -- saving rejects to configure.rej

If I say yes to -R, almost all hunks fail.

***************
*** 1,6 ****
  #! /bin/sh

- # From configure.in Revision: 1.288.6.3

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
--- 1,6 ----
  #! /bin/sh

+ # From configure.in Revision: 1.288.6.4

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
***************
*** 1428,1434 ****
          fi      
        case $ac_sys_system in
        AIX*)
-          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $(LINKCC)";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)
--- 1428,1434 ----
          fi      
        case $ac_sys_system in
        AIX*)
+          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $LINKCC";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)

Well, I'll try it as patched - those hunks don't look like
much is lost.

The config.log doesn't look good:

configure:2016: checking for sys/resource.h
configure:2026: gcc -E  conftest.c >/dev/null 2>conftest.out
In file included from /usr/include/sys/resource.h:25,
                 from configure:2022:
/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition
configure: failed program was:
#line 2021 "configure"
#include "confdefs.h"
#include <sys/resource.h>



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 16:58

Message:
Logged In: YES 
user_id=21627

Please try the attached conf.txt with an otherwise
unmodified system, and report whether it solves the problem.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 05:33

Message:
Logged In: YES 
user_id=133413

Probably not wisely, I tried changing the definition of
RLIM_INFINITY in bits/resource.h to match that in the kernel
header.  That took Python through the install, with make
test producing:

166 tests OK.
1 test failed:
    test_mmap
20 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl
test_imgfile
    test_largefile test_linuxaudiodev test_minidom test_nis
    test_ntpath test_pyexpat test_sax test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file
test_winreg
    test_winsound
4 skips unexpected on linux2:
    test_minidom test_linuxaudiodev test_pyexpat test_sax
make: *** [test] Error 1

As I understand all this, the definition to prefer should
probably be the one from glibc rather than the kernel (if it
even makes a difference on this value). Is this the one
which would be in effect if Python's configure were simply
to accept that resource.h is present rather than rejecting
it for this difference? 

RLIM_INFINITY btw is changed to match more recent kernels in
glibc 2.2 - but there's no rpm of that for Red Hat 6.x, and
of course building your own glibc is a good way to break a
system.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 00:03

Message:
Logged In: YES 
user_id=133413

A Google search leads me to a comment from Linus himself 
explaining that all the distributions symlinking like Red 
Hat 6.0 did are broken. I'm sure his theory is right, but 
out here in the real world, as he notes, many distros do 
that and most of us do have the idea that the current 
kernel should be built in /usr/src/linux. (Seems that rpms 
and debs of kernels put new kernel code there too - but 
I've always built kernels from tar.) 

Anyway, Linus's take is at: 
http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 23:43

Message:
Logged In: YES 
user_id=133413

You have good instincts on what to believe. I was mislead 
because rerunning configure produces a config.log without 
the warnings about resource.h. However running it in a 
freshly openned tar reproduces that warning; and even 
running it twice there (the second time, no warning) 
results in compilation failing at the same place.

So I think you have it - configure takes _any_ gcc warning 
as indicating nonexistence. And I think I see why the 
conflict comes on some systems but not on others. Red Hat 
6.0 sets /usr/include/asm as follows:

asm -> ../src/linux/include/asm/

That directory includes a "resource.h". On this box that 
happens to be code included with kernel 2.4.16, largely 
consisting of a modified definition of RLIM_INFINITY. I'd 
guess if the box still had a 2.2 kernel there would be no 
gcc warning. The whole of that file is:

#ifndef _I386_RESOURCE_H
#define _I386_RESOURCE_H

/*
 * Resource limits
 */

#define RLIMIT_CPU      0               /* CPU time in ms 
*/
#define RLIMIT_FSIZE    1               /* Maximum 
filesize */
#define RLIMIT_DATA     2               /* max data size */
#define RLIMIT_STACK    3               /* max stack size 
*/
#define RLIMIT_CORE     4               /* max core file 
size */
#define RLIMIT_RSS      5               /* max resident 
set size */
#define RLIMIT_NPROC    6               /* max number of 
processes */
#define RLIMIT_NOFILE   7               /* max number of 
open files */
#define RLIMIT_MEMLOCK  8               /* max 
locked-in-memory address space */
#define RLIMIT_AS       9               /* address space 
limit */
#define RLIMIT_LOCKS    10              /* maximum file 
locks held */

#define RLIM_NLIMITS    11

/*
 * SuS says limits have to be unsigned.
 * Which makes a ton more sense anyway.
 */
#define RLIM_INFINITY   (~0UL)

#ifdef __KERNEL__

#define INIT_RLIMITS                                    {                                                               { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {      _STK_LIM, RLIM_INFINITY },                       {             0, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {             0,             0 },                       {      INR_OPEN,     INR_OPEN  },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },               }
 
#endif /* __KERNEL__ */

#endif




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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 22:08

Message:
Logged In: YES 
user_id=21627

This is hard to believe: the spaces should have no effect.
Please consider the config.log analysis of the problem:

/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition

Apparently, configure treats these warnings as an indication
that sys/resource.h is absent. config.log also gives the
"program" it tried to compile - if your theory is correct,
changing the spaces should silence the gcc warning. Could
you please verify this theory (i.e. compiling the program

#include <sys/resource.h>

both with the original and the modified resource.h)

It appears that configure should disable warnings in gcc;
I'll try to come up with a patch.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 18:20

Message:
Logged In: YES 
user_id=133413

Think you've led me to the problem.

/usr/include/bits/resource.h has:

/* Value to indicate that there is no limit.  */
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int)(~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif

#ifdef __USE_LARGEFILE64
# define RLIM64_INFINITY 0x7fffffffffffffffLL
#endif

Removing the spaces after "#" before "define" results in 
configure correctly recognizing resource.h. Then the 
question would be: is this a shortcoming of configure, or 
are those spaces actually disabling bugs in this version 
of bits/resource.h? 


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:56

Message:
Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 17:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:02

Message:
Logged In: YES 
user_id=133413

Here it is.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 01:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 01:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 20:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 17:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 16:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 18:02:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 10:02:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-555360 ] UTF-16 BOM handling counterintuitive
Message-ID: <E17EvE8-0005Z2-00@usw-sf-web3.sourceforge.net>

Bugs item #555360, was opened at 2002-05-13 09:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Stephen J. Turnbull (yaseppochi)
Assigned to: Walter Dörwald (doerwalter)
Summary: UTF-16 BOM handling counterintuitive

Initial Comment:
A search on "Unicode BOM" doesn't turn up anything related.

Sorry, I don't have a 2.2 or CVS to hand.  Easy enough
to replicate, anyway.  The UTF-16 codec happily
corrupts files by appending a BOM before writing
encoded text to the file:

bash-2.05a$ python
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import codecs
>>> f = codecs.open("/tmp/utf16","w","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = codecs.open("/tmp/utf16","a","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = open("/tmp/utf16","r") 
>>> f.read()
'\xff\xfea\x00\xff\xfea\x00'

Oops.

Also, dir(codecs) shows BOM64* constants are defined
(to what purpose, I have no idea---Microsoft Word files
on Alpha, maybe?), but no BOM8, which actually has some
basis in the standards.  (I think the idea of a UTF-8
signature is a abomination, so you can leave it
out<wink>, but people who do use the BOM as signature
in UTF-8 files would find it useful.)  Hmm ...

>>> codecs.BOM_BE
'\xfe\xff'
>>> codecs.BOM64_BE
'\x00\x00\xfe\xff'
>>> codecs.BOM32_BE
'\xfe\xff'
>>> 

Urk!  I only count 32 bits in BOM64 and 16 bits in
BOM32!  Maybe BOM32_* was intended as an alias for
BOM_*, and BOM64_* was a continuation of the typo, as
it were?

I wonder if this is the right interface, actually. 
Wouldn't prefixBOM() and checkBOM() methods for streams
and strings make more sense?  prefixBOM should be
idempotent, and checkBOM would return either a codec
(with size and endianness determined) or a codec.BOM*
constant.

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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 17:02

Message:
Logged In: YES 
user_id=38388

Google'ing around a bit, I can't find a single reference to
something like a special BOM mark on 64-bit machines.

Perhaps this was just some wild idea which has no
real meaning ?

Hmm it could have a meaning for UTF-32... but then it
should really be BOM_UTF16_ vs. BOM_UTF32_..
and have nothing to do with the internal storage format.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 15:41

Message:
Logged In: YES 
user_id=89016

In old code BOM, BOM_LE and BOM_BE are all 16bit, so to be
backwards compatible maybe the attached path diff2.txt
should be applied instead.

But this feels strange, because I'd expect that for a
--enable-unicode=ucs2 build codecs.BOM==codecs.BOM_UCS2 and
for an --enable-unicode=ucs4 build codecs.BOM==codecs.BOM_UCS4.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 14:54

Message:
Logged In: YES 
user_id=89016

> The only requirement we have for BOM is that it matches
> the BOM mark which actually gets written to the file.

But this is independent from the internal byte size of the
character type. UTF-16 always writes two bytes (except for
surrogates).

The attached diff.txt shows what I think the BOM stuff
should look like.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 13:58

Message:
Logged In: YES 
user_id=38388

The only requirement we have for BOM is that it matches
the BOM mark which actually gets written to the file.
The purpose of BOM_UCS2_ and BOM_UCS4_ is
to be able to figure out which underlying Unicode
version was used.

I'm not even sure whether there's a standard for this on
64-bit machines; could be that Microsoft invented something
here... (maybe that's also where the old names originated,
I don't know)

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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 13:35

Message:
Logged In: YES 
user_id=89016

codecs.py says:
BOM = struct.pack('=H', 0xFEFF)
this is not correct in wide build. Should this be changed to
if sys.maxunicode>0xffff:
   BOM = struct.pack('=L', 0x0000FEFF)
else:
   BOM = struct.pack('=H', 0xFEFF)
(with two additional constants BOM_UCS2 and BOM_UCS4?)

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 12:57

Message:
Logged In: YES 
user_id=38388

Ok, please do and then close the bug.

About the append mode: I think you're right. It's
not worth the trouble. Applications can easily figure
this out for themselves (and then use the proper
non-BOM prepending codec name).

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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 12:38

Message:
Logged In: YES 
user_id=89016

> Perhaps we should add aliases called BOM_UCS2_*
> and BOM_UCS4_* and update the documentation
> accordingly ?

Sounds reasonable!

If you want, I'll change it (including documentation)

About the append mode: I don't think it's a good idea to try
to fix this. There is much that can go wrong: seeking an odd
number of bytes, mixed endianness on writes, using a
different encoding on the second write. And what about UTF-8
and UTF-7? What should happen if the user seeks into the
middle of a UTF-[78] byte sequence and starts to write?


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 12:10

Message:
Logged In: YES 
user_id=38388

Hmm, you're right. Something is wrong here.

Perhaps we should add aliases called BOM_UCS2_*
and BOM_UCS4_* and update the documentation
accordingly ?

About the append mode: is file.mode considered to
be part of the file interface or not... I think that a patch
for the UTF-16 codec should check for this attribute
on the stream object to tell whether or not to prepend
the BOM mark.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 11:54

Message:
Logged In: YES 
user_id=89016

> The 32 vs. 16 refer to the number of bits in the
> Unicode internal type; they don't refer to the number of
> bits in the mark.

Yes, but unfortunately the constants in codecs are *not*
BOM32_?? and BOM16_??, but BOM64_?? and BOM32_??.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-02 17:16

Message:
Logged In: YES 
user_id=38388

I agree that opening a file in append mode should 
probably be smarter in the sense that the BOM is
only written in case file.seek() points to the beginning
of the file; patches are welcome.

On the other points:
* I don't see the point of adding an 8-bit BOM mark
  (UTF-8 does not depend on byte order).
* The 32 vs. 16 refer to the number of bits in the
  Unicode internal type; they don't refer to the number of 
  bits in the mark.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-05-13 20:43

Message:
Logged In: YES 
user_id=89016

And if you're using a different encoding for the second 
open call, the data will really be corrupted:
f = codecs.open("/tmp/foo","w","utf-8")
f.write("ää")
f = codecs.open("/tmp/foo","a","latin-1")
f.write("ää")

But how should codec.open be able to determine that the 
file is always opened with the same encoding, or which 
encoding was used for the open call last time? And if it 
could would it have to read the content using the old 
encoding and rewrite it using the new encoding to keep the 
file consistent?

I agree that the BOM names are broken.

> I wonder if this is the right interface, actually. 
> Wouldn't prefixBOM() and checkBOM() methods for streams 
> and strings make more sense? prefixBOM should be 
> idempotent, and checkBOM would return either a codec 
> (with size and endianness determined) or a codec.BOM* 
> constant.

You should consider UTF-16 to be a stateful encoding, so if 
you want to do your output in multiple pieces you have to 
use a stateful encoder, i.e. a StreamWriter:

>>> import codecs, cStringIO as StringIO
>>> stream = StringIO.StringIO()
>>> writer = codecs.getwriter("utf-16")(stream)
>>> writer.write(u"a")
>>> writer.write(u"b") 
>>> stream.getvalue()
'\xff\xfea\x00b\x00'


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 18:19:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 10:19:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-555360 ] UTF-16 BOM handling counterintuitive
Message-ID: <E17EvUq-0003g7-00@usw-sf-web4.sourceforge.net>

Bugs item #555360, was opened at 2002-05-13 11:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Stephen J. Turnbull (yaseppochi)
Assigned to: Walter Dörwald (doerwalter)
Summary: UTF-16 BOM handling counterintuitive

Initial Comment:
A search on "Unicode BOM" doesn't turn up anything related.

Sorry, I don't have a 2.2 or CVS to hand.  Easy enough
to replicate, anyway.  The UTF-16 codec happily
corrupts files by appending a BOM before writing
encoded text to the file:

bash-2.05a$ python
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import codecs
>>> f = codecs.open("/tmp/utf16","w","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = codecs.open("/tmp/utf16","a","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = open("/tmp/utf16","r") 
>>> f.read()
'\xff\xfea\x00\xff\xfea\x00'

Oops.

Also, dir(codecs) shows BOM64* constants are defined
(to what purpose, I have no idea---Microsoft Word files
on Alpha, maybe?), but no BOM8, which actually has some
basis in the standards.  (I think the idea of a UTF-8
signature is a abomination, so you can leave it
out<wink>, but people who do use the BOM as signature
in UTF-8 files would find it useful.)  Hmm ...

>>> codecs.BOM_BE
'\xfe\xff'
>>> codecs.BOM64_BE
'\x00\x00\xfe\xff'
>>> codecs.BOM32_BE
'\xfe\xff'
>>> 

Urk!  I only count 32 bits in BOM64 and 16 bits in
BOM32!  Maybe BOM32_* was intended as an alias for
BOM_*, and BOM64_* was a continuation of the typo, as
it were?

I wonder if this is the right interface, actually. 
Wouldn't prefixBOM() and checkBOM() methods for streams
and strings make more sense?  prefixBOM should be
idempotent, and checkBOM would return either a codec
(with size and endianness determined) or a codec.BOM*
constant.

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

>Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 19:19

Message:
Logged In: YES 
user_id=89016

So should I name them BOM_UTF16_* and BOM_UTF32_*?
(IMHO it makes much more sense this way)

Maybe Python should get an UTF-32 codec (see
http://www.unicode.org/unicode/reports/tr19/)?


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 19:02

Message:
Logged In: YES 
user_id=38388

Google'ing around a bit, I can't find a single reference to
something like a special BOM mark on 64-bit machines.

Perhaps this was just some wild idea which has no
real meaning ?

Hmm it could have a meaning for UTF-32... but then it
should really be BOM_UTF16_ vs. BOM_UTF32_..
and have nothing to do with the internal storage format.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 17:41

Message:
Logged In: YES 
user_id=89016

In old code BOM, BOM_LE and BOM_BE are all 16bit, so to be
backwards compatible maybe the attached path diff2.txt
should be applied instead.

But this feels strange, because I'd expect that for a
--enable-unicode=ucs2 build codecs.BOM==codecs.BOM_UCS2 and
for an --enable-unicode=ucs4 build codecs.BOM==codecs.BOM_UCS4.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 16:54

Message:
Logged In: YES 
user_id=89016

> The only requirement we have for BOM is that it matches
> the BOM mark which actually gets written to the file.

But this is independent from the internal byte size of the
character type. UTF-16 always writes two bytes (except for
surrogates).

The attached diff.txt shows what I think the BOM stuff
should look like.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 15:58

Message:
Logged In: YES 
user_id=38388

The only requirement we have for BOM is that it matches
the BOM mark which actually gets written to the file.
The purpose of BOM_UCS2_ and BOM_UCS4_ is
to be able to figure out which underlying Unicode
version was used.

I'm not even sure whether there's a standard for this on
64-bit machines; could be that Microsoft invented something
here... (maybe that's also where the old names originated,
I don't know)

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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 15:35

Message:
Logged In: YES 
user_id=89016

codecs.py says:
BOM = struct.pack('=H', 0xFEFF)
this is not correct in wide build. Should this be changed to
if sys.maxunicode>0xffff:
   BOM = struct.pack('=L', 0x0000FEFF)
else:
   BOM = struct.pack('=H', 0xFEFF)
(with two additional constants BOM_UCS2 and BOM_UCS4?)

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 14:57

Message:
Logged In: YES 
user_id=38388

Ok, please do and then close the bug.

About the append mode: I think you're right. It's
not worth the trouble. Applications can easily figure
this out for themselves (and then use the proper
non-BOM prepending codec name).

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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 14:38

Message:
Logged In: YES 
user_id=89016

> Perhaps we should add aliases called BOM_UCS2_*
> and BOM_UCS4_* and update the documentation
> accordingly ?

Sounds reasonable!

If you want, I'll change it (including documentation)

About the append mode: I don't think it's a good idea to try
to fix this. There is much that can go wrong: seeking an odd
number of bytes, mixed endianness on writes, using a
different encoding on the second write. And what about UTF-8
and UTF-7? What should happen if the user seeks into the
middle of a UTF-[78] byte sequence and starts to write?


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 14:10

Message:
Logged In: YES 
user_id=38388

Hmm, you're right. Something is wrong here.

Perhaps we should add aliases called BOM_UCS2_*
and BOM_UCS4_* and update the documentation
accordingly ?

About the append mode: is file.mode considered to
be part of the file interface or not... I think that a patch
for the UTF-16 codec should check for this attribute
on the stream object to tell whether or not to prepend
the BOM mark.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 13:54

Message:
Logged In: YES 
user_id=89016

> The 32 vs. 16 refer to the number of bits in the
> Unicode internal type; they don't refer to the number of
> bits in the mark.

Yes, but unfortunately the constants in codecs are *not*
BOM32_?? and BOM16_??, but BOM64_?? and BOM32_??.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-02 19:16

Message:
Logged In: YES 
user_id=38388

I agree that opening a file in append mode should 
probably be smarter in the sense that the BOM is
only written in case file.seek() points to the beginning
of the file; patches are welcome.

On the other points:
* I don't see the point of adding an 8-bit BOM mark
  (UTF-8 does not depend on byte order).
* The 32 vs. 16 refer to the number of bits in the
  Unicode internal type; they don't refer to the number of 
  bits in the mark.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-05-13 22:43

Message:
Logged In: YES 
user_id=89016

And if you're using a different encoding for the second 
open call, the data will really be corrupted:
f = codecs.open("/tmp/foo","w","utf-8")
f.write("ää")
f = codecs.open("/tmp/foo","a","latin-1")
f.write("ää")

But how should codec.open be able to determine that the 
file is always opened with the same encoding, or which 
encoding was used for the open call last time? And if it 
could would it have to read the content using the old 
encoding and rewrite it using the new encoding to keep the 
file consistent?

I agree that the BOM names are broken.

> I wonder if this is the right interface, actually. 
> Wouldn't prefixBOM() and checkBOM() methods for streams 
> and strings make more sense? prefixBOM should be 
> idempotent, and checkBOM would return either a codec 
> (with size and endianness determined) or a codec.BOM* 
> constant.

You should consider UTF-16 to be a stateful encoding, so if 
you want to do your output in multiple pieces you have to 
use a stateful encoder, i.e. a StreamWriter:

>>> import codecs, cStringIO as StringIO
>>> stream = StringIO.StringIO()
>>> writer = codecs.getwriter("utf-16")(stream)
>>> writer.write(u"a")
>>> writer.write(u"b") 
>>> stream.getvalue()
'\xff\xfea\x00b\x00'


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 17:59:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 09:59:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows)
Message-ID: <E17EvBA-0005Xz-00@usw-sf-web3.sourceforge.net>

Bugs item #216289, was opened at 2000-10-06 22:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: Later
Priority: 3
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: Programs using Tkinter sometimes can't shut down (Windows)

Initial Comment:
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


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

>Comment By: Tim Peters (tim_one)
Date: 2002-06-03 12:59

Message:
Logged In: YES 
user_id=31435

I tried replacing Python 2.2.1's tk83.dll and tcl83.dll (from 
Tcl/Tk 8.3.2) with newer matched sets from

A) PythonWare's py21 distribution (Tcl/Tk 8.3.3).

and again from

B) ActiveState's Tcl/Tk 8.3.4.

All the symptoms originally reported here persisted on 
Win98SE despite that.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-22 09:57

Message:
Logged In: NO 

I am new to Python and encountered this bug on my very first 
Tkinter application.  It persists in Python 2.2.1 under 
Windows Me. Needless to say, it makes a bad first 
impression.  Basically, this thread says that Tkinter has been 
broken for a year and a half on a popular platform at a time 
when Python is trying to expand its user base.  Hopefully, this 
bug will be corrected soon.

If Tcl/Tk 8.4 is not released shortly you might try repackaging 
Tkinter for Win32 with an earlier version of Tcl/Tk, such as 
8.0, that doesn't encounter this problem.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:36

Message:
Logged In: YES 
user_id=6380

The proper action is to wait until Tcl 8.3.5 is released,
and then shaming someone else in providing you with a set of
Windowsbinaries for Tcl. You may also ask Hobbs if there's a
Windows project file to build Tcl/Tk for Windows.

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

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-03-11 21:31

Message:
Logged In: YES 
user_id=72656

I did end up back-porting this to the 8.3.4+ Tcl CVS on 
2002-02-25, which means it will be in an eventual 8.3.5.  
It is already in the release 8.4 alpha series.

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

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 20:50

Message:
Logged In: YES 
user_id=31435

Back to Guido:  Do you think you know what the proper 
action is?  (You said that's why you reopened it, and 
there's been no new info here since then.)

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

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 19:55

Message:
Logged In: YES 
user_id=143340

I knew I wasn't getting to the heart of it ....

Almost a one-liner!

It has been seriously spoiling my (otherwise crash free) 
Python experience on Win9x - hope it gets fixed soon.

cheers,
John.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-25 18:39

Message:
Logged In: YES 
user_id=6380

Reopened until we know what the proper action is.

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

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-02-25 18:32

Message:
Logged In: YES 
user_id=72656

This is mostly correct, and is fixed in the 8.4 Tcl sources 
already (I guess we can backport this).  This was mentioned 
in SF Tcl bug (account for chopped URL):

https://sourceforge.net/tracker/?
func=detail&aid=217982&group_id=10894&atid=110894

and the code comment is:

    /*
     * Only finalize the notifier if a notifier was 
installed in the
     * current thread; there is a route in which this is not
     * guaranteed to be true (when tclWin32Dll.c:DllMain() 
is called
     * with the flag DLL_PROCESS_DETACH by the OS, which 
could be
     * doing so from a thread that's never previously been 
involved
     * with Tcl, e.g. the task manager) so this check is 
important.
     *
     * Fixes Bug #217982 reported by Hugh Vu and Gene 
Leache.
     */
    if (tsdPtr == NULL) {
	return;
    }


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

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 17:41

Message:
Logged In: YES 
user_id=143340

This one has been torturing me for a while.

Managed to track it down to a problem inside Tcl.
For the Tcl8.3.4 source distribution the problem is in
the file win/tclWinNotify.c 

void Tcl_FinalizeNotifier(ClientData clientData)
{
    ThreadSpecificData *tsdPtr = 
                         (ThreadSpecificData *) clientData;

    /* sometimes called with tsdPtr == NULL */
    if ( tsdPtr != NULL )
    {
        DeleteCriticalSection(&tsdPtr->crit);
        CloseHandle(tsdPtr->event);

        /*
         * Clean up the timer and messaging 
         * window for this thread.
         */

        if (tsdPtr->hwnd) {
	    KillTimer(tsdPtr->hwnd, INTERVAL_TIMER);
            DestroyWindow(tsdPtr->hwnd);
        }
    }

    /*
     * If this is the last thread to use the notifier, 
     * unregister the notifier window class.
     */

    Tcl_MutexLock(&notifierMutex);
    if ( notifierCount && !--notifierCount ) {
	UnregisterClassA( "TclNotifier", 
                          TclWinGetTclInstance());
    }
    Tcl_MutexUnlock(&notifierMutex);
}

This bodge doesn't address the underlying problem but has 
stopped me from tearing all my hair out,

cheers,
John Popplewell.


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

Comment By: Tim Peters (tim_one)
Date: 2001-10-24 18:27

Message:
Logged In: YES 
user_id=31435

FYI, you don't need an IDE to do this -- in Win9x, hit 
Ctrl+Alt+Del and kill the process directly.

A saner <wink> solution is to develop under Win2K, which 
doesn't appear to suffer this problem (the only reports 
I've seen, and experienced myself, came from Win9x boxes).

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-24 04:52

Message:
Logged In: NO 

For those who are still trapped in this bug's hell, I will 
gladly share the one thing that saved my sanity:  
WingIDE's 'Kill' command will shut down the program with 
apparent 100% certainty and no fear of lockups.  WingIDE 
has its own issues, so its not a perfect solution, but if 
you are like me and Joe (above) who test in small 
iterations, then using 'Kill' to quit out of your app while 
testing is a workaround that may preserve your sanity.

Perhaps the python gods and the Wing guys can get together 
and tell us how to replicate 'kill' into our code.  For 
now, I'll use WingIDE to edit, and pythonw.exe for my final 
client's delivery.

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

Comment By: Howard Lightstone (hlightstone)
Date: 2001-09-05 13:43

Message:
Logged In: YES 
user_id=66570

I sometimes get bunches of these....

A tool I use (Taskinfo2000) reports that (after killing 
winoldap):

python.exe is blocked on a mutex named OLESCELOCKMUTEX.
The reported state is "Console Terminating".  There appears 
to be only one (os) thread running.


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

Comment By: Tim Peters (tim_one)
Date: 2001-04-02 16:06

Message:
Logged In: YES 
user_id=31435

No sign of progress on this presumed Tk/Tcl Windows bug in 
over 3 months, so closing it for lack of hope.

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

Comment By: Doug Henderson (djhender)
Date: 2001-02-06 00:13

Message:
This was a symptom I saw while tracking down the essence of the problem reported in #131207.  Using Win98SE, I would get an error dialog (GPF?) in the Kernel, and sometimes the dos prompt would not come back.

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

Comment By: Tim Peters (tim_one)
Date: 2000-12-12 21:00

Message:
Just reproduced w/ current CVS, but didn't hang until the 8th try.

http://dev.scriptics.com/software/tcltk/ says 8.3 is still the latest released version; don't know whether that URL still makes sense, though.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-12-12 15:58

Message:
Tim, can you still reproduce this with the current CVS version?

There's been one critical patch to _tkinter since the 2.0 release.

An alternative would be to try with a newer version of Tcl (isn't 8.4 out already?).


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

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-15 12:47

Message:
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>

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-13 10:40

Message:
Back to Tim since I have no clue what to do here.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-12 13:25

Message:
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.

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

Comment By: Tim Peters (tim_one)
Date: 2000-10-07 03:37

Message:
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.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 19:39:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 11:39:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-555360 ] UTF-16 BOM handling counterintuitive
Message-ID: <E17Ewjq-00048F-00@usw-sf-web4.sourceforge.net>

Bugs item #555360, was opened at 2002-05-13 09:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Stephen J. Turnbull (yaseppochi)
Assigned to: Walter Dörwald (doerwalter)
Summary: UTF-16 BOM handling counterintuitive

Initial Comment:
A search on "Unicode BOM" doesn't turn up anything related.

Sorry, I don't have a 2.2 or CVS to hand.  Easy enough
to replicate, anyway.  The UTF-16 codec happily
corrupts files by appending a BOM before writing
encoded text to the file:

bash-2.05a$ python
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import codecs
>>> f = codecs.open("/tmp/utf16","w","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = codecs.open("/tmp/utf16","a","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = open("/tmp/utf16","r") 
>>> f.read()
'\xff\xfea\x00\xff\xfea\x00'

Oops.

Also, dir(codecs) shows BOM64* constants are defined
(to what purpose, I have no idea---Microsoft Word files
on Alpha, maybe?), but no BOM8, which actually has some
basis in the standards.  (I think the idea of a UTF-8
signature is a abomination, so you can leave it
out<wink>, but people who do use the BOM as signature
in UTF-8 files would find it useful.)  Hmm ...

>>> codecs.BOM_BE
'\xfe\xff'
>>> codecs.BOM64_BE
'\x00\x00\xfe\xff'
>>> codecs.BOM32_BE
'\xfe\xff'
>>> 

Urk!  I only count 32 bits in BOM64 and 16 bits in
BOM32!  Maybe BOM32_* was intended as an alias for
BOM_*, and BOM64_* was a continuation of the typo, as
it were?

I wonder if this is the right interface, actually. 
Wouldn't prefixBOM() and checkBOM() methods for streams
and strings make more sense?  prefixBOM should be
idempotent, and checkBOM would return either a codec
(with size and endianness determined) or a codec.BOM*
constant.

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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 18:39

Message:
Logged In: YES 
user_id=38388

Yes, please (but do leave the existing ones around fof
backward compatiblity).

About the UTF-32 codec: sure why not. Patches are
welcome !

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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 17:19

Message:
Logged In: YES 
user_id=89016

So should I name them BOM_UTF16_* and BOM_UTF32_*?
(IMHO it makes much more sense this way)

Maybe Python should get an UTF-32 codec (see
http://www.unicode.org/unicode/reports/tr19/)?


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 17:02

Message:
Logged In: YES 
user_id=38388

Google'ing around a bit, I can't find a single reference to
something like a special BOM mark on 64-bit machines.

Perhaps this was just some wild idea which has no
real meaning ?

Hmm it could have a meaning for UTF-32... but then it
should really be BOM_UTF16_ vs. BOM_UTF32_..
and have nothing to do with the internal storage format.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 15:41

Message:
Logged In: YES 
user_id=89016

In old code BOM, BOM_LE and BOM_BE are all 16bit, so to be
backwards compatible maybe the attached path diff2.txt
should be applied instead.

But this feels strange, because I'd expect that for a
--enable-unicode=ucs2 build codecs.BOM==codecs.BOM_UCS2 and
for an --enable-unicode=ucs4 build codecs.BOM==codecs.BOM_UCS4.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 14:54

Message:
Logged In: YES 
user_id=89016

> The only requirement we have for BOM is that it matches
> the BOM mark which actually gets written to the file.

But this is independent from the internal byte size of the
character type. UTF-16 always writes two bytes (except for
surrogates).

The attached diff.txt shows what I think the BOM stuff
should look like.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 13:58

Message:
Logged In: YES 
user_id=38388

The only requirement we have for BOM is that it matches
the BOM mark which actually gets written to the file.
The purpose of BOM_UCS2_ and BOM_UCS4_ is
to be able to figure out which underlying Unicode
version was used.

I'm not even sure whether there's a standard for this on
64-bit machines; could be that Microsoft invented something
here... (maybe that's also where the old names originated,
I don't know)

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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 13:35

Message:
Logged In: YES 
user_id=89016

codecs.py says:
BOM = struct.pack('=H', 0xFEFF)
this is not correct in wide build. Should this be changed to
if sys.maxunicode>0xffff:
   BOM = struct.pack('=L', 0x0000FEFF)
else:
   BOM = struct.pack('=H', 0xFEFF)
(with two additional constants BOM_UCS2 and BOM_UCS4?)

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 12:57

Message:
Logged In: YES 
user_id=38388

Ok, please do and then close the bug.

About the append mode: I think you're right. It's
not worth the trouble. Applications can easily figure
this out for themselves (and then use the proper
non-BOM prepending codec name).

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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 12:38

Message:
Logged In: YES 
user_id=89016

> Perhaps we should add aliases called BOM_UCS2_*
> and BOM_UCS4_* and update the documentation
> accordingly ?

Sounds reasonable!

If you want, I'll change it (including documentation)

About the append mode: I don't think it's a good idea to try
to fix this. There is much that can go wrong: seeking an odd
number of bytes, mixed endianness on writes, using a
different encoding on the second write. And what about UTF-8
and UTF-7? What should happen if the user seeks into the
middle of a UTF-[78] byte sequence and starts to write?


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 12:10

Message:
Logged In: YES 
user_id=38388

Hmm, you're right. Something is wrong here.

Perhaps we should add aliases called BOM_UCS2_*
and BOM_UCS4_* and update the documentation
accordingly ?

About the append mode: is file.mode considered to
be part of the file interface or not... I think that a patch
for the UTF-16 codec should check for this attribute
on the stream object to tell whether or not to prepend
the BOM mark.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 11:54

Message:
Logged In: YES 
user_id=89016

> The 32 vs. 16 refer to the number of bits in the
> Unicode internal type; they don't refer to the number of
> bits in the mark.

Yes, but unfortunately the constants in codecs are *not*
BOM32_?? and BOM16_??, but BOM64_?? and BOM32_??.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-02 17:16

Message:
Logged In: YES 
user_id=38388

I agree that opening a file in append mode should 
probably be smarter in the sense that the BOM is
only written in case file.seek() points to the beginning
of the file; patches are welcome.

On the other points:
* I don't see the point of adding an 8-bit BOM mark
  (UTF-8 does not depend on byte order).
* The 32 vs. 16 refer to the number of bits in the
  Unicode internal type; they don't refer to the number of 
  bits in the mark.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-05-13 20:43

Message:
Logged In: YES 
user_id=89016

And if you're using a different encoding for the second 
open call, the data will really be corrupted:
f = codecs.open("/tmp/foo","w","utf-8")
f.write("ää")
f = codecs.open("/tmp/foo","a","latin-1")
f.write("ää")

But how should codec.open be able to determine that the 
file is always opened with the same encoding, or which 
encoding was used for the open call last time? And if it 
could would it have to read the content using the old 
encoding and rewrite it using the new encoding to keep the 
file consistent?

I agree that the BOM names are broken.

> I wonder if this is the right interface, actually. 
> Wouldn't prefixBOM() and checkBOM() methods for streams 
> and strings make more sense? prefixBOM should be 
> idempotent, and checkBOM would return either a codec 
> (with size and endianness determined) or a codec.BOM* 
> constant.

You should consider UTF-16 to be a stateful encoding, so if 
you want to do your output in multiple pieces you have to 
use a stateful encoder, i.e. a StreamWriter:

>>> import codecs, cStringIO as StringIO
>>> stream = StringIO.StringIO()
>>> writer = codecs.getwriter("utf-16")(stream)
>>> writer.write(u"a")
>>> writer.write(u"b") 
>>> stream.getvalue()
'\xff\xfea\x00b\x00'


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 19:55:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 11:55:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows)
Message-ID: <E17Ewzb-0006D1-00@usw-sf-web3.sourceforge.net>

Bugs item #216289, was opened at 2000-10-06 19:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: Later
Priority: 3
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: Programs using Tkinter sometimes can't shut down (Windows)

Initial Comment:
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


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

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-06-03 11:55

Message:
Logged In: YES 
user_id=72656

providing Tim with a fixed DLL exactly according to John 
Popplewell's patch did not fix the problem for him.  That 
makes it seem fishy that John really didn't see the problem 
any more.

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

Comment By: Tim Peters (tim_one)
Date: 2002-06-03 09:59

Message:
Logged In: YES 
user_id=31435

I tried replacing Python 2.2.1's tk83.dll and tcl83.dll (from 
Tcl/Tk 8.3.2) with newer matched sets from

A) PythonWare's py21 distribution (Tcl/Tk 8.3.3).

and again from

B) ActiveState's Tcl/Tk 8.3.4.

All the symptoms originally reported here persisted on 
Win98SE despite that.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-22 06:57

Message:
Logged In: NO 

I am new to Python and encountered this bug on my very first 
Tkinter application.  It persists in Python 2.2.1 under 
Windows Me. Needless to say, it makes a bad first 
impression.  Basically, this thread says that Tkinter has been 
broken for a year and a half on a popular platform at a time 
when Python is trying to expand its user base.  Hopefully, this 
bug will be corrected soon.

If Tcl/Tk 8.4 is not released shortly you might try repackaging 
Tkinter for Win32 with an earlier version of Tcl/Tk, such as 
8.0, that doesn't encounter this problem.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 19:36

Message:
Logged In: YES 
user_id=6380

The proper action is to wait until Tcl 8.3.5 is released,
and then shaming someone else in providing you with a set of
Windowsbinaries for Tcl. You may also ask Hobbs if there's a
Windows project file to build Tcl/Tk for Windows.

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

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-03-11 18:31

Message:
Logged In: YES 
user_id=72656

I did end up back-porting this to the 8.3.4+ Tcl CVS on 
2002-02-25, which means it will be in an eventual 8.3.5.  
It is already in the release 8.4 alpha series.

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

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 17:50

Message:
Logged In: YES 
user_id=31435

Back to Guido:  Do you think you know what the proper 
action is?  (You said that's why you reopened it, and 
there's been no new info here since then.)

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

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 16:55

Message:
Logged In: YES 
user_id=143340

I knew I wasn't getting to the heart of it ....

Almost a one-liner!

It has been seriously spoiling my (otherwise crash free) 
Python experience on Win9x - hope it gets fixed soon.

cheers,
John.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-25 15:39

Message:
Logged In: YES 
user_id=6380

Reopened until we know what the proper action is.

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

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-02-25 15:32

Message:
Logged In: YES 
user_id=72656

This is mostly correct, and is fixed in the 8.4 Tcl sources 
already (I guess we can backport this).  This was mentioned 
in SF Tcl bug (account for chopped URL):

https://sourceforge.net/tracker/?
func=detail&aid=217982&group_id=10894&atid=110894

and the code comment is:

    /*
     * Only finalize the notifier if a notifier was 
installed in the
     * current thread; there is a route in which this is not
     * guaranteed to be true (when tclWin32Dll.c:DllMain() 
is called
     * with the flag DLL_PROCESS_DETACH by the OS, which 
could be
     * doing so from a thread that's never previously been 
involved
     * with Tcl, e.g. the task manager) so this check is 
important.
     *
     * Fixes Bug #217982 reported by Hugh Vu and Gene 
Leache.
     */
    if (tsdPtr == NULL) {
	return;
    }


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

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 14:41

Message:
Logged In: YES 
user_id=143340

This one has been torturing me for a while.

Managed to track it down to a problem inside Tcl.
For the Tcl8.3.4 source distribution the problem is in
the file win/tclWinNotify.c 

void Tcl_FinalizeNotifier(ClientData clientData)
{
    ThreadSpecificData *tsdPtr = 
                         (ThreadSpecificData *) clientData;

    /* sometimes called with tsdPtr == NULL */
    if ( tsdPtr != NULL )
    {
        DeleteCriticalSection(&tsdPtr->crit);
        CloseHandle(tsdPtr->event);

        /*
         * Clean up the timer and messaging 
         * window for this thread.
         */

        if (tsdPtr->hwnd) {
	    KillTimer(tsdPtr->hwnd, INTERVAL_TIMER);
            DestroyWindow(tsdPtr->hwnd);
        }
    }

    /*
     * If this is the last thread to use the notifier, 
     * unregister the notifier window class.
     */

    Tcl_MutexLock(&notifierMutex);
    if ( notifierCount && !--notifierCount ) {
	UnregisterClassA( "TclNotifier", 
                          TclWinGetTclInstance());
    }
    Tcl_MutexUnlock(&notifierMutex);
}

This bodge doesn't address the underlying problem but has 
stopped me from tearing all my hair out,

cheers,
John Popplewell.


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

Comment By: Tim Peters (tim_one)
Date: 2001-10-24 15:27

Message:
Logged In: YES 
user_id=31435

FYI, you don't need an IDE to do this -- in Win9x, hit 
Ctrl+Alt+Del and kill the process directly.

A saner <wink> solution is to develop under Win2K, which 
doesn't appear to suffer this problem (the only reports 
I've seen, and experienced myself, came from Win9x boxes).

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-24 01:52

Message:
Logged In: NO 

For those who are still trapped in this bug's hell, I will 
gladly share the one thing that saved my sanity:  
WingIDE's 'Kill' command will shut down the program with 
apparent 100% certainty and no fear of lockups.  WingIDE 
has its own issues, so its not a perfect solution, but if 
you are like me and Joe (above) who test in small 
iterations, then using 'Kill' to quit out of your app while 
testing is a workaround that may preserve your sanity.

Perhaps the python gods and the Wing guys can get together 
and tell us how to replicate 'kill' into our code.  For 
now, I'll use WingIDE to edit, and pythonw.exe for my final 
client's delivery.

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

Comment By: Howard Lightstone (hlightstone)
Date: 2001-09-05 10:43

Message:
Logged In: YES 
user_id=66570

I sometimes get bunches of these....

A tool I use (Taskinfo2000) reports that (after killing 
winoldap):

python.exe is blocked on a mutex named OLESCELOCKMUTEX.
The reported state is "Console Terminating".  There appears 
to be only one (os) thread running.


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

Comment By: Tim Peters (tim_one)
Date: 2001-04-02 13:06

Message:
Logged In: YES 
user_id=31435

No sign of progress on this presumed Tk/Tcl Windows bug in 
over 3 months, so closing it for lack of hope.

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

Comment By: Doug Henderson (djhender)
Date: 2001-02-05 21:13

Message:
This was a symptom I saw while tracking down the essence of the problem reported in #131207.  Using Win98SE, I would get an error dialog (GPF?) in the Kernel, and sometimes the dos prompt would not come back.

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

Comment By: Tim Peters (tim_one)
Date: 2000-12-12 18:00

Message:
Just reproduced w/ current CVS, but didn't hang until the 8th try.

http://dev.scriptics.com/software/tcltk/ says 8.3 is still the latest released version; don't know whether that URL still makes sense, though.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-12-12 12:58

Message:
Tim, can you still reproduce this with the current CVS version?

There's been one critical patch to _tkinter since the 2.0 release.

An alternative would be to try with a newer version of Tcl (isn't 8.4 out already?).


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

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-15 09:47

Message:
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>

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-13 07:40

Message:
Back to Tim since I have no clue what to do here.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-12 10:25

Message:
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.

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

Comment By: Tim Peters (tim_one)
Date: 2000-10-07 00:37

Message:
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.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 20:07:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 12:07:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-421973 ] Coercion rules incomplete
Message-ID: <E17ExAi-0000w7-00@usw-sf-web1.sourceforge.net>

Bugs item #421973, was opened at 2001-05-07 05:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=421973&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 1
Submitted By: Konrad Hinsen (hinsen)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Coercion rules incomplete

Initial Comment:
The description of the coercion rules for numeric types
at
http://www.python.org/doc/current/ref/numeric-types.html
is incomplete. Step 3 says "We only get here if neither
x nor y is a class instance. " But step 2a also refers
to step 3 for the case that an explicit coercion
function returns None. It is not clear what happens in
that case.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-03 15:07

Message:
Logged In: YES 
user_id=6380

I've "fixed" this by a rewrite of the subsection on coercion
rules.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-09 14:04

Message:
Logged In: YES 
user_id=3066

Guido, can you correct this?  I'm afraid I might get it
wrong.  The coercion rules are strange turf for me.  ;-(

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=421973&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 20:55:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 12:55:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-551412 ] possible to fail to calc mro's
Message-ID: <E17Exv7-0001AO-00@usw-sf-web1.sourceforge.net>

Bugs item #551412, was opened at 2002-05-02 09:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551412&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
Resolution: Fixed
Priority: 6
Submitted By: Michael Hudson (mwh)
Assigned to: Guido van Rossum (gvanrossum)
Summary: possible to fail to calc mro's

Initial Comment:
This only crashes on the release22-maint branch, and
only when coredump is true:

class UserLong(object):
    def __pow__(self, *args):
        pass

coredump = 1

if not coredump:
   int.__mro__

pow(0, UserLong(), 0)

It's the type of the first argument to pow() that's
relavent: if you change it to "pow(0L, UserLong(), 0)"
you then have to change "int.__mro__" to "long.__mro__"
to avoid the crash.

Maybe it was the "typeobject.c refactoring" patch that
accidentally fixed this on the trunk?

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-03 15:55

Message:
Logged In: YES 
user_id=6380

OK, fixed that too in 2.2.x and in 2.3, by calling
PyErr_Clear().  Not ideal, but not bad either.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 17:46

Message:
Logged In: YES 
user_id=6380

Argh, reopening.

There's one little detail left:
_PyType_Lookup() promises not
to set an exception.  If the call
to PyType_Ready() fails, this
promise is broken...

What to do?  PyErr_Clear()
and return NULL comes to mind...

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 17:42

Message:
Logged In: YES 
user_id=6380

OK, I nailed it.

The fix is to call PyType_Ready()
in _PyType_Lookup() when mro is NULL.

Fixed in both 2.3 and 2.2.
A test case added only for 2.3.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 17:20

Message:
Logged In: YES 
user_id=6380

In fact, this still crashes in 2.2:
pow(0L, UserLong(), 0L)

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 17:10

Message:
Logged In: YES 
user_id=6380

Hm, this is serious.

This can happen whenever a built-in type
isn't initialized by PyType_Ready() yet,
and for many that is pretty common.
(The call to int.__mro__ goes through
type_getattro which calls PyType_Ready().)

I'm not sure which refactoring patch
you are referring to, and I'm actually
not at all sure that this can't happen
in 2.3 (despite the fact that this
particular example doesn't core dump there).

I'll investigate more...


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551412&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 22:01:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 14:01:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-459235 ] tuple __getitem__ limited
Message-ID: <E17Eywn-0005gp-00@usw-sf-web2.sourceforge.net>

Bugs item #459235, was opened at 2001-09-06 13:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=459235&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
>Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Guido van Rossum (gvanrossum)
Summary: tuple __getitem__ limited

Initial Comment:
The __getitem__ of a tuple does not support the
extended slicing. That makes it difficult to delegate
from an object's __getitem__ to a builtin container,
which ought to work through delegating __getitem__

<pre>
class GI:
    def __getitem__(self,a):
        print a

a = GI()
a[1:2]
(1,2,3,4).__getitem__(slice(1,2,None))
</pre>

gives

slice(1, 2, None)
Traceback (most recent call last):
  File "bar.py", line 7, in ?
    (1,2,3,4).__getitem__(slice(1,2,None))


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-03 17:01

Message:
Logged In: YES 
user_id=6380

See (revived) patch 400998?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-06 14:08

Message:
Logged In: YES 
user_id=6380

This is not just the __getitem__ -- t[...] also has this
problem.
As a workaround, you can define __getslice__ or parse the
slice() object yourself.

I'll eventually get around to fixing this, but it's a bit
messy.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=459235&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 22:01:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 14:01:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-473985 ] str, __getitem__ and slices
Message-ID: <E17EyxD-0007Ak-00@usw-sf-web3.sourceforge.net>

Bugs item #473985, was opened at 2001-10-23 06:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=473985&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: Remind
>Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Guido van Rossum (gvanrossum)
Summary: str, __getitem__ and slices

Initial Comment:
Using slices with __getitem__ doesn't work with 
classes derived from str:
---
class S(str):
   def __getitem__(self, index):
      print "getitem", index
      return str.__getitem__(self, index)
   def __setitem__(self, index, value):
      print "setitem", index, value

s = S("foo")
print s[0]
print s[0:2]
s[0] = "b"
s[0:2] = "bar"
---
This prints:
---
getitem 0
f
fo
setitem 0 b
setitem slice(0, 2, None) bar
---
instead of
---
getitem 0
f
getitem slice(0, 2, None)
fo
setitem 0 b
setitem slice(0, 2, None) bar
---
i.e. when no __getslice__ is defined s[0:2] will not 
be forwarded to __getitem__, but it seems to work for 
__setitem__.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-03 17:01

Message:
Logged In: YES 
user_id=6380

See (revived) patch 400998?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:45

Message:
Logged In: YES 
user_id=6380

Raising the priority slightly and marking as a 2.3 issue.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-10-23 10:50

Message:
Logged In: YES 
user_id=6380

I've thought about this some more.

It should be fixed, but the fix is complex, and think I'd
rather not make this change in 2.2 -- (1) I have little
time, and (2) we've already issued a beta release and a
declared a feature freeze. So I'd like to put this on hold
until I can start working on 2.3. This is what would have to
be done:

- Change all built-in sequence types to get rid of the
sq_slice and sq_ass_slice dispatch functions; instead, add a
mapping extension to these types and add mp_subscript and
mp_ass_subscript dispatch functions that recognize slice
objects.

- We'd probably also have to get rid of the sq_item and
sq_ass_item dispatch functions, to roll them into
mp_subscript and mp_ass_subscript.

- Possibly, the whole "PySequenceMethods" structure should
be deprecated; all the operations there are overloading
either numerical or mapping operations.

Extension types that define a sequence methods structure
should continue to work, but the recommendation would be to
migrate these out.

I wish I could do this in 2.2, but it's really too much work
to start now, *and* it would be a serious incompatibility
between 2.2b1 and 2.2b2.

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

Comment By: Walter Dörwald (doerwalter)
Date: 2001-10-23 10:05

Message:
Logged In: YES 
user_id=89016

Oops, this wasn't meant to be a patch. Should have gone 
into the bugs category.

The problems is that http://python.sourceforge.net/devel-
docs/ref/sequence-methods.html says, that __getslice__ 
is "Deprecated since release 2.0", so the user will want to 
implement __getslice__ via __getitem__.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-10-23 09:48

Message:
Logged In: YES 
user_id=6380

I don't think this is a bug. S inherits __getslice__ from
the str base class, but since str is immutable, it doesn't
define a __setslice__ to inherit for S.

BTW I'm reclassifying this as a bug, not a patch. This will
unfortunately invalidate the old URL you had for this entry
(SF doesn't really like reclassification that much.)

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=473985&group_id=5470



From noreply@sourceforge.net  Mon Jun  3 22:04:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 14:04:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-547211 ] Warn for __coerce__ in new-style classes
Message-ID: <E17Ez0A-0001ov-00@usw-sf-web1.sourceforge.net>

Bugs item #547211, was opened at 2002-04-22 14:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547211&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
>Resolution: Later
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Warn for __coerce__ in new-style classes

Initial Comment:
New-style classes don't support __coerce__, except that
when you define it, coerce() will call it. (But it
won't be called by the binary operators.) Methinks a
warning should be issued when a new-style class defines
__coerce__.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-03 17:04

Message:
Logged In: YES 
user_id=6380

I think this is a PyChecker issue.

Neal, can you add this to PyChecker?

If you do, please close this bug report.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547211&group_id=5470



From noreply@sourceforge.net  Tue Jun  4 02:20:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 18:20:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-563598 ] Core dump with newly built Python
Message-ID: <E17F30G-00007Z-00@usw-sf-web2.sourceforge.net>

Bugs item #563598, was opened at 2002-06-02 14:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563598&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Nobody/Anonymous (nobody)
Summary: Core dump with newly built Python

Initial Comment:
This is on what started as a Red Hat 6.0 box currently
running a 2.4.19-pre9-ac3 kernel:

# gdb ./python ./core
GNU gdb 4.17.0.11 with Linux support
...
This GDB was configured as "i386-redhat-linux"...
Core was generated by `./python -E ./setup.py build'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libpthread.so.0...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.
#0  0x8075732 in eval_frame (f=0x812504c) at
Python/ceval.c:1310
1310                            Py_DECREF(u);

(gdb) bt 
#0  0x8075732 in eval_frame (f=0x812504c) at
Python/ceval.c:1310
#1  0x8077bee in PyEval_EvalCodeEx (co=0x81245c0,
globals=0x811ec6c, locals=0x811ec6c, args=0x0,
argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at
Python/ceval.c:2585
#2  0x8079c60 in PyEval_EvalCode (co=0x81245c0,
globals=0x811ec6c, locals=0x811ec6c) at Python/ceval.c:483
#3  0x808b53d in PyImport_ExecCodeModuleEx
(name=0xbfffe4f4 "os", co=0x81245c0, 
    pathname=0xbfffdbf4
"/usr/src/Python-2.2.1/Lib/os.pyc") at Python/import.c:502
#4  0x808ba59 in load_source_module (name=0xbfffe4f4
"os", pathname=0xbfffe064
"/usr/src/Python-2.2.1/Lib/os.py", 
    fp=0x810f710) at Python/import.c:772
#5  0x808c380 in load_module (name=0xbfffe4f4 "os",
fp=0x810f710, buf=0xbfffe064
"/usr/src/Python-2.2.1/Lib/os.py", 
    type=1) at Python/import.c:1356
#6  0x808d015 in import_submodule (mod=0x80e105c,
subname=0xbfffe4f4 "os", fullname=0xbfffe4f4 "os")
    at Python/import.c:1895
#7  0x808cbbd in load_next (mod=0x80e105c,
altmod=0x80e105c, p_name=0xbfffe900, buf=0xbfffe4f4 "os", 
    p_buflen=0xbfffe4f0) at Python/import.c:1751
#8  0x808c7eb in import_module_ex (name=0x0,
globals=0x81151cc, locals=0x81151cc, fromlist=0x80e105c)
    at Python/import.c:1602
#9  0x808dd14 in PyImport_ImportModuleEx
(name=0x8110854 "os", globals=0x81151cc,
locals=0x81151cc, fromlist=0x80e105c)
    at Python/import.c:1643
#10 0x80ca8ac in builtin___import__ (self=0x0,
args=0x81153fc) at Python/bltinmodule.c:40
#11 0x80c6e7d in PyCFunction_Call (func=0x8102998,
arg=0x81153fc, kw=0x0) at Objects/methodobject.c:80
#12 0x80a956e in PyObject_Call (func=0x8102998,
arg=0x81153fc, kw=0x0) at Objects/abstract.c:1684
#13 0x80783e0 in PyEval_CallObjectWithKeywords
(func=0x8102998, arg=0x81153fc, kw=0x0) at
Python/ceval.c:3049
#14 0x8076793 in eval_frame (f=0x8115554) at
Python/ceval.c:1839
#15 0x8077bee in PyEval_EvalCodeEx (co=0x81051d0,
globals=0x81151cc, locals=0x81151cc, args=0x0,
argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at
Python/ceval.c:2585
#16 0x8079c60 in PyEval_EvalCode (co=0x81051d0,
globals=0x81151cc, locals=0x81151cc) at Python/ceval.c:483
#17 0x808b53d in PyImport_ExecCodeModuleEx
(name=0xbffff494 "site", co=0x81051d0, 
    pathname=0xbfffeb94
"/usr/src/Python-2.2.1/Lib/site.pyc") at
Python/import.c:502
#18 0x808ba59 in load_source_module (name=0xbffff494
"site", pathname=0xbffff004
"/usr/src/Python-2.2.1/Lib/site.py", 
    fp=0x810f658) at Python/import.c:772
#19 0x808c380 in load_module (name=0xbffff494 "site",
fp=0x810f658, 
    buf=0xbffff004 "/usr/src/Python-2.2.1/Lib/site.py",
type=1) at Python/import.c:1356
#20 0x808d015 in import_submodule (mod=0x80e105c,
subname=0xbffff494 "site", fullname=0xbffff494 "site")
    at Python/import.c:1895
#21 0x808cbbd in load_next (mod=0x80e105c,
altmod=0x80e105c, p_name=0xbffff8a0, buf=0xbffff494
"site", 
    p_buflen=0xbffff490) at Python/import.c:1751
#22 0x808c7eb in import_module_ex (name=0x0,
globals=0x810f5d4, locals=0x810f5d4, fromlist=0x8107adc)
    at Python/import.c:1602
#23 0x808dd14 in PyImport_ImportModuleEx
(name=0x810f5bc "site", globals=0x810f5d4,
locals=0x810f5d4, 
    fromlist=0x8107adc) at Python/import.c:1643
#24 0x80ca8ac in builtin___import__ (self=0x0,
args=0x8107edc) at Python/bltinmodule.c:40
#25 0x80c6e7d in PyCFunction_Call (func=0x8102998,
arg=0x8107edc, kw=0x0) at Objects/methodobject.c:80
#26 0x80a956e in PyObject_Call (func=0x8102998,
arg=0x8107edc, kw=0x0) at Objects/abstract.c:1684
#27 0x80783e0 in PyEval_CallObjectWithKeywords
(func=0x8102998, arg=0x8107edc, kw=0x0) at
Python/ceval.c:3049
#28 0x80a8bee in PyObject_CallFunction
(callable=0x8102998, format=0x80d5707 "OOOO") at
Objects/abstract.c:1725
#29 0x808d4e6 in PyImport_Import
(module_name=0x810f5a8) at Python/import.c:2048
#30 0x808dc53 in PyImport_ImportModule (name=0x80d6ea3
"site") at Python/import.c:1574
#31 0x809448b in initsite () at Python/pythonrun.c:443
#32 0x8092812 in Py_Initialize () at Python/pythonrun.c:173
#33 0x8053387 in Py_Main (argc=4, argv=0xbffffb54) at
Modules/main.c:322
#34 0x8052dca in main (argc=4, argv=0xbffffb54) at
Modules/python.c:10
#35 0x400699cb in __libc_start_main (main=0x8052db4
<main>, argc=4, argv=0xbffffb54, init=0x80521e4 <_init>, 
    fini=0x80cbed4 <_fini>, rtld_fini=0x4000aea0
<_dl_fini>, stack_end=0xbffffb4c)
    at ../sysdeps/generic/libc-start.c:92
y_Initialize () at Python/pythonrun.c:173

(gdb) print u
$1 = (PyObject *) 0x0


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-03 21:20

Message:
Logged In: YES 
user_id=33168

What compiler & version are you using?
Did you start from a clean build?
Have you used the compiler for other packages?
If you start python -S, does that get a prompt?
If so, can you do anything?
Have you successfully built any other versions of Python on
this machine?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563598&group_id=5470



From noreply@sourceforge.net  Tue Jun  4 02:23:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 18:23:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-560286 ] Add docs for 'basestring'
Message-ID: <E17F338-00009S-00@usw-sf-web2.sourceforge.net>

Bugs item #560286, was opened at 2002-05-24 15:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560286&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: Add docs for 'basestring'

Initial Comment:
Please document the new built-in abstract type
'string'.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-03 21:23

Message:
Logged In: YES 
user_id=33168

Updated summary, since string was changed to basestring.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560286&group_id=5470



From noreply@sourceforge.net  Tue Jun  4 02:35:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 18:35:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-549731 ] Unicode encoders appears to leak references
Message-ID: <E17F3EA-0000HN-00@usw-sf-web2.sourceforge.net>

Bugs item #549731, was opened at 2002-04-28 05:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549731&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Unicode encoders appears to leak references

Initial Comment:
Note the following Debug Python session:

>>> s=u"anything"
[8189 refs]
>>> v=s.encode("utf8")
[10967 refs]
>>> v=s.encode("utf8")
[10968 refs]
>>> v=s.encode("utf8")
[10969 refs]
>>> v=s.encode("utf8")
[10970 refs]

Each call to encode is losing a reference.  Attaching a
test program that demonstrates this in more detail. 
The output from my test program is:

After 10000 iterations, lost 12850 references
[15227 refs]

and for 100000:
After 100000 iterations, lost 102850 references
[105227 refs]

etc.

As far as I can tell, this appears in all Python 2.x
versions.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-03 21:35

Message:
Logged In: YES 
user_id=33168

Patch makes sense to me.
If you add a test, I may be able to catch the problem w/purify
next time I run it (if purify works).

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

Comment By: Mark Hammond (mhammond)
Date: 2002-04-28 06:39

Message:
Logged In: YES 
user_id=14198

Oops - too quick.  All calls to _PyCodec_Lookup() leak.

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

Comment By: Mark Hammond (mhammond)
Date: 2002-04-28 06:05

Message:
Logged In: YES 
user_id=14198

Found it :)  Attaching patch.

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

Comment By: Mark Hammond (mhammond)
Date: 2002-04-28 05:26

Message:
Logged In: YES 
user_id=14198

s/decode/encode/ :)  Also meant to mention problem not
restricted to UTF8 - changing the encoding in the text file
to anything other than 'ascii' seems to leak in the same way.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549731&group_id=5470



From noreply@sourceforge.net  Tue Jun  4 03:09:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 19:09:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-555360 ] UTF-16 BOM handling counterintuitive
Message-ID: <E17F3lX-0000AK-00@usw-sf-web4.sourceforge.net>

Bugs item #555360, was opened at 2002-05-13 18:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Stephen J. Turnbull (yaseppochi)
Assigned to: Walter Dörwald (doerwalter)
Summary: UTF-16 BOM handling counterintuitive

Initial Comment:
A search on "Unicode BOM" doesn't turn up anything related.

Sorry, I don't have a 2.2 or CVS to hand.  Easy enough
to replicate, anyway.  The UTF-16 codec happily
corrupts files by appending a BOM before writing
encoded text to the file:

bash-2.05a$ python
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import codecs
>>> f = codecs.open("/tmp/utf16","w","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = codecs.open("/tmp/utf16","a","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = open("/tmp/utf16","r") 
>>> f.read()
'\xff\xfea\x00\xff\xfea\x00'

Oops.

Also, dir(codecs) shows BOM64* constants are defined
(to what purpose, I have no idea---Microsoft Word files
on Alpha, maybe?), but no BOM8, which actually has some
basis in the standards.  (I think the idea of a UTF-8
signature is a abomination, so you can leave it
out<wink>, but people who do use the BOM as signature
in UTF-8 files would find it useful.)  Hmm ...

>>> codecs.BOM_BE
'\xfe\xff'
>>> codecs.BOM64_BE
'\x00\x00\xfe\xff'
>>> codecs.BOM32_BE
'\xfe\xff'
>>> 

Urk!  I only count 32 bits in BOM64 and 16 bits in
BOM32!  Maybe BOM32_* was intended as an alias for
BOM_*, and BOM64_* was a continuation of the typo, as
it were?

I wonder if this is the right interface, actually. 
Wouldn't prefixBOM() and checkBOM() methods for streams
and strings make more sense?  prefixBOM should be
idempotent, and checkBOM would return either a codec
(with size and endianness determined) or a codec.BOM*
constant.

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

>Comment By: Stephen J. Turnbull (yaseppochi)
Date: 2002-06-04 11:09

Message:
Logged In: YES 
user_id=88738

The reason for a BOM8 is for use as a _signature_, cf.
ISO/IEC 10646-1, Annex F, as Amended by Amendment 2. 
Implementers of PEP 263 and those who have to interchange
with MS Notepad and other such applications that use a
leading ZERO-WIDTH NO-BREAK SPACE as a Unicode signature may
find it convenient.  The name BOM8 is for consistency with
the other signatures.

Of course you could trash _all_ the BOM names in favor of
"SIGNATURE_UTF(8|16|32)(_[BL]E)?", which applies in all cases.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-04 03:39

Message:
Logged In: YES 
user_id=38388

Yes, please (but do leave the existing ones around fof
backward compatiblity).

About the UTF-32 codec: sure why not. Patches are
welcome !

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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-04 02:19

Message:
Logged In: YES 
user_id=89016

So should I name them BOM_UTF16_* and BOM_UTF32_*?
(IMHO it makes much more sense this way)

Maybe Python should get an UTF-32 codec (see
http://www.unicode.org/unicode/reports/tr19/)?


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-04 02:02

Message:
Logged In: YES 
user_id=38388

Google'ing around a bit, I can't find a single reference to
something like a special BOM mark on 64-bit machines.

Perhaps this was just some wild idea which has no
real meaning ?

Hmm it could have a meaning for UTF-32... but then it
should really be BOM_UTF16_ vs. BOM_UTF32_..
and have nothing to do with the internal storage format.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-04 00:41

Message:
Logged In: YES 
user_id=89016

In old code BOM, BOM_LE and BOM_BE are all 16bit, so to be
backwards compatible maybe the attached path diff2.txt
should be applied instead.

But this feels strange, because I'd expect that for a
--enable-unicode=ucs2 build codecs.BOM==codecs.BOM_UCS2 and
for an --enable-unicode=ucs4 build codecs.BOM==codecs.BOM_UCS4.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 23:54

Message:
Logged In: YES 
user_id=89016

> The only requirement we have for BOM is that it matches
> the BOM mark which actually gets written to the file.

But this is independent from the internal byte size of the
character type. UTF-16 always writes two bytes (except for
surrogates).

The attached diff.txt shows what I think the BOM stuff
should look like.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 22:58

Message:
Logged In: YES 
user_id=38388

The only requirement we have for BOM is that it matches
the BOM mark which actually gets written to the file.
The purpose of BOM_UCS2_ and BOM_UCS4_ is
to be able to figure out which underlying Unicode
version was used.

I'm not even sure whether there's a standard for this on
64-bit machines; could be that Microsoft invented something
here... (maybe that's also where the old names originated,
I don't know)

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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 22:35

Message:
Logged In: YES 
user_id=89016

codecs.py says:
BOM = struct.pack('=H', 0xFEFF)
this is not correct in wide build. Should this be changed to
if sys.maxunicode>0xffff:
   BOM = struct.pack('=L', 0x0000FEFF)
else:
   BOM = struct.pack('=H', 0xFEFF)
(with two additional constants BOM_UCS2 and BOM_UCS4?)

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 21:57

Message:
Logged In: YES 
user_id=38388

Ok, please do and then close the bug.

About the append mode: I think you're right. It's
not worth the trouble. Applications can easily figure
this out for themselves (and then use the proper
non-BOM prepending codec name).

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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 21:38

Message:
Logged In: YES 
user_id=89016

> Perhaps we should add aliases called BOM_UCS2_*
> and BOM_UCS4_* and update the documentation
> accordingly ?

Sounds reasonable!

If you want, I'll change it (including documentation)

About the append mode: I don't think it's a good idea to try
to fix this. There is much that can go wrong: seeking an odd
number of bytes, mixed endianness on writes, using a
different encoding on the second write. And what about UTF-8
and UTF-7? What should happen if the user seeks into the
middle of a UTF-[78] byte sequence and starts to write?


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 21:10

Message:
Logged In: YES 
user_id=38388

Hmm, you're right. Something is wrong here.

Perhaps we should add aliases called BOM_UCS2_*
and BOM_UCS4_* and update the documentation
accordingly ?

About the append mode: is file.mode considered to
be part of the file interface or not... I think that a patch
for the UTF-16 codec should check for this attribute
on the stream object to tell whether or not to prepend
the BOM mark.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 20:54

Message:
Logged In: YES 
user_id=89016

> The 32 vs. 16 refer to the number of bits in the
> Unicode internal type; they don't refer to the number of
> bits in the mark.

Yes, but unfortunately the constants in codecs are *not*
BOM32_?? and BOM16_??, but BOM64_?? and BOM32_??.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 02:16

Message:
Logged In: YES 
user_id=38388

I agree that opening a file in append mode should 
probably be smarter in the sense that the BOM is
only written in case file.seek() points to the beginning
of the file; patches are welcome.

On the other points:
* I don't see the point of adding an 8-bit BOM mark
  (UTF-8 does not depend on byte order).
* The 32 vs. 16 refer to the number of bits in the
  Unicode internal type; they don't refer to the number of 
  bits in the mark.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-05-14 05:43

Message:
Logged In: YES 
user_id=89016

And if you're using a different encoding for the second 
open call, the data will really be corrupted:
f = codecs.open("/tmp/foo","w","utf-8")
f.write("ää")
f = codecs.open("/tmp/foo","a","latin-1")
f.write("ää")

But how should codec.open be able to determine that the 
file is always opened with the same encoding, or which 
encoding was used for the open call last time? And if it 
could would it have to read the content using the old 
encoding and rewrite it using the new encoding to keep the 
file consistent?

I agree that the BOM names are broken.

> I wonder if this is the right interface, actually. 
> Wouldn't prefixBOM() and checkBOM() methods for streams 
> and strings make more sense? prefixBOM should be 
> idempotent, and checkBOM would return either a codec 
> (with size and endianness determined) or a codec.BOM* 
> constant.

You should consider UTF-16 to be a stateful encoding, so if 
you want to do your output in multiple pieces you have to 
use a stateful encoder, i.e. a StreamWriter:

>>> import codecs, cStringIO as StringIO
>>> stream = StringIO.StringIO()
>>> writer = codecs.getwriter("utf-16")(stream)
>>> writer.write(u"a")
>>> writer.write(u"b") 
>>> stream.getvalue()
'\xff\xfea\x00b\x00'


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470



From noreply@sourceforge.net  Tue Jun  4 03:39:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 19:39:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-563598 ] Core dump with newly built Python
Message-ID: <E17F4E8-0000Ug-00@usw-sf-web4.sourceforge.net>

Bugs item #563598, was opened at 2002-06-02 14:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563598&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Nobody/Anonymous (nobody)
Summary: Core dump with newly built Python

Initial Comment:
This is on what started as a Red Hat 6.0 box currently
running a 2.4.19-pre9-ac3 kernel:

# gdb ./python ./core
GNU gdb 4.17.0.11 with Linux support
...
This GDB was configured as "i386-redhat-linux"...
Core was generated by `./python -E ./setup.py build'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libpthread.so.0...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.
#0  0x8075732 in eval_frame (f=0x812504c) at
Python/ceval.c:1310
1310                            Py_DECREF(u);

(gdb) bt 
#0  0x8075732 in eval_frame (f=0x812504c) at
Python/ceval.c:1310
#1  0x8077bee in PyEval_EvalCodeEx (co=0x81245c0,
globals=0x811ec6c, locals=0x811ec6c, args=0x0,
argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at
Python/ceval.c:2585
#2  0x8079c60 in PyEval_EvalCode (co=0x81245c0,
globals=0x811ec6c, locals=0x811ec6c) at Python/ceval.c:483
#3  0x808b53d in PyImport_ExecCodeModuleEx
(name=0xbfffe4f4 "os", co=0x81245c0, 
    pathname=0xbfffdbf4
"/usr/src/Python-2.2.1/Lib/os.pyc") at Python/import.c:502
#4  0x808ba59 in load_source_module (name=0xbfffe4f4
"os", pathname=0xbfffe064
"/usr/src/Python-2.2.1/Lib/os.py", 
    fp=0x810f710) at Python/import.c:772
#5  0x808c380 in load_module (name=0xbfffe4f4 "os",
fp=0x810f710, buf=0xbfffe064
"/usr/src/Python-2.2.1/Lib/os.py", 
    type=1) at Python/import.c:1356
#6  0x808d015 in import_submodule (mod=0x80e105c,
subname=0xbfffe4f4 "os", fullname=0xbfffe4f4 "os")
    at Python/import.c:1895
#7  0x808cbbd in load_next (mod=0x80e105c,
altmod=0x80e105c, p_name=0xbfffe900, buf=0xbfffe4f4 "os", 
    p_buflen=0xbfffe4f0) at Python/import.c:1751
#8  0x808c7eb in import_module_ex (name=0x0,
globals=0x81151cc, locals=0x81151cc, fromlist=0x80e105c)
    at Python/import.c:1602
#9  0x808dd14 in PyImport_ImportModuleEx
(name=0x8110854 "os", globals=0x81151cc,
locals=0x81151cc, fromlist=0x80e105c)
    at Python/import.c:1643
#10 0x80ca8ac in builtin___import__ (self=0x0,
args=0x81153fc) at Python/bltinmodule.c:40
#11 0x80c6e7d in PyCFunction_Call (func=0x8102998,
arg=0x81153fc, kw=0x0) at Objects/methodobject.c:80
#12 0x80a956e in PyObject_Call (func=0x8102998,
arg=0x81153fc, kw=0x0) at Objects/abstract.c:1684
#13 0x80783e0 in PyEval_CallObjectWithKeywords
(func=0x8102998, arg=0x81153fc, kw=0x0) at
Python/ceval.c:3049
#14 0x8076793 in eval_frame (f=0x8115554) at
Python/ceval.c:1839
#15 0x8077bee in PyEval_EvalCodeEx (co=0x81051d0,
globals=0x81151cc, locals=0x81151cc, args=0x0,
argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at
Python/ceval.c:2585
#16 0x8079c60 in PyEval_EvalCode (co=0x81051d0,
globals=0x81151cc, locals=0x81151cc) at Python/ceval.c:483
#17 0x808b53d in PyImport_ExecCodeModuleEx
(name=0xbffff494 "site", co=0x81051d0, 
    pathname=0xbfffeb94
"/usr/src/Python-2.2.1/Lib/site.pyc") at
Python/import.c:502
#18 0x808ba59 in load_source_module (name=0xbffff494
"site", pathname=0xbffff004
"/usr/src/Python-2.2.1/Lib/site.py", 
    fp=0x810f658) at Python/import.c:772
#19 0x808c380 in load_module (name=0xbffff494 "site",
fp=0x810f658, 
    buf=0xbffff004 "/usr/src/Python-2.2.1/Lib/site.py",
type=1) at Python/import.c:1356
#20 0x808d015 in import_submodule (mod=0x80e105c,
subname=0xbffff494 "site", fullname=0xbffff494 "site")
    at Python/import.c:1895
#21 0x808cbbd in load_next (mod=0x80e105c,
altmod=0x80e105c, p_name=0xbffff8a0, buf=0xbffff494
"site", 
    p_buflen=0xbffff490) at Python/import.c:1751
#22 0x808c7eb in import_module_ex (name=0x0,
globals=0x810f5d4, locals=0x810f5d4, fromlist=0x8107adc)
    at Python/import.c:1602
#23 0x808dd14 in PyImport_ImportModuleEx
(name=0x810f5bc "site", globals=0x810f5d4,
locals=0x810f5d4, 
    fromlist=0x8107adc) at Python/import.c:1643
#24 0x80ca8ac in builtin___import__ (self=0x0,
args=0x8107edc) at Python/bltinmodule.c:40
#25 0x80c6e7d in PyCFunction_Call (func=0x8102998,
arg=0x8107edc, kw=0x0) at Objects/methodobject.c:80
#26 0x80a956e in PyObject_Call (func=0x8102998,
arg=0x8107edc, kw=0x0) at Objects/abstract.c:1684
#27 0x80783e0 in PyEval_CallObjectWithKeywords
(func=0x8102998, arg=0x8107edc, kw=0x0) at
Python/ceval.c:3049
#28 0x80a8bee in PyObject_CallFunction
(callable=0x8102998, format=0x80d5707 "OOOO") at
Objects/abstract.c:1725
#29 0x808d4e6 in PyImport_Import
(module_name=0x810f5a8) at Python/import.c:2048
#30 0x808dc53 in PyImport_ImportModule (name=0x80d6ea3
"site") at Python/import.c:1574
#31 0x809448b in initsite () at Python/pythonrun.c:443
#32 0x8092812 in Py_Initialize () at Python/pythonrun.c:173
#33 0x8053387 in Py_Main (argc=4, argv=0xbffffb54) at
Modules/main.c:322
#34 0x8052dca in main (argc=4, argv=0xbffffb54) at
Modules/python.c:10
#35 0x400699cb in __libc_start_main (main=0x8052db4
<main>, argc=4, argv=0xbffffb54, init=0x80521e4 <_init>, 
    fini=0x80cbed4 <_fini>, rtld_fini=0x4000aea0
<_dl_fini>, stack_end=0xbffffb4c)
    at ../sysdeps/generic/libc-start.c:92
y_Initialize () at Python/pythonrun.c:173

(gdb) print u
$1 = (PyObject *) 0x0


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

>Comment By: Whit Blauvelt (whit)
Date: 2002-06-03 22:39

Message:
Logged In: YES 
user_id=133413

Compiler: gcc version 2.95.3 20010315 (release) (built from tar)
Clean build: pretty much, but see closed bug 535545 (using a
slightly modified       configure file courtesy of Martin v.
Loewis)
Other packages: yes many, no problems
"python -S": yes, a prompt!
Do anything?: I don't really speak Python - something you
can suggest?
Other versions: Yes, 1.5.2 (same compiler); also 2.2.1rc
(forget which), which built fine after correcting
configure's error noted in bug 535545 - whereas this version
dumped core at the step of the make process quoted above
(/python -E ./setup.py build)

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-03 21:20

Message:
Logged In: YES 
user_id=33168

What compiler & version are you using?
Did you start from a clean build?
Have you used the compiler for other packages?
If you start python -S, does that get a prompt?
If so, can you do anything?
Have you successfully built any other versions of Python on
this machine?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563598&group_id=5470



From noreply@sourceforge.net  Tue Jun  4 05:39:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 21:39:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-549731 ] Unicode encoders appears to leak references
Message-ID: <E17F66p-0003lx-00@usw-sf-web3.sourceforge.net>

Bugs item #549731, was opened at 2002-04-28 02:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549731&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Unicode encoders appears to leak references

Initial Comment:
Note the following Debug Python session:

>>> s=u"anything"
[8189 refs]
>>> v=s.encode("utf8")
[10967 refs]
>>> v=s.encode("utf8")
[10968 refs]
>>> v=s.encode("utf8")
[10969 refs]
>>> v=s.encode("utf8")
[10970 refs]

Each call to encode is losing a reference.  Attaching a
test program that demonstrates this in more detail. 
The output from my test program is:

After 10000 iterations, lost 12850 references
[15227 refs]

and for 100000:
After 100000 iterations, lost 102850 references
[105227 refs]

etc.

As far as I can tell, this appears in all Python 2.x
versions.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-03 21:39

Message:
Logged In: NO 

I'm not sure what sort of test you are suggesting I add.  I
think the patch is pretty obvious and reasonable, so MAL
should just check it in or assign it back to me <wink>. 
Earlier the better really.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-03 18:35

Message:
Logged In: YES 
user_id=33168

Patch makes sense to me.
If you add a test, I may be able to catch the problem w/purify
next time I run it (if purify works).

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

Comment By: Mark Hammond (mhammond)
Date: 2002-04-28 03:39

Message:
Logged In: YES 
user_id=14198

Oops - too quick.  All calls to _PyCodec_Lookup() leak.

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

Comment By: Mark Hammond (mhammond)
Date: 2002-04-28 03:05

Message:
Logged In: YES 
user_id=14198

Found it :)  Attaching patch.

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

Comment By: Mark Hammond (mhammond)
Date: 2002-04-28 02:26

Message:
Logged In: YES 
user_id=14198

s/decode/encode/ :)  Also meant to mention problem not
restricted to UTF8 - changing the encoding in the text file
to anything other than 'ascii' seems to leak in the same way.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549731&group_id=5470



From noreply@sourceforge.net  Tue Jun  4 05:42:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 21:42:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-549731 ] Unicode encoders appears to leak references
Message-ID: <E17F69b-0003nv-00@usw-sf-web3.sourceforge.net>

Bugs item #549731, was opened at 2002-04-28 19:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549731&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Unicode encoders appears to leak references

Initial Comment:
Note the following Debug Python session:

>>> s=u"anything"
[8189 refs]
>>> v=s.encode("utf8")
[10967 refs]
>>> v=s.encode("utf8")
[10968 refs]
>>> v=s.encode("utf8")
[10969 refs]
>>> v=s.encode("utf8")
[10970 refs]

Each call to encode is losing a reference.  Attaching a
test program that demonstrates this in more detail. 
The output from my test program is:

After 10000 iterations, lost 12850 references
[15227 refs]

and for 100000:
After 100000 iterations, lost 102850 references
[105227 refs]

etc.

As far as I can tell, this appears in all Python 2.x
versions.

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

>Comment By: Mark Hammond (mhammond)
Date: 2002-06-04 14:42

Message:
Logged In: YES 
user_id=14198

damn sourceforge - it went to the trouble of asking my email
address when I submitted without being logged in, but it
doesn't seem to have done anything with it - so that was me
just incase you weren't sure :)

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-04 14:39

Message:
Logged In: NO 

I'm not sure what sort of test you are suggesting I add.  I
think the patch is pretty obvious and reasonable, so MAL
should just check it in or assign it back to me <wink>. 
Earlier the better really.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-04 11:35

Message:
Logged In: YES 
user_id=33168

Patch makes sense to me.
If you add a test, I may be able to catch the problem w/purify
next time I run it (if purify works).

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

Comment By: Mark Hammond (mhammond)
Date: 2002-04-28 20:39

Message:
Logged In: YES 
user_id=14198

Oops - too quick.  All calls to _PyCodec_Lookup() leak.

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

Comment By: Mark Hammond (mhammond)
Date: 2002-04-28 20:05

Message:
Logged In: YES 
user_id=14198

Found it :)  Attaching patch.

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

Comment By: Mark Hammond (mhammond)
Date: 2002-04-28 19:26

Message:
Logged In: YES 
user_id=14198

s/decode/encode/ :)  Also meant to mention problem not
restricted to UTF8 - changing the encoding in the text file
to anything other than 'ascii' seems to leak in the same way.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549731&group_id=5470



From noreply@sourceforge.net  Tue Jun  4 06:55:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 22:55:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-563060 ] Module can be used as a base class
Message-ID: <E17F7Hg-0002wF-00@usw-sf-web2.sourceforge.net>

Bugs item #563060, was opened at 2002-05-31 15:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563060&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Module can be used as a base class

Initial Comment:
>From python-dev:

> But this is not what I would expect:
> 
>       >>> import string
>       >>> class newstr(string): pass
>       ... 
>       # i would have expected this to raise a TypeError
>       >>> x = newstr()
>       Traceback (most recent call last):
>         File "<stdin>", line 1, in ?
>       TypeError: 'module' object is not callable
> 
> Perhaps this error should be handled when the class
is constructed
> rather than when instantiating an object?

Guido says "the bug is that you can use any module as a
base class"

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-04 01:55

Message:
Logged In: YES 
user_id=6380

Fixed. The module type's constructor now takes a name and an
optional docstring argument (just like the C constructor
PyModule_New()), and nothing else.

Indeed, new.module can now be changed to point to the module
type.

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-06-01 01:30

Message:
Logged In: YES 
user_id=12800

Note that this bug exists in Python 2.2.1 also.

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

Comment By: Phillip J. Eby (pje)
Date: 2002-05-31 16:27

Message:
Logged In: YES 
user_id=56214

More specifically, ModuleType's constructor accepts and
ignores a (name,bases,dict) call signature.  Other objects
will fail at class construction time like this:

>>> class d({}): pass

Traceback (most recent call last):
  File "<pyshell#1>", line 1, in ?
    class d({}): pass
TypeError: dict() takes at most 1 argument (3 given)
>>> class n(1): pass

Traceback (most recent call last):
  File "<pyshell#3>", line 1, in ?
    class n(1): pass
TypeError: int() takes at most 2 arguments (3 given)
>>> class s("s"): pass

Traceback (most recent call last):
  File "<pyshell#5>", line 1, in ?
    class s("s"): pass
TypeError: str() takes at most 1 argument (3 given)
>>> 

Since the module constructor doesn't actually need any
arguments, it should complain the same way the above items do.

Interestingly, while type(module) doesn't complain when
called with excess arguments, the function 'new.module'
does.  Ironically, the docstring for new.module seems to
imply it takes an argument.  Perhaps new.module should
simply refer to type(module), once the latter is fixed.

Another, far more radical fix for this bug would be to
change the constructor to accept the (name,bases,dict)
signature, thus making it possible to subclass a module and
have it work correctly, for some value of "correctly".  :)

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563060&group_id=5470



From noreply@sourceforge.net  Tue Jun  4 06:56:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 03 Jun 2002 22:56:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-563060 ] Module can be used as a base class
Message-ID: <E17F7IY-0002wy-00@usw-sf-web2.sourceforge.net>

Bugs item #563060, was opened at 2002-05-31 15:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563060&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Module can be used as a base class

Initial Comment:
>From python-dev:

> But this is not what I would expect:
> 
>       >>> import string
>       >>> class newstr(string): pass
>       ... 
>       # i would have expected this to raise a TypeError
>       >>> x = newstr()
>       Traceback (most recent call last):
>         File "<stdin>", line 1, in ?
>       TypeError: 'module' object is not callable
> 
> Perhaps this error should be handled when the class
is constructed
> rather than when instantiating an object?

Guido says "the bug is that you can use any module as a
base class"

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-04 01:56

Message:
Logged In: YES 
user_id=6380

This can't be fixed in 2.2.x without changing the module
constructor signature, which I think is too much of an
incompatibility to risk. (Hey, someone might even have a use
fora module as a base class. :-)


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-04 01:55

Message:
Logged In: YES 
user_id=6380

Fixed. The module type's constructor now takes a name and an
optional docstring argument (just like the C constructor
PyModule_New()), and nothing else.

Indeed, new.module can now be changed to point to the module
type.

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-06-01 01:30

Message:
Logged In: YES 
user_id=12800

Note that this bug exists in Python 2.2.1 also.

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

Comment By: Phillip J. Eby (pje)
Date: 2002-05-31 16:27

Message:
Logged In: YES 
user_id=56214

More specifically, ModuleType's constructor accepts and
ignores a (name,bases,dict) call signature.  Other objects
will fail at class construction time like this:

>>> class d({}): pass

Traceback (most recent call last):
  File "<pyshell#1>", line 1, in ?
    class d({}): pass
TypeError: dict() takes at most 1 argument (3 given)
>>> class n(1): pass

Traceback (most recent call last):
  File "<pyshell#3>", line 1, in ?
    class n(1): pass
TypeError: int() takes at most 2 arguments (3 given)
>>> class s("s"): pass

Traceback (most recent call last):
  File "<pyshell#5>", line 1, in ?
    class s("s"): pass
TypeError: str() takes at most 1 argument (3 given)
>>> 

Since the module constructor doesn't actually need any
arguments, it should complain the same way the above items do.

Interestingly, while type(module) doesn't complain when
called with excess arguments, the function 'new.module'
does.  Ironically, the docstring for new.module seems to
imply it takes an argument.  Perhaps new.module should
simply refer to type(module), once the latter is fixed.

Another, far more radical fix for this bug would be to
change the constructor to accept the (name,bases,dict)
signature, thus making it possible to subclass a module and
have it work correctly, for some value of "correctly".  :)

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563060&group_id=5470



From noreply@sourceforge.net  Tue Jun  4 08:19:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 04 Jun 2002 00:19:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-555360 ] UTF-16 BOM handling counterintuitive
Message-ID: <E17F8az-0003QZ-00@usw-sf-web4.sourceforge.net>

Bugs item #555360, was opened at 2002-05-13 09:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Stephen J. Turnbull (yaseppochi)
Assigned to: Walter Dörwald (doerwalter)
Summary: UTF-16 BOM handling counterintuitive

Initial Comment:
A search on "Unicode BOM" doesn't turn up anything related.

Sorry, I don't have a 2.2 or CVS to hand.  Easy enough
to replicate, anyway.  The UTF-16 codec happily
corrupts files by appending a BOM before writing
encoded text to the file:

bash-2.05a$ python
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import codecs
>>> f = codecs.open("/tmp/utf16","w","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = codecs.open("/tmp/utf16","a","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = open("/tmp/utf16","r") 
>>> f.read()
'\xff\xfea\x00\xff\xfea\x00'

Oops.

Also, dir(codecs) shows BOM64* constants are defined
(to what purpose, I have no idea---Microsoft Word files
on Alpha, maybe?), but no BOM8, which actually has some
basis in the standards.  (I think the idea of a UTF-8
signature is a abomination, so you can leave it
out<wink>, but people who do use the BOM as signature
in UTF-8 files would find it useful.)  Hmm ...

>>> codecs.BOM_BE
'\xfe\xff'
>>> codecs.BOM64_BE
'\x00\x00\xfe\xff'
>>> codecs.BOM32_BE
'\xfe\xff'
>>> 

Urk!  I only count 32 bits in BOM64 and 16 bits in
BOM32!  Maybe BOM32_* was intended as an alias for
BOM_*, and BOM64_* was a continuation of the typo, as
it were?

I wonder if this is the right interface, actually. 
Wouldn't prefixBOM() and checkBOM() methods for streams
and strings make more sense?  prefixBOM should be
idempotent, and checkBOM would return either a codec
(with size and endianness determined) or a codec.BOM*
constant.

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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-04 07:19

Message:
Logged In: YES 
user_id=38388

Stephen, how would your BOM8 look like ?

As explained below, the two constants are there
for checking which signature was used, not so 
much for generating it (since this is up to the 
UTF-16/32 codecs).

UTF-8 doesn't need a BOM. Still, it can be used
as signature, so I'D say we add BOM_UTF8_
= '\xef\xbb\xbf' as well.

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

Comment By: Stephen J. Turnbull (yaseppochi)
Date: 2002-06-04 02:09

Message:
Logged In: YES 
user_id=88738

The reason for a BOM8 is for use as a _signature_, cf.
ISO/IEC 10646-1, Annex F, as Amended by Amendment 2. 
Implementers of PEP 263 and those who have to interchange
with MS Notepad and other such applications that use a
leading ZERO-WIDTH NO-BREAK SPACE as a Unicode signature may
find it convenient.  The name BOM8 is for consistency with
the other signatures.

Of course you could trash _all_ the BOM names in favor of
"SIGNATURE_UTF(8|16|32)(_[BL]E)?", which applies in all cases.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 18:39

Message:
Logged In: YES 
user_id=38388

Yes, please (but do leave the existing ones around fof
backward compatiblity).

About the UTF-32 codec: sure why not. Patches are
welcome !

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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 17:19

Message:
Logged In: YES 
user_id=89016

So should I name them BOM_UTF16_* and BOM_UTF32_*?
(IMHO it makes much more sense this way)

Maybe Python should get an UTF-32 codec (see
http://www.unicode.org/unicode/reports/tr19/)?


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 17:02

Message:
Logged In: YES 
user_id=38388

Google'ing around a bit, I can't find a single reference to
something like a special BOM mark on 64-bit machines.

Perhaps this was just some wild idea which has no
real meaning ?

Hmm it could have a meaning for UTF-32... but then it
should really be BOM_UTF16_ vs. BOM_UTF32_..
and have nothing to do with the internal storage format.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 15:41

Message:
Logged In: YES 
user_id=89016

In old code BOM, BOM_LE and BOM_BE are all 16bit, so to be
backwards compatible maybe the attached path diff2.txt
should be applied instead.

But this feels strange, because I'd expect that for a
--enable-unicode=ucs2 build codecs.BOM==codecs.BOM_UCS2 and
for an --enable-unicode=ucs4 build codecs.BOM==codecs.BOM_UCS4.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 14:54

Message:
Logged In: YES 
user_id=89016

> The only requirement we have for BOM is that it matches
> the BOM mark which actually gets written to the file.

But this is independent from the internal byte size of the
character type. UTF-16 always writes two bytes (except for
surrogates).

The attached diff.txt shows what I think the BOM stuff
should look like.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 13:58

Message:
Logged In: YES 
user_id=38388

The only requirement we have for BOM is that it matches
the BOM mark which actually gets written to the file.
The purpose of BOM_UCS2_ and BOM_UCS4_ is
to be able to figure out which underlying Unicode
version was used.

I'm not even sure whether there's a standard for this on
64-bit machines; could be that Microsoft invented something
here... (maybe that's also where the old names originated,
I don't know)

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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 13:35

Message:
Logged In: YES 
user_id=89016

codecs.py says:
BOM = struct.pack('=H', 0xFEFF)
this is not correct in wide build. Should this be changed to
if sys.maxunicode>0xffff:
   BOM = struct.pack('=L', 0x0000FEFF)
else:
   BOM = struct.pack('=H', 0xFEFF)
(with two additional constants BOM_UCS2 and BOM_UCS4?)

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 12:57

Message:
Logged In: YES 
user_id=38388

Ok, please do and then close the bug.

About the append mode: I think you're right. It's
not worth the trouble. Applications can easily figure
this out for themselves (and then use the proper
non-BOM prepending codec name).

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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 12:38

Message:
Logged In: YES 
user_id=89016

> Perhaps we should add aliases called BOM_UCS2_*
> and BOM_UCS4_* and update the documentation
> accordingly ?

Sounds reasonable!

If you want, I'll change it (including documentation)

About the append mode: I don't think it's a good idea to try
to fix this. There is much that can go wrong: seeking an odd
number of bytes, mixed endianness on writes, using a
different encoding on the second write. And what about UTF-8
and UTF-7? What should happen if the user seeks into the
middle of a UTF-[78] byte sequence and starts to write?


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 12:10

Message:
Logged In: YES 
user_id=38388

Hmm, you're right. Something is wrong here.

Perhaps we should add aliases called BOM_UCS2_*
and BOM_UCS4_* and update the documentation
accordingly ?

About the append mode: is file.mode considered to
be part of the file interface or not... I think that a patch
for the UTF-16 codec should check for this attribute
on the stream object to tell whether or not to prepend
the BOM mark.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 11:54

Message:
Logged In: YES 
user_id=89016

> The 32 vs. 16 refer to the number of bits in the
> Unicode internal type; they don't refer to the number of
> bits in the mark.

Yes, but unfortunately the constants in codecs are *not*
BOM32_?? and BOM16_??, but BOM64_?? and BOM32_??.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-02 17:16

Message:
Logged In: YES 
user_id=38388

I agree that opening a file in append mode should 
probably be smarter in the sense that the BOM is
only written in case file.seek() points to the beginning
of the file; patches are welcome.

On the other points:
* I don't see the point of adding an 8-bit BOM mark
  (UTF-8 does not depend on byte order).
* The 32 vs. 16 refer to the number of bits in the
  Unicode internal type; they don't refer to the number of 
  bits in the mark.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-05-13 20:43

Message:
Logged In: YES 
user_id=89016

And if you're using a different encoding for the second 
open call, the data will really be corrupted:
f = codecs.open("/tmp/foo","w","utf-8")
f.write("ää")
f = codecs.open("/tmp/foo","a","latin-1")
f.write("ää")

But how should codec.open be able to determine that the 
file is always opened with the same encoding, or which 
encoding was used for the open call last time? And if it 
could would it have to read the content using the old 
encoding and rewrite it using the new encoding to keep the 
file consistent?

I agree that the BOM names are broken.

> I wonder if this is the right interface, actually. 
> Wouldn't prefixBOM() and checkBOM() methods for streams 
> and strings make more sense? prefixBOM should be 
> idempotent, and checkBOM would return either a codec 
> (with size and endianness determined) or a codec.BOM* 
> constant.

You should consider UTF-16 to be a stateful encoding, so if 
you want to do your output in multiple pieces you have to 
use a stateful encoder, i.e. a StreamWriter:

>>> import codecs, cStringIO as StringIO
>>> stream = StringIO.StringIO()
>>> writer = codecs.getwriter("utf-16")(stream)
>>> writer.write(u"a")
>>> writer.write(u"b") 
>>> stream.getvalue()
'\xff\xfea\x00b\x00'


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470



From noreply@sourceforge.net  Tue Jun  4 08:20:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 04 Jun 2002 00:20:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-549731 ] Unicode encoders appears to leak references
Message-ID: <E17F8c0-0003RV-00@usw-sf-web4.sourceforge.net>

Bugs item #549731, was opened at 2002-04-28 09:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549731&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Unicode encoders appears to leak references

Initial Comment:
Note the following Debug Python session:

>>> s=u"anything"
[8189 refs]
>>> v=s.encode("utf8")
[10967 refs]
>>> v=s.encode("utf8")
[10968 refs]
>>> v=s.encode("utf8")
[10969 refs]
>>> v=s.encode("utf8")
[10970 refs]

Each call to encode is losing a reference.  Attaching a
test program that demonstrates this in more detail. 
The output from my test program is:

After 10000 iterations, lost 12850 references
[15227 refs]

and for 100000:
After 100000 iterations, lost 102850 references
[105227 refs]

etc.

As far as I can tell, this appears in all Python 2.x
versions.

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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-04 07:20

Message:
Logged In: YES 
user_id=38388

I'll have a look later today.

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

Comment By: Mark Hammond (mhammond)
Date: 2002-06-04 04:42

Message:
Logged In: YES 
user_id=14198

damn sourceforge - it went to the trouble of asking my email
address when I submitted without being logged in, but it
doesn't seem to have done anything with it - so that was me
just incase you weren't sure :)

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-04 04:39

Message:
Logged In: NO 

I'm not sure what sort of test you are suggesting I add.  I
think the patch is pretty obvious and reasonable, so MAL
should just check it in or assign it back to me <wink>. 
Earlier the better really.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-04 01:35

Message:
Logged In: YES 
user_id=33168

Patch makes sense to me.
If you add a test, I may be able to catch the problem w/purify
next time I run it (if purify works).

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

Comment By: Mark Hammond (mhammond)
Date: 2002-04-28 10:39

Message:
Logged In: YES 
user_id=14198

Oops - too quick.  All calls to _PyCodec_Lookup() leak.

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

Comment By: Mark Hammond (mhammond)
Date: 2002-04-28 10:05

Message:
Logged In: YES 
user_id=14198

Found it :)  Attaching patch.

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

Comment By: Mark Hammond (mhammond)
Date: 2002-04-28 09:26

Message:
Logged In: YES 
user_id=14198

s/decode/encode/ :)  Also meant to mention problem not
restricted to UTF8 - changing the encoding in the text file
to anything other than 'ascii' seems to leak in the same way.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549731&group_id=5470



From noreply@sourceforge.net  Tue Jun  4 10:28:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 04 Jun 2002 02:28:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-563915 ] getttext defaults with unicode
Message-ID: <E17FAbx-0006ya-00@usw-sf-web3.sourceforge.net>

Bugs item #563915, was opened at 2002-06-03 17:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563915&group_id=5470

Category: Unicode
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Rikard Anglerud (anglerud)
Assigned to: M.-A. Lemburg (lemburg)
Summary: getttext defaults with unicode

Initial Comment:
When using gettext, and a token is not translated, for
example:
print _('Foo')
the output will be 'Foo', as expected. 
However, if that entry is:
print _(u'Foo')
we get:
Traceback (most recent call last):
  File "./translation.py", line 12, in ?
    print _(u'Foo')
  File "/usr/lib/python2.2/gettext.py", line 195, in
ugettext
    return unicode(tmsg, self._charset)
TypeError: decoding Unicode is not supported

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-04 11:28

Message:
Logged In: YES 
user_id=21627

I'm not sure this is a bug: they keys in a message catalog
are really byte strings. So it is an error to use Unicode
strings as arguments to _.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563915&group_id=5470



From noreply@sourceforge.net  Tue Jun  4 10:35:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 04 Jun 2002 02:35:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-563730 ] isinstance() fails to identify obj class
Message-ID: <E17FAig-00073u-00@usw-sf-web3.sourceforge.net>

Bugs item #563730, was opened at 2002-06-03 06:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563730&group_id=5470

Category: None
Group: Python 2.2.1
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Jessica Preston (jesspreston)
Assigned to: Nobody/Anonymous (nobody)
Summary: isinstance() fails to identify obj class

Initial Comment:
The problem seems to be that if I create two objects
using the same class
constructor, but having imported the class differently,
the isinstance() method
fails to identify them as being the same. The problem
only occurs (I think)
when cPickle is used, at least, that was how I managed
to reproduce it.

I have attached an example which includes a README and
a couple of directories:

SampleDir contains
- Simple.py (a simple class that has a compare() method
that uses isinstance)
- Main.py

SampleDir/NestedDir contains
- CreatePickle.py (which creates a Simple() object and
pickles it into the cwd)

Main.py unpickles the Simple object created by
CreatePickle.py, then compares it against a newly
created Simple() object using the Simple.compare()
method. It should raise as Assertion error claiming
that the passed object was not a Simple object.
However, it is.

I looked through existing bug reports and found a very
similar one from 2001 with tracking number 467267 -
this was marked as invalid, I think, but I'm not sure
whether this resolves my problem.

The README contains instructions on running the
example, plus my system information.

I am running RedHat7.1, with kernel 2.4.18 (if
relevant) and
the version of python I am using is Python 2.2.1

I hope that this will demonstrate the problem.

Thanks
-jess

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-04 11:35

Message:
Logged In: YES 
user_id=21627

So this clearly is a user error: you are using a nested
module as the main program, and have this module import
other modules as top-level modules.

Closing this report as invalid.

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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 18:51

Message:
Logged In: YES 
user_id=89016

This has nothing to do with cPickle directly. Bug #467267
seems to report exactly the same problem. Adding the
following code to Simple.compare demonstrates that the
Simple module was imported twice and generated two different
module objects:
		import sys
		print id(sys.modules["Simple"])
		print id(sys.modules["SampleDir.Simple"])

The pickle file includes the module name SampleDir.Simple,
which will implicitly be imported. But Main.py does an
"import Simple".

The simplest example that provokes this error is the
following script (which should be named test.py and started
with "python test.py")
class Foo:
    pass
# reimport the module under a different name
import test
assert isinstance(Foo(), test.Foo)

Moving the CreatePickle.py file from NestedDir to SampleDir
and changing the import from "from SampleDir.Simple import
Simple
" to "from Simple import Simple" fixes the problem.

Maybe Python should use absolute file/package names as keys
for sys.modules?


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563730&group_id=5470



From noreply@sourceforge.net  Tue Jun  4 10:35:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 04 Jun 2002 02:35:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-563915 ] getttext defaults with unicode
Message-ID: <E17FAiq-0001uP-00@usw-sf-web1.sourceforge.net>

Bugs item #563915, was opened at 2002-06-03 15:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563915&group_id=5470

Category: Unicode
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Rikard Anglerud (anglerud)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: getttext defaults with unicode

Initial Comment:
When using gettext, and a token is not translated, for
example:
print _('Foo')
the output will be 'Foo', as expected. 
However, if that entry is:
print _(u'Foo')
we get:
Traceback (most recent call last):
  File "./translation.py", line 12, in ?
    print _(u'Foo')
  File "/usr/lib/python2.2/gettext.py", line 195, in
ugettext
    return unicode(tmsg, self._charset)
TypeError: decoding Unicode is not supported

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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-04 09:35

Message:
Logged In: YES 
user_id=38388

Barry will know what to do...

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-04 09:28

Message:
Logged In: YES 
user_id=21627

I'm not sure this is a bug: they keys in a message catalog
are really byte strings. So it is an error to use Unicode
strings as arguments to _.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563915&group_id=5470



From noreply@sourceforge.net  Tue Jun  4 10:50:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 04 Jun 2002 02:50:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-555360 ] UTF-16 BOM handling counterintuitive
Message-ID: <E17FAxp-0007FT-00@usw-sf-web3.sourceforge.net>

Bugs item #555360, was opened at 2002-05-13 18:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Stephen J. Turnbull (yaseppochi)
Assigned to: Walter Dörwald (doerwalter)
Summary: UTF-16 BOM handling counterintuitive

Initial Comment:
A search on "Unicode BOM" doesn't turn up anything related.

Sorry, I don't have a 2.2 or CVS to hand.  Easy enough
to replicate, anyway.  The UTF-16 codec happily
corrupts files by appending a BOM before writing
encoded text to the file:

bash-2.05a$ python
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import codecs
>>> f = codecs.open("/tmp/utf16","w","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = codecs.open("/tmp/utf16","a","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = open("/tmp/utf16","r") 
>>> f.read()
'\xff\xfea\x00\xff\xfea\x00'

Oops.

Also, dir(codecs) shows BOM64* constants are defined
(to what purpose, I have no idea---Microsoft Word files
on Alpha, maybe?), but no BOM8, which actually has some
basis in the standards.  (I think the idea of a UTF-8
signature is a abomination, so you can leave it
out<wink>, but people who do use the BOM as signature
in UTF-8 files would find it useful.)  Hmm ...

>>> codecs.BOM_BE
'\xfe\xff'
>>> codecs.BOM64_BE
'\x00\x00\xfe\xff'
>>> codecs.BOM32_BE
'\xfe\xff'
>>> 

Urk!  I only count 32 bits in BOM64 and 16 bits in
BOM32!  Maybe BOM32_* was intended as an alias for
BOM_*, and BOM64_* was a continuation of the typo, as
it were?

I wonder if this is the right interface, actually. 
Wouldn't prefixBOM() and checkBOM() methods for streams
and strings make more sense?  prefixBOM should be
idempotent, and checkBOM would return either a codec
(with size and endianness determined) or a codec.BOM*
constant.

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

>Comment By: Stephen J. Turnbull (yaseppochi)
Date: 2002-06-04 18:50

Message:
Logged In: YES 
user_id=88738

"My" BOM8 would look exactly as you give it:  '\xef\xbb\xbf'
This would be useful in the same kinds of contexts as the
BOM16/32 variants, I would think.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-04 16:19

Message:
Logged In: YES 
user_id=38388

Stephen, how would your BOM8 look like ?

As explained below, the two constants are there
for checking which signature was used, not so 
much for generating it (since this is up to the 
UTF-16/32 codecs).

UTF-8 doesn't need a BOM. Still, it can be used
as signature, so I'D say we add BOM_UTF8_
= '\xef\xbb\xbf' as well.

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

Comment By: Stephen J. Turnbull (yaseppochi)
Date: 2002-06-04 11:09

Message:
Logged In: YES 
user_id=88738

The reason for a BOM8 is for use as a _signature_, cf.
ISO/IEC 10646-1, Annex F, as Amended by Amendment 2. 
Implementers of PEP 263 and those who have to interchange
with MS Notepad and other such applications that use a
leading ZERO-WIDTH NO-BREAK SPACE as a Unicode signature may
find it convenient.  The name BOM8 is for consistency with
the other signatures.

Of course you could trash _all_ the BOM names in favor of
"SIGNATURE_UTF(8|16|32)(_[BL]E)?", which applies in all cases.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-04 03:39

Message:
Logged In: YES 
user_id=38388

Yes, please (but do leave the existing ones around fof
backward compatiblity).

About the UTF-32 codec: sure why not. Patches are
welcome !

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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-04 02:19

Message:
Logged In: YES 
user_id=89016

So should I name them BOM_UTF16_* and BOM_UTF32_*?
(IMHO it makes much more sense this way)

Maybe Python should get an UTF-32 codec (see
http://www.unicode.org/unicode/reports/tr19/)?


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-04 02:02

Message:
Logged In: YES 
user_id=38388

Google'ing around a bit, I can't find a single reference to
something like a special BOM mark on 64-bit machines.

Perhaps this was just some wild idea which has no
real meaning ?

Hmm it could have a meaning for UTF-32... but then it
should really be BOM_UTF16_ vs. BOM_UTF32_..
and have nothing to do with the internal storage format.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-04 00:41

Message:
Logged In: YES 
user_id=89016

In old code BOM, BOM_LE and BOM_BE are all 16bit, so to be
backwards compatible maybe the attached path diff2.txt
should be applied instead.

But this feels strange, because I'd expect that for a
--enable-unicode=ucs2 build codecs.BOM==codecs.BOM_UCS2 and
for an --enable-unicode=ucs4 build codecs.BOM==codecs.BOM_UCS4.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 23:54

Message:
Logged In: YES 
user_id=89016

> The only requirement we have for BOM is that it matches
> the BOM mark which actually gets written to the file.

But this is independent from the internal byte size of the
character type. UTF-16 always writes two bytes (except for
surrogates).

The attached diff.txt shows what I think the BOM stuff
should look like.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 22:58

Message:
Logged In: YES 
user_id=38388

The only requirement we have for BOM is that it matches
the BOM mark which actually gets written to the file.
The purpose of BOM_UCS2_ and BOM_UCS4_ is
to be able to figure out which underlying Unicode
version was used.

I'm not even sure whether there's a standard for this on
64-bit machines; could be that Microsoft invented something
here... (maybe that's also where the old names originated,
I don't know)

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 22:35

Message:
Logged In: YES 
user_id=89016

codecs.py says:
BOM = struct.pack('=H', 0xFEFF)
this is not correct in wide build. Should this be changed to
if sys.maxunicode>0xffff:
   BOM = struct.pack('=L', 0x0000FEFF)
else:
   BOM = struct.pack('=H', 0xFEFF)
(with two additional constants BOM_UCS2 and BOM_UCS4?)

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 21:57

Message:
Logged In: YES 
user_id=38388

Ok, please do and then close the bug.

About the append mode: I think you're right. It's
not worth the trouble. Applications can easily figure
this out for themselves (and then use the proper
non-BOM prepending codec name).

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 21:38

Message:
Logged In: YES 
user_id=89016

> Perhaps we should add aliases called BOM_UCS2_*
> and BOM_UCS4_* and update the documentation
> accordingly ?

Sounds reasonable!

If you want, I'll change it (including documentation)

About the append mode: I don't think it's a good idea to try
to fix this. There is much that can go wrong: seeking an odd
number of bytes, mixed endianness on writes, using a
different encoding on the second write. And what about UTF-8
and UTF-7? What should happen if the user seeks into the
middle of a UTF-[78] byte sequence and starts to write?


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 21:10

Message:
Logged In: YES 
user_id=38388

Hmm, you're right. Something is wrong here.

Perhaps we should add aliases called BOM_UCS2_*
and BOM_UCS4_* and update the documentation
accordingly ?

About the append mode: is file.mode considered to
be part of the file interface or not... I think that a patch
for the UTF-16 codec should check for this attribute
on the stream object to tell whether or not to prepend
the BOM mark.


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 20:54

Message:
Logged In: YES 
user_id=89016

> The 32 vs. 16 refer to the number of bits in the
> Unicode internal type; they don't refer to the number of
> bits in the mark.

Yes, but unfortunately the constants in codecs are *not*
BOM32_?? and BOM16_??, but BOM64_?? and BOM32_??.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 02:16

Message:
Logged In: YES 
user_id=38388

I agree that opening a file in append mode should 
probably be smarter in the sense that the BOM is
only written in case file.seek() points to the beginning
of the file; patches are welcome.

On the other points:
* I don't see the point of adding an 8-bit BOM mark
  (UTF-8 does not depend on byte order).
* The 32 vs. 16 refer to the number of bits in the
  Unicode internal type; they don't refer to the number of 
  bits in the mark.


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2002-05-14 05:43

Message:
Logged In: YES 
user_id=89016

And if you're using a different encoding for the second 
open call, the data will really be corrupted:
f = codecs.open("/tmp/foo","w","utf-8")
f.write("ää")
f = codecs.open("/tmp/foo","a","latin-1")
f.write("ää")

But how should codec.open be able to determine that the 
file is always opened with the same encoding, or which 
encoding was used for the open call last time? And if it 
could would it have to read the content using the old 
encoding and rewrite it using the new encoding to keep the 
file consistent?

I agree that the BOM names are broken.

> I wonder if this is the right interface, actually. 
> Wouldn't prefixBOM() and checkBOM() methods for streams 
> and strings make more sense? prefixBOM should be 
> idempotent, and checkBOM would return either a codec 
> (with size and endianness determined) or a codec.BOM* 
> constant.

You should consider UTF-16 to be a stateful encoding, so if 
you want to do your output in multiple pieces you have to 
use a stateful encoder, i.e. a StreamWriter:

>>> import codecs, cStringIO as StringIO
>>> stream = StringIO.StringIO()
>>> writer = codecs.getwriter("utf-16")(stream)
>>> writer.write(u"a")
>>> writer.write(u"b") 
>>> stream.getvalue()
'\xff\xfea\x00b\x00'


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470



From noreply@sourceforge.net  Tue Jun  4 11:30:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 04 Jun 2002 03:30:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-563598 ] Core dump with newly built Python
Message-ID: <E17FBaX-0007jN-00@usw-sf-web3.sourceforge.net>

Bugs item #563598, was opened at 2002-06-02 18:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563598&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Nobody/Anonymous (nobody)
Summary: Core dump with newly built Python

Initial Comment:
This is on what started as a Red Hat 6.0 box currently
running a 2.4.19-pre9-ac3 kernel:

# gdb ./python ./core
GNU gdb 4.17.0.11 with Linux support
...
This GDB was configured as "i386-redhat-linux"...
Core was generated by `./python -E ./setup.py build'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libpthread.so.0...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.
#0  0x8075732 in eval_frame (f=0x812504c) at
Python/ceval.c:1310
1310                            Py_DECREF(u);

(gdb) bt 
#0  0x8075732 in eval_frame (f=0x812504c) at
Python/ceval.c:1310
#1  0x8077bee in PyEval_EvalCodeEx (co=0x81245c0,
globals=0x811ec6c, locals=0x811ec6c, args=0x0,
argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at
Python/ceval.c:2585
#2  0x8079c60 in PyEval_EvalCode (co=0x81245c0,
globals=0x811ec6c, locals=0x811ec6c) at Python/ceval.c:483
#3  0x808b53d in PyImport_ExecCodeModuleEx
(name=0xbfffe4f4 "os", co=0x81245c0, 
    pathname=0xbfffdbf4
"/usr/src/Python-2.2.1/Lib/os.pyc") at Python/import.c:502
#4  0x808ba59 in load_source_module (name=0xbfffe4f4
"os", pathname=0xbfffe064
"/usr/src/Python-2.2.1/Lib/os.py", 
    fp=0x810f710) at Python/import.c:772
#5  0x808c380 in load_module (name=0xbfffe4f4 "os",
fp=0x810f710, buf=0xbfffe064
"/usr/src/Python-2.2.1/Lib/os.py", 
    type=1) at Python/import.c:1356
#6  0x808d015 in import_submodule (mod=0x80e105c,
subname=0xbfffe4f4 "os", fullname=0xbfffe4f4 "os")
    at Python/import.c:1895
#7  0x808cbbd in load_next (mod=0x80e105c,
altmod=0x80e105c, p_name=0xbfffe900, buf=0xbfffe4f4 "os", 
    p_buflen=0xbfffe4f0) at Python/import.c:1751
#8  0x808c7eb in import_module_ex (name=0x0,
globals=0x81151cc, locals=0x81151cc, fromlist=0x80e105c)
    at Python/import.c:1602
#9  0x808dd14 in PyImport_ImportModuleEx
(name=0x8110854 "os", globals=0x81151cc,
locals=0x81151cc, fromlist=0x80e105c)
    at Python/import.c:1643
#10 0x80ca8ac in builtin___import__ (self=0x0,
args=0x81153fc) at Python/bltinmodule.c:40
#11 0x80c6e7d in PyCFunction_Call (func=0x8102998,
arg=0x81153fc, kw=0x0) at Objects/methodobject.c:80
#12 0x80a956e in PyObject_Call (func=0x8102998,
arg=0x81153fc, kw=0x0) at Objects/abstract.c:1684
#13 0x80783e0 in PyEval_CallObjectWithKeywords
(func=0x8102998, arg=0x81153fc, kw=0x0) at
Python/ceval.c:3049
#14 0x8076793 in eval_frame (f=0x8115554) at
Python/ceval.c:1839
#15 0x8077bee in PyEval_EvalCodeEx (co=0x81051d0,
globals=0x81151cc, locals=0x81151cc, args=0x0,
argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at
Python/ceval.c:2585
#16 0x8079c60 in PyEval_EvalCode (co=0x81051d0,
globals=0x81151cc, locals=0x81151cc) at Python/ceval.c:483
#17 0x808b53d in PyImport_ExecCodeModuleEx
(name=0xbffff494 "site", co=0x81051d0, 
    pathname=0xbfffeb94
"/usr/src/Python-2.2.1/Lib/site.pyc") at
Python/import.c:502
#18 0x808ba59 in load_source_module (name=0xbffff494
"site", pathname=0xbffff004
"/usr/src/Python-2.2.1/Lib/site.py", 
    fp=0x810f658) at Python/import.c:772
#19 0x808c380 in load_module (name=0xbffff494 "site",
fp=0x810f658, 
    buf=0xbffff004 "/usr/src/Python-2.2.1/Lib/site.py",
type=1) at Python/import.c:1356
#20 0x808d015 in import_submodule (mod=0x80e105c,
subname=0xbffff494 "site", fullname=0xbffff494 "site")
    at Python/import.c:1895
#21 0x808cbbd in load_next (mod=0x80e105c,
altmod=0x80e105c, p_name=0xbffff8a0, buf=0xbffff494
"site", 
    p_buflen=0xbffff490) at Python/import.c:1751
#22 0x808c7eb in import_module_ex (name=0x0,
globals=0x810f5d4, locals=0x810f5d4, fromlist=0x8107adc)
    at Python/import.c:1602
#23 0x808dd14 in PyImport_ImportModuleEx
(name=0x810f5bc "site", globals=0x810f5d4,
locals=0x810f5d4, 
    fromlist=0x8107adc) at Python/import.c:1643
#24 0x80ca8ac in builtin___import__ (self=0x0,
args=0x8107edc) at Python/bltinmodule.c:40
#25 0x80c6e7d in PyCFunction_Call (func=0x8102998,
arg=0x8107edc, kw=0x0) at Objects/methodobject.c:80
#26 0x80a956e in PyObject_Call (func=0x8102998,
arg=0x8107edc, kw=0x0) at Objects/abstract.c:1684
#27 0x80783e0 in PyEval_CallObjectWithKeywords
(func=0x8102998, arg=0x8107edc, kw=0x0) at
Python/ceval.c:3049
#28 0x80a8bee in PyObject_CallFunction
(callable=0x8102998, format=0x80d5707 "OOOO") at
Objects/abstract.c:1725
#29 0x808d4e6 in PyImport_Import
(module_name=0x810f5a8) at Python/import.c:2048
#30 0x808dc53 in PyImport_ImportModule (name=0x80d6ea3
"site") at Python/import.c:1574
#31 0x809448b in initsite () at Python/pythonrun.c:443
#32 0x8092812 in Py_Initialize () at Python/pythonrun.c:173
#33 0x8053387 in Py_Main (argc=4, argv=0xbffffb54) at
Modules/main.c:322
#34 0x8052dca in main (argc=4, argv=0xbffffb54) at
Modules/python.c:10
#35 0x400699cb in __libc_start_main (main=0x8052db4
<main>, argc=4, argv=0xbffffb54, init=0x80521e4 <_init>, 
    fini=0x80cbed4 <_fini>, rtld_fini=0x4000aea0
<_dl_fini>, stack_end=0xbffffb4c)
    at ../sysdeps/generic/libc-start.c:92
y_Initialize () at Python/pythonrun.c:173

(gdb) print u
$1 = (PyObject *) 0x0


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-06-04 10:30

Message:
Logged In: YES 
user_id=6656

One thing to try is deleting .pyc files.  I don't think that'll help, 
but it might...


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-06-04 02:39

Message:
Logged In: YES 
user_id=133413

Compiler: gcc version 2.95.3 20010315 (release) (built from tar)
Clean build: pretty much, but see closed bug 535545 (using a
slightly modified       configure file courtesy of Martin v.
Loewis)
Other packages: yes many, no problems
"python -S": yes, a prompt!
Do anything?: I don't really speak Python - something you
can suggest?
Other versions: Yes, 1.5.2 (same compiler); also 2.2.1rc
(forget which), which built fine after correcting
configure's error noted in bug 535545 - whereas this version
dumped core at the step of the make process quoted above
(/python -E ./setup.py build)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-04 01:20

Message:
Logged In: YES 
user_id=33168

What compiler & version are you using?
Did you start from a clean build?
Have you used the compiler for other packages?
If you start python -S, does that get a prompt?
If so, can you do anything?
Have you successfully built any other versions of Python on
this machine?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563598&group_id=5470



From noreply@sourceforge.net  Tue Jun  4 16:19:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 04 Jun 2002 08:19:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-555360 ] UTF-16 BOM handling counterintuitive
Message-ID: <E17FG5d-0001f9-00@usw-sf-web3.sourceforge.net>

Bugs item #555360, was opened at 2002-05-13 11:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470

Category: Unicode
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: Stephen J. Turnbull (yaseppochi)
Assigned to: Walter Dörwald (doerwalter)
Summary: UTF-16 BOM handling counterintuitive

Initial Comment:
A search on "Unicode BOM" doesn't turn up anything related.

Sorry, I don't have a 2.2 or CVS to hand.  Easy enough
to replicate, anyway.  The UTF-16 codec happily
corrupts files by appending a BOM before writing
encoded text to the file:

bash-2.05a$ python
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import codecs
>>> f = codecs.open("/tmp/utf16","w","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = codecs.open("/tmp/utf16","a","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = open("/tmp/utf16","r") 
>>> f.read()
'\xff\xfea\x00\xff\xfea\x00'

Oops.

Also, dir(codecs) shows BOM64* constants are defined
(to what purpose, I have no idea---Microsoft Word files
on Alpha, maybe?), but no BOM8, which actually has some
basis in the standards.  (I think the idea of a UTF-8
signature is a abomination, so you can leave it
out<wink>, but people who do use the BOM as signature
in UTF-8 files would find it useful.)  Hmm ...

>>> codecs.BOM_BE
'\xfe\xff'
>>> codecs.BOM64_BE
'\x00\x00\xfe\xff'
>>> codecs.BOM32_BE
'\xfe\xff'
>>> 

Urk!  I only count 32 bits in BOM64 and 16 bits in
BOM32!  Maybe BOM32_* was intended as an alias for
BOM_*, and BOM64_* was a continuation of the typo, as
it were?

I wonder if this is the right interface, actually. 
Wouldn't prefixBOM() and checkBOM() methods for streams
and strings make more sense?  prefixBOM should be
idempotent, and checkBOM would return either a codec
(with size and endianness determined) or a codec.BOM*
constant.

----------------------------------------------------------------------

>Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-04 17:19

Message:
Logged In: YES 
user_id=89016

Checked in as:
Misc/NEWS 1.413
Lib/codecs.py 1.25
Doc/lib/libcodecs.tex 1.9


----------------------------------------------------------------------

Comment By: Stephen J. Turnbull (yaseppochi)
Date: 2002-06-04 11:50

Message:
Logged In: YES 
user_id=88738

"My" BOM8 would look exactly as you give it:  '\xef\xbb\xbf'
This would be useful in the same kinds of contexts as the
BOM16/32 variants, I would think.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-04 09:19

Message:
Logged In: YES 
user_id=38388

Stephen, how would your BOM8 look like ?

As explained below, the two constants are there
for checking which signature was used, not so 
much for generating it (since this is up to the 
UTF-16/32 codecs).

UTF-8 doesn't need a BOM. Still, it can be used
as signature, so I'D say we add BOM_UTF8_
= '\xef\xbb\xbf' as well.

----------------------------------------------------------------------

Comment By: Stephen J. Turnbull (yaseppochi)
Date: 2002-06-04 04:09

Message:
Logged In: YES 
user_id=88738

The reason for a BOM8 is for use as a _signature_, cf.
ISO/IEC 10646-1, Annex F, as Amended by Amendment 2. 
Implementers of PEP 263 and those who have to interchange
with MS Notepad and other such applications that use a
leading ZERO-WIDTH NO-BREAK SPACE as a Unicode signature may
find it convenient.  The name BOM8 is for consistency with
the other signatures.

Of course you could trash _all_ the BOM names in favor of
"SIGNATURE_UTF(8|16|32)(_[BL]E)?", which applies in all cases.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 20:39

Message:
Logged In: YES 
user_id=38388

Yes, please (but do leave the existing ones around fof
backward compatiblity).

About the UTF-32 codec: sure why not. Patches are
welcome !

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 19:19

Message:
Logged In: YES 
user_id=89016

So should I name them BOM_UTF16_* and BOM_UTF32_*?
(IMHO it makes much more sense this way)

Maybe Python should get an UTF-32 codec (see
http://www.unicode.org/unicode/reports/tr19/)?


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 19:02

Message:
Logged In: YES 
user_id=38388

Google'ing around a bit, I can't find a single reference to
something like a special BOM mark on 64-bit machines.

Perhaps this was just some wild idea which has no
real meaning ?

Hmm it could have a meaning for UTF-32... but then it
should really be BOM_UTF16_ vs. BOM_UTF32_..
and have nothing to do with the internal storage format.


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 17:41

Message:
Logged In: YES 
user_id=89016

In old code BOM, BOM_LE and BOM_BE are all 16bit, so to be
backwards compatible maybe the attached path diff2.txt
should be applied instead.

But this feels strange, because I'd expect that for a
--enable-unicode=ucs2 build codecs.BOM==codecs.BOM_UCS2 and
for an --enable-unicode=ucs4 build codecs.BOM==codecs.BOM_UCS4.


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 16:54

Message:
Logged In: YES 
user_id=89016

> The only requirement we have for BOM is that it matches
> the BOM mark which actually gets written to the file.

But this is independent from the internal byte size of the
character type. UTF-16 always writes two bytes (except for
surrogates).

The attached diff.txt shows what I think the BOM stuff
should look like.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 15:58

Message:
Logged In: YES 
user_id=38388

The only requirement we have for BOM is that it matches
the BOM mark which actually gets written to the file.
The purpose of BOM_UCS2_ and BOM_UCS4_ is
to be able to figure out which underlying Unicode
version was used.

I'm not even sure whether there's a standard for this on
64-bit machines; could be that Microsoft invented something
here... (maybe that's also where the old names originated,
I don't know)

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 15:35

Message:
Logged In: YES 
user_id=89016

codecs.py says:
BOM = struct.pack('=H', 0xFEFF)
this is not correct in wide build. Should this be changed to
if sys.maxunicode>0xffff:
   BOM = struct.pack('=L', 0x0000FEFF)
else:
   BOM = struct.pack('=H', 0xFEFF)
(with two additional constants BOM_UCS2 and BOM_UCS4?)

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 14:57

Message:
Logged In: YES 
user_id=38388

Ok, please do and then close the bug.

About the append mode: I think you're right. It's
not worth the trouble. Applications can easily figure
this out for themselves (and then use the proper
non-BOM prepending codec name).

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 14:38

Message:
Logged In: YES 
user_id=89016

> Perhaps we should add aliases called BOM_UCS2_*
> and BOM_UCS4_* and update the documentation
> accordingly ?

Sounds reasonable!

If you want, I'll change it (including documentation)

About the append mode: I don't think it's a good idea to try
to fix this. There is much that can go wrong: seeking an odd
number of bytes, mixed endianness on writes, using a
different encoding on the second write. And what about UTF-8
and UTF-7? What should happen if the user seeks into the
middle of a UTF-[78] byte sequence and starts to write?


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-03 14:10

Message:
Logged In: YES 
user_id=38388

Hmm, you're right. Something is wrong here.

Perhaps we should add aliases called BOM_UCS2_*
and BOM_UCS4_* and update the documentation
accordingly ?

About the append mode: is file.mode considered to
be part of the file interface or not... I think that a patch
for the UTF-16 codec should check for this attribute
on the stream object to tell whether or not to prepend
the BOM mark.


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-03 13:54

Message:
Logged In: YES 
user_id=89016

> The 32 vs. 16 refer to the number of bits in the
> Unicode internal type; they don't refer to the number of
> bits in the mark.

Yes, but unfortunately the constants in codecs are *not*
BOM32_?? and BOM16_??, but BOM64_?? and BOM32_??.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-02 19:16

Message:
Logged In: YES 
user_id=38388

I agree that opening a file in append mode should 
probably be smarter in the sense that the BOM is
only written in case file.seek() points to the beginning
of the file; patches are welcome.

On the other points:
* I don't see the point of adding an 8-bit BOM mark
  (UTF-8 does not depend on byte order).
* The 32 vs. 16 refer to the number of bits in the
  Unicode internal type; they don't refer to the number of 
  bits in the mark.


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2002-05-13 22:43

Message:
Logged In: YES 
user_id=89016

And if you're using a different encoding for the second 
open call, the data will really be corrupted:
f = codecs.open("/tmp/foo","w","utf-8")
f.write("ää")
f = codecs.open("/tmp/foo","a","latin-1")
f.write("ää")

But how should codec.open be able to determine that the 
file is always opened with the same encoding, or which 
encoding was used for the open call last time? And if it 
could would it have to read the content using the old 
encoding and rewrite it using the new encoding to keep the 
file consistent?

I agree that the BOM names are broken.

> I wonder if this is the right interface, actually. 
> Wouldn't prefixBOM() and checkBOM() methods for streams 
> and strings make more sense? prefixBOM should be 
> idempotent, and checkBOM would return either a codec 
> (with size and endianness determined) or a codec.BOM* 
> constant.

You should consider UTF-16 to be a stateful encoding, so if 
you want to do your output in multiple pieces you have to 
use a stateful encoder, i.e. a StreamWriter:

>>> import codecs, cStringIO as StringIO
>>> stream = StringIO.StringIO()
>>> writer = codecs.getwriter("utf-16")(stream)
>>> writer.write(u"a")
>>> writer.write(u"b") 
>>> stream.getvalue()
'\xff\xfea\x00b\x00'


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470



From noreply@sourceforge.net  Tue Jun  4 16:35:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 04 Jun 2002 08:35:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-563598 ] Core dump with newly built Python
Message-ID: <E17FGL8-0000py-00@usw-sf-web2.sourceforge.net>

Bugs item #563598, was opened at 2002-06-02 14:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563598&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Nobody/Anonymous (nobody)
Summary: Core dump with newly built Python

Initial Comment:
This is on what started as a Red Hat 6.0 box currently
running a 2.4.19-pre9-ac3 kernel:

# gdb ./python ./core
GNU gdb 4.17.0.11 with Linux support
...
This GDB was configured as "i386-redhat-linux"...
Core was generated by `./python -E ./setup.py build'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libpthread.so.0...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.
#0  0x8075732 in eval_frame (f=0x812504c) at
Python/ceval.c:1310
1310                            Py_DECREF(u);

(gdb) bt 
#0  0x8075732 in eval_frame (f=0x812504c) at
Python/ceval.c:1310
#1  0x8077bee in PyEval_EvalCodeEx (co=0x81245c0,
globals=0x811ec6c, locals=0x811ec6c, args=0x0,
argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at
Python/ceval.c:2585
#2  0x8079c60 in PyEval_EvalCode (co=0x81245c0,
globals=0x811ec6c, locals=0x811ec6c) at Python/ceval.c:483
#3  0x808b53d in PyImport_ExecCodeModuleEx
(name=0xbfffe4f4 "os", co=0x81245c0, 
    pathname=0xbfffdbf4
"/usr/src/Python-2.2.1/Lib/os.pyc") at Python/import.c:502
#4  0x808ba59 in load_source_module (name=0xbfffe4f4
"os", pathname=0xbfffe064
"/usr/src/Python-2.2.1/Lib/os.py", 
    fp=0x810f710) at Python/import.c:772
#5  0x808c380 in load_module (name=0xbfffe4f4 "os",
fp=0x810f710, buf=0xbfffe064
"/usr/src/Python-2.2.1/Lib/os.py", 
    type=1) at Python/import.c:1356
#6  0x808d015 in import_submodule (mod=0x80e105c,
subname=0xbfffe4f4 "os", fullname=0xbfffe4f4 "os")
    at Python/import.c:1895
#7  0x808cbbd in load_next (mod=0x80e105c,
altmod=0x80e105c, p_name=0xbfffe900, buf=0xbfffe4f4 "os", 
    p_buflen=0xbfffe4f0) at Python/import.c:1751
#8  0x808c7eb in import_module_ex (name=0x0,
globals=0x81151cc, locals=0x81151cc, fromlist=0x80e105c)
    at Python/import.c:1602
#9  0x808dd14 in PyImport_ImportModuleEx
(name=0x8110854 "os", globals=0x81151cc,
locals=0x81151cc, fromlist=0x80e105c)
    at Python/import.c:1643
#10 0x80ca8ac in builtin___import__ (self=0x0,
args=0x81153fc) at Python/bltinmodule.c:40
#11 0x80c6e7d in PyCFunction_Call (func=0x8102998,
arg=0x81153fc, kw=0x0) at Objects/methodobject.c:80
#12 0x80a956e in PyObject_Call (func=0x8102998,
arg=0x81153fc, kw=0x0) at Objects/abstract.c:1684
#13 0x80783e0 in PyEval_CallObjectWithKeywords
(func=0x8102998, arg=0x81153fc, kw=0x0) at
Python/ceval.c:3049
#14 0x8076793 in eval_frame (f=0x8115554) at
Python/ceval.c:1839
#15 0x8077bee in PyEval_EvalCodeEx (co=0x81051d0,
globals=0x81151cc, locals=0x81151cc, args=0x0,
argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at
Python/ceval.c:2585
#16 0x8079c60 in PyEval_EvalCode (co=0x81051d0,
globals=0x81151cc, locals=0x81151cc) at Python/ceval.c:483
#17 0x808b53d in PyImport_ExecCodeModuleEx
(name=0xbffff494 "site", co=0x81051d0, 
    pathname=0xbfffeb94
"/usr/src/Python-2.2.1/Lib/site.pyc") at
Python/import.c:502
#18 0x808ba59 in load_source_module (name=0xbffff494
"site", pathname=0xbffff004
"/usr/src/Python-2.2.1/Lib/site.py", 
    fp=0x810f658) at Python/import.c:772
#19 0x808c380 in load_module (name=0xbffff494 "site",
fp=0x810f658, 
    buf=0xbffff004 "/usr/src/Python-2.2.1/Lib/site.py",
type=1) at Python/import.c:1356
#20 0x808d015 in import_submodule (mod=0x80e105c,
subname=0xbffff494 "site", fullname=0xbffff494 "site")
    at Python/import.c:1895
#21 0x808cbbd in load_next (mod=0x80e105c,
altmod=0x80e105c, p_name=0xbffff8a0, buf=0xbffff494
"site", 
    p_buflen=0xbffff490) at Python/import.c:1751
#22 0x808c7eb in import_module_ex (name=0x0,
globals=0x810f5d4, locals=0x810f5d4, fromlist=0x8107adc)
    at Python/import.c:1602
#23 0x808dd14 in PyImport_ImportModuleEx
(name=0x810f5bc "site", globals=0x810f5d4,
locals=0x810f5d4, 
    fromlist=0x8107adc) at Python/import.c:1643
#24 0x80ca8ac in builtin___import__ (self=0x0,
args=0x8107edc) at Python/bltinmodule.c:40
#25 0x80c6e7d in PyCFunction_Call (func=0x8102998,
arg=0x8107edc, kw=0x0) at Objects/methodobject.c:80
#26 0x80a956e in PyObject_Call (func=0x8102998,
arg=0x8107edc, kw=0x0) at Objects/abstract.c:1684
#27 0x80783e0 in PyEval_CallObjectWithKeywords
(func=0x8102998, arg=0x8107edc, kw=0x0) at
Python/ceval.c:3049
#28 0x80a8bee in PyObject_CallFunction
(callable=0x8102998, format=0x80d5707 "OOOO") at
Objects/abstract.c:1725
#29 0x808d4e6 in PyImport_Import
(module_name=0x810f5a8) at Python/import.c:2048
#30 0x808dc53 in PyImport_ImportModule (name=0x80d6ea3
"site") at Python/import.c:1574
#31 0x809448b in initsite () at Python/pythonrun.c:443
#32 0x8092812 in Py_Initialize () at Python/pythonrun.c:173
#33 0x8053387 in Py_Main (argc=4, argv=0xbffffb54) at
Modules/main.c:322
#34 0x8052dca in main (argc=4, argv=0xbffffb54) at
Modules/python.c:10
#35 0x400699cb in __libc_start_main (main=0x8052db4
<main>, argc=4, argv=0xbffffb54, init=0x80521e4 <_init>, 
    fini=0x80cbed4 <_fini>, rtld_fini=0x4000aea0
<_dl_fini>, stack_end=0xbffffb4c)
    at ../sysdeps/generic/libc-start.c:92
y_Initialize () at Python/pythonrun.c:173

(gdb) print u
$1 = (PyObject *) 0x0


----------------------------------------------------------------------

>Comment By: Whit Blauvelt (whit)
Date: 2002-06-04 11:35

Message:
Logged In: YES 
user_id=133413

Deleting .pyc files does not help.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-06-04 06:30

Message:
Logged In: YES 
user_id=6656

One thing to try is deleting .pyc files.  I don't think that'll help, 
but it might...


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-06-03 22:39

Message:
Logged In: YES 
user_id=133413

Compiler: gcc version 2.95.3 20010315 (release) (built from tar)
Clean build: pretty much, but see closed bug 535545 (using a
slightly modified       configure file courtesy of Martin v.
Loewis)
Other packages: yes many, no problems
"python -S": yes, a prompt!
Do anything?: I don't really speak Python - something you
can suggest?
Other versions: Yes, 1.5.2 (same compiler); also 2.2.1rc
(forget which), which built fine after correcting
configure's error noted in bug 535545 - whereas this version
dumped core at the step of the make process quoted above
(/python -E ./setup.py build)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-03 21:20

Message:
Logged In: YES 
user_id=33168

What compiler & version are you using?
Did you start from a clean build?
Have you used the compiler for other packages?
If you start python -S, does that get a prompt?
If so, can you do anything?
Have you successfully built any other versions of Python on
this machine?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563598&group_id=5470



From noreply@sourceforge.net  Tue Jun  4 16:54:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 04 Jun 2002 08:54:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-563915 ] getttext defaults with unicode
Message-ID: <E17FGe0-0000zZ-00@usw-sf-web2.sourceforge.net>

Bugs item #563915, was opened at 2002-06-03 11:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563915&group_id=5470

Category: Unicode
Group: Python 2.2.1
Status: Open
>Resolution: Wont Fix
Priority: 5
Submitted By: Rikard Anglerud (anglerud)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: getttext defaults with unicode

Initial Comment:
When using gettext, and a token is not translated, for
example:
print _('Foo')
the output will be 'Foo', as expected. 
However, if that entry is:
print _(u'Foo')
we get:
Traceback (most recent call last):
  File "./translation.py", line 12, in ?
    print _(u'Foo')
  File "/usr/lib/python2.2/gettext.py", line 195, in
ugettext
    return unicode(tmsg, self._charset)
TypeError: decoding Unicode is not supported

----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-06-04 11:54

Message:
Logged In: YES 
user_id=12800

I agree with Martin, you shouldn't be passing unicode
strings to ugettext().  I don't think it's worth doing a
type test in ugettext(); maybe we simply need to improve the
documentation?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-04 05:35

Message:
Logged In: YES 
user_id=38388

Barry will know what to do...

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-04 05:28

Message:
Logged In: YES 
user_id=21627

I'm not sure this is a bug: they keys in a message catalog
are really byte strings. So it is an error to use Unicode
strings as arguments to _.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563915&group_id=5470



From noreply@sourceforge.net  Tue Jun  4 17:20:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 04 Jun 2002 09:20:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-547211 ] Warn for __coerce__ in new-style classes
Message-ID: <E17FH2W-0002DS-00@usw-sf-web3.sourceforge.net>

Bugs item #547211, was opened at 2002-04-22 14:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547211&group_id=5470

Category: Type/class unification
Group: Python 2.3
>Status: Closed
Resolution: Later
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Warn for __coerce__ in new-style classes

Initial Comment:
New-style classes don't support __coerce__, except that
when you define it, coerce() will call it. (But it
won't be called by the binary operators.) Methinks a
warning should be issued when a new-style class defines
__coerce__.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-04 12:20

Message:
Logged In: YES 
user_id=33168

Added warning to pychecker.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-03 17:04

Message:
Logged In: YES 
user_id=6380

I think this is a PyChecker issue.

Neal, can you add this to PyChecker?

If you do, please close this bug report.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547211&group_id=5470



From noreply@sourceforge.net  Tue Jun  4 18:14:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 04 Jun 2002 10:14:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-557436 ] TclError is a str should be an Exception
Message-ID: <E17FHtN-0001FK-00@usw-sf-web4.sourceforge.net>

Bugs item #557436, was opened at 2002-05-17 16:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557436&group_id=5470

Category: Tkinter
Group: Python 2.3
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: TclError is a str should be an Exception

Initial Comment:
Since string exceptions are deprecated, it seems that
TclError (in _tkinter.c) should be changed to derive
from Exception.

It isn't apparent to me how to accomplish this.  If
someone can provide a quick high-level description, I
can make a patch.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-04 13:14

Message:
Logged In: YES 
user_id=33168

Checked in as Modules/_tkinter.c 1.125 and Misc/NEWS 1.415

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 08:49

Message:
Logged In: YES 
user_id=21627

The patch looks good; please apply it. Also add a note in
Misc/NEWS, and send a message to python-dev or amk that this
is potentially an incompatibility.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-25 09:34

Message:
Logged In: YES 
user_id=33168

The attached patch seems to work,
but I'm not sure I'm exercising it appropriately.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-22 12:56

Message:
Logged In: YES 
user_id=21627

The official API is PyErr_NewException, where NULL as the
base class indicates to inherit from Exception.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-18 04:45

Message:
Logged In: YES 
user_id=80475

Try makeclass() in Python/exceptions.c -- the file also 
shows how all the built-in exceptions get created.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557436&group_id=5470



From noreply@sourceforge.net  Tue Jun  4 18:20:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 04 Jun 2002 10:20:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-561858 ] Assertion with very long lists
Message-ID: <E17FHyl-0001o9-00@usw-sf-web2.sourceforge.net>

Bugs item #561858, was opened at 2002-05-29 06:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Jerome Alet (jalet)
>Assigned to: Tim Peters (tim_one)
Summary: Assertion with very long lists

Initial Comment:
I've tried to import a module which only define a list
of 170000 elements (a word list) which defines an
element per line, so the module also has 170000 lines
in it. Here's the error :

--- CUT ---
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import dictionnaire
python: ../Python/ceval.c:695: eval_code2: Assertion
`(stack_pointer - f->f_valuestack) <= f->f_stacksize'
failed.
Abandon
--- CUT ---

this seems to be the same problem as bug id 210647 but
there's no segfault.

the module is attached to this bug report.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-04 13:20

Message:
Logged In: YES 
user_id=33168

Tim, could you also review long-list.diff.  This is the
patch against CVS version.
It changes what is marshalled to disk.  Thanks.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-01 14:28

Message:
Logged In: YES 
user_id=33168

Thanks Tim.
Checked in for 2.1/2.2 as 2.175.2.3 and 2.192.6.2. 

Could you or someone also review the other patch for current
CVS?
That patch has a test and is different ([rw]_short ->
[rw]_long).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-01 14:14

Message:
Logged In: YES 
user_id=31435

Assuming the patch you're talking about is the one named 
long-list-2.2.diff, looks good to me, so Accepted and 
assigned back to you.  Thanks!

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-01 10:56

Message:
Logged In: YES 
user_id=33168

Added a patch for 2.2 (2.1) is basically the same.
No test for 2.2/2.1 though.
Could someone please review before checkin?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 22:04

Message:
Logged In: YES 
user_id=33168

Final patch attached.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 20:17

Message:
Logged In: YES 
user_id=33168

Got a fix.  Patch attached.  
It will probably have to be changed,
since I don't remember what else needs to be
done when the MAGIC is changed.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 20:06

Message:
Logged In: YES 
user_id=33168

I found at least part of the problem, perhaps everything.
The co_stacksize > 32767 and only a short value is marshalled
to the .pyc.

See Python/marshal.c line 246.

Not sure how to fix yet.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 18:32

Message:
Logged In: YES 
user_id=33168

I think there are several problems here.
I was able to narrow down at least one problem to a long list.
It doesn't seem to have anything to do w/backslashes.

There seems to be an interaction with importing the module.
If the long list is in __main__, the problem does not occur.
The problem only occurs when the list is in an imported module
and only after importing it the second time (after the .pyc
is created).

If a list has 32768+ items there seems to be a memory problem.
There is an exception, then a crash.  Here's the exception:

TypeError: unsupported operand type(s) for &: 'str' and 'str'

Here's a stack trace against CVS version:

#0  chunk_free (ar_ptr=0x401b1620, p=0x8156a10) at malloc.c:3180
#1  0x400fdbf4 in __libc_free (mem=0x8156a18) at malloc.c:3154
#2  0x0805c0db in list_dealloc (op=0x401c4eac) at
Objects/listobject.c:214
#3  0x080c7618 in PyDict_SetItem (op=0x401bd79c,
key=0x401c4ec0, 
    value=0x80e185c) at Objects/dictobject.c:373
#4  0x080c93f9 in PyDict_SetItemString (v=0x401bd79c,
key=0x80d9070 "path", 
    item=0x80e185c) at Objects/dictobject.c:1895
#5  0x08099ad8 in PyImport_Cleanup () at Python/import.c:286
#6  0x080a266d in Py_Finalize () at Python/pythonrun.c:228
#7  0x08053766 in Py_Main (argc=2, argv=0xbffff904) at
Modules/main.c:379


----------------------------------------------------------------------

Comment By: Jerome Alet (jalet)
Date: 2002-05-29 08:42

Message:
Logged In: YES 
user_id=97214

I've done more tests, the bug only occurs if every line has
a backslash at its end :

liste = [ \
            "item0", \
            "item1", \
            # ... many many lines
            "itemN" ]

and it works if I remove the \ from each end of line.

hth.

----------------------------------------------------------------------

Comment By: Jerome Alet (jalet)
Date: 2002-05-29 06:14

Message:
Logged In: YES 
user_id=97214

module too long to be attached. ask it by email at
alet@librelogiciel.com if needed.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470



From noreply@sourceforge.net  Tue Jun  4 18:25:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 04 Jun 2002 10:25:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-549731 ] Unicode encoders appears to leak references
Message-ID: <E17FI42-0001rj-00@usw-sf-web2.sourceforge.net>

Bugs item #549731, was opened at 2002-04-28 05:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549731&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Unicode encoders appears to leak references

Initial Comment:
Note the following Debug Python session:

>>> s=u"anything"
[8189 refs]
>>> v=s.encode("utf8")
[10967 refs]
>>> v=s.encode("utf8")
[10968 refs]
>>> v=s.encode("utf8")
[10969 refs]
>>> v=s.encode("utf8")
[10970 refs]

Each call to encode is losing a reference.  Attaching a
test program that demonstrates this in more detail. 
The output from my test program is:

After 10000 iterations, lost 12850 references
[15227 refs]

and for 100000:
After 100000 iterations, lost 102850 references
[105227 refs]

etc.

As far as I can tell, this appears in all Python 2.x
versions.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-04 13:25

Message:
Logged In: YES 
user_id=33168

Basically the code in the report would be fine.
Purify *should* catch anything which causes the leak.
So:
    s = u'anything'
    assert(s.encode('utf-8') == s.encode('utf-8'))

should work.  Perhaps, there is already a test for this?
and purify didn't report leaks.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-04 03:20

Message:
Logged In: YES 
user_id=38388

I'll have a look later today.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-06-04 00:42

Message:
Logged In: YES 
user_id=14198

damn sourceforge - it went to the trouble of asking my email
address when I submitted without being logged in, but it
doesn't seem to have done anything with it - so that was me
just incase you weren't sure :)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-04 00:39

Message:
Logged In: NO 

I'm not sure what sort of test you are suggesting I add.  I
think the patch is pretty obvious and reasonable, so MAL
should just check it in or assign it back to me <wink>. 
Earlier the better really.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-03 21:35

Message:
Logged In: YES 
user_id=33168

Patch makes sense to me.
If you add a test, I may be able to catch the problem w/purify
next time I run it (if purify works).

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-28 06:39

Message:
Logged In: YES 
user_id=14198

Oops - too quick.  All calls to _PyCodec_Lookup() leak.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-28 06:05

Message:
Logged In: YES 
user_id=14198

Found it :)  Attaching patch.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-28 05:26

Message:
Logged In: YES 
user_id=14198

s/decode/encode/ :)  Also meant to mention problem not
restricted to UTF8 - changing the encoding in the text file
to anything other than 'ascii' seems to leak in the same way.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549731&group_id=5470



From noreply@sourceforge.net  Tue Jun  4 20:53:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 04 Jun 2002 12:53:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-519621 ] __slots__ may lead to undetected cycles
Message-ID: <E17FKNK-0002Sn-00@usw-sf-web4.sourceforge.net>

Bugs item #519621, was opened at 2002-02-18 16:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=519621&group_id=5470

Category: Type/class unification
>Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Martin v. Löwis (loewis)
Assigned to: Guido van Rossum (gvanrossum)
Summary: __slots__ may lead to undetected cycles

Initial Comment:
Please see the attached script. It should print

Deleting
Deleted
done

[and actually does when you remove the cycle], but prints

Deleting
done



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-04 15:53

Message:
Logged In: YES 
user_id=6380

Fixed.  I think I'll fix this in 2.2.x too.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=519621&group_id=5470



From noreply@sourceforge.net  Tue Jun  4 22:28:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 04 Jun 2002 14:28:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-510186 ] clean doesn't
Message-ID: <E17FLrH-0003YY-00@usw-sf-web2.sourceforge.net>

Bugs item #510186, was opened at 2002-01-29 15:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510186&group_id=5470

Category: Distutils
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: clean doesn't

Initial Comment:
rRnning "python setup.py clean" says:

% python setup.py 
clean
running clean
removing 'build/temp.linux-i686-2.2' 
(and everything under it)

However, following that with an 
immediate "python
setup.py build" reports:

% python 
setup.py build
running build
running build_py
not copying 
RSWM/__init__.py (output up-to-date)
running 
build_ext
skipping 'rswm' extension (up-to-date)

Shouldn't 
the "clean" command simply delete the build
directory?


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-04 21:28

Message:
Logged In: YES 
user_id=31392

I think the reported behavior is intended, so I'm closing
the bug report.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-21 23:06

Message:
Logged In: YES 
user_id=11375

"make clean" usually deletes intermediate files such as 
.o files, leaving executables such as the 'python' 
binary 
in place.  This means you can run it to save disk space 
after building something, and the Distutils 'clean' 
command probably leaves the .so files alone to match 
this behaviour.  Also, note that Modules/Makefile only 
deletes .so files on a "make clobber" (but "make clean" 
deletes the Python executable).


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-01-29 15:31

Message:
Logged In: YES 
user_id=6656

Hmm.  Does "python setup.py clean --all" do what you
want/expect?

Agree this should possibly be the default, by analogy with
"make clean".

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510186&group_id=5470



From noreply@sourceforge.net  Tue Jun  4 22:31:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 04 Jun 2002 14:31:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-564601 ] patch 551410 broke xrange
Message-ID: <E17FLtP-00033i-00@usw-sf-web4.sourceforge.net>

Bugs item #564601, was opened at 2002-06-04 17:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564601&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Raymond Hettinger (rhettinger)
Summary: patch 551410 broke xrange

Initial Comment:
Patch 551410 is broken.

>>> a = iter(xrange(10))
>>> for i in a:
...     print i    
...     if i == 4: print '*', a.next()
... 
0
1
2
3
4
* 0
5
6
7
8
9
>>>

Compare to:

>>> a = iter(range(10))
>>> for i in a:
...     print i
...     if i == 4: print '*', a.next()
... 
0
1
2
3
4
* 5
6
7
8
9
>>> 


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564601&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 00:02:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 04 Jun 2002 16:02:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-563598 ] Core dump with newly built Python
Message-ID: <E17FNJa-0004Yn-00@usw-sf-web2.sourceforge.net>

Bugs item #563598, was opened at 2002-06-02 14:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563598&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Nobody/Anonymous (nobody)
Summary: Core dump with newly built Python

Initial Comment:
This is on what started as a Red Hat 6.0 box currently
running a 2.4.19-pre9-ac3 kernel:

# gdb ./python ./core
GNU gdb 4.17.0.11 with Linux support
...
This GDB was configured as "i386-redhat-linux"...
Core was generated by `./python -E ./setup.py build'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libpthread.so.0...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.
#0  0x8075732 in eval_frame (f=0x812504c) at
Python/ceval.c:1310
1310                            Py_DECREF(u);

(gdb) bt 
#0  0x8075732 in eval_frame (f=0x812504c) at
Python/ceval.c:1310
#1  0x8077bee in PyEval_EvalCodeEx (co=0x81245c0,
globals=0x811ec6c, locals=0x811ec6c, args=0x0,
argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at
Python/ceval.c:2585
#2  0x8079c60 in PyEval_EvalCode (co=0x81245c0,
globals=0x811ec6c, locals=0x811ec6c) at Python/ceval.c:483
#3  0x808b53d in PyImport_ExecCodeModuleEx
(name=0xbfffe4f4 "os", co=0x81245c0, 
    pathname=0xbfffdbf4
"/usr/src/Python-2.2.1/Lib/os.pyc") at Python/import.c:502
#4  0x808ba59 in load_source_module (name=0xbfffe4f4
"os", pathname=0xbfffe064
"/usr/src/Python-2.2.1/Lib/os.py", 
    fp=0x810f710) at Python/import.c:772
#5  0x808c380 in load_module (name=0xbfffe4f4 "os",
fp=0x810f710, buf=0xbfffe064
"/usr/src/Python-2.2.1/Lib/os.py", 
    type=1) at Python/import.c:1356
#6  0x808d015 in import_submodule (mod=0x80e105c,
subname=0xbfffe4f4 "os", fullname=0xbfffe4f4 "os")
    at Python/import.c:1895
#7  0x808cbbd in load_next (mod=0x80e105c,
altmod=0x80e105c, p_name=0xbfffe900, buf=0xbfffe4f4 "os", 
    p_buflen=0xbfffe4f0) at Python/import.c:1751
#8  0x808c7eb in import_module_ex (name=0x0,
globals=0x81151cc, locals=0x81151cc, fromlist=0x80e105c)
    at Python/import.c:1602
#9  0x808dd14 in PyImport_ImportModuleEx
(name=0x8110854 "os", globals=0x81151cc,
locals=0x81151cc, fromlist=0x80e105c)
    at Python/import.c:1643
#10 0x80ca8ac in builtin___import__ (self=0x0,
args=0x81153fc) at Python/bltinmodule.c:40
#11 0x80c6e7d in PyCFunction_Call (func=0x8102998,
arg=0x81153fc, kw=0x0) at Objects/methodobject.c:80
#12 0x80a956e in PyObject_Call (func=0x8102998,
arg=0x81153fc, kw=0x0) at Objects/abstract.c:1684
#13 0x80783e0 in PyEval_CallObjectWithKeywords
(func=0x8102998, arg=0x81153fc, kw=0x0) at
Python/ceval.c:3049
#14 0x8076793 in eval_frame (f=0x8115554) at
Python/ceval.c:1839
#15 0x8077bee in PyEval_EvalCodeEx (co=0x81051d0,
globals=0x81151cc, locals=0x81151cc, args=0x0,
argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at
Python/ceval.c:2585
#16 0x8079c60 in PyEval_EvalCode (co=0x81051d0,
globals=0x81151cc, locals=0x81151cc) at Python/ceval.c:483
#17 0x808b53d in PyImport_ExecCodeModuleEx
(name=0xbffff494 "site", co=0x81051d0, 
    pathname=0xbfffeb94
"/usr/src/Python-2.2.1/Lib/site.pyc") at
Python/import.c:502
#18 0x808ba59 in load_source_module (name=0xbffff494
"site", pathname=0xbffff004
"/usr/src/Python-2.2.1/Lib/site.py", 
    fp=0x810f658) at Python/import.c:772
#19 0x808c380 in load_module (name=0xbffff494 "site",
fp=0x810f658, 
    buf=0xbffff004 "/usr/src/Python-2.2.1/Lib/site.py",
type=1) at Python/import.c:1356
#20 0x808d015 in import_submodule (mod=0x80e105c,
subname=0xbffff494 "site", fullname=0xbffff494 "site")
    at Python/import.c:1895
#21 0x808cbbd in load_next (mod=0x80e105c,
altmod=0x80e105c, p_name=0xbffff8a0, buf=0xbffff494
"site", 
    p_buflen=0xbffff490) at Python/import.c:1751
#22 0x808c7eb in import_module_ex (name=0x0,
globals=0x810f5d4, locals=0x810f5d4, fromlist=0x8107adc)
    at Python/import.c:1602
#23 0x808dd14 in PyImport_ImportModuleEx
(name=0x810f5bc "site", globals=0x810f5d4,
locals=0x810f5d4, 
    fromlist=0x8107adc) at Python/import.c:1643
#24 0x80ca8ac in builtin___import__ (self=0x0,
args=0x8107edc) at Python/bltinmodule.c:40
#25 0x80c6e7d in PyCFunction_Call (func=0x8102998,
arg=0x8107edc, kw=0x0) at Objects/methodobject.c:80
#26 0x80a956e in PyObject_Call (func=0x8102998,
arg=0x8107edc, kw=0x0) at Objects/abstract.c:1684
#27 0x80783e0 in PyEval_CallObjectWithKeywords
(func=0x8102998, arg=0x8107edc, kw=0x0) at
Python/ceval.c:3049
#28 0x80a8bee in PyObject_CallFunction
(callable=0x8102998, format=0x80d5707 "OOOO") at
Objects/abstract.c:1725
#29 0x808d4e6 in PyImport_Import
(module_name=0x810f5a8) at Python/import.c:2048
#30 0x808dc53 in PyImport_ImportModule (name=0x80d6ea3
"site") at Python/import.c:1574
#31 0x809448b in initsite () at Python/pythonrun.c:443
#32 0x8092812 in Py_Initialize () at Python/pythonrun.c:173
#33 0x8053387 in Py_Main (argc=4, argv=0xbffffb54) at
Modules/main.c:322
#34 0x8052dca in main (argc=4, argv=0xbffffb54) at
Modules/python.c:10
#35 0x400699cb in __libc_start_main (main=0x8052db4
<main>, argc=4, argv=0xbffffb54, init=0x80521e4 <_init>, 
    fini=0x80cbed4 <_fini>, rtld_fini=0x4000aea0
<_dl_fini>, stack_end=0xbffffb4c)
    at ../sysdeps/generic/libc-start.c:92
y_Initialize () at Python/pythonrun.c:173

(gdb) print u
$1 = (PyObject *) 0x0


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-04 19:02

Message:
Logged In: YES 
user_id=33168

I'm really grasping here, but here are some more things to try:

Use python -S to start (since that's all that works):

Try each of these lines (if one crashes, restart and try a
different one):
    import os
    import site
    # the following 3 lines need to be done in order
    x = [1, 2, 3]
    x[1] = 5
    del x[1]

If you paste these lines into a .gdbinit file (or into gdb),
you can find out where in the python source the program
crashes:

    define ppystack
        while $pc < Py_Main || $pc > Py_GetArgcArgv
            if $pc > eval_frame && $pc < PyEval_EvalCodeEx
                set $__fn = PyString_AsString(co->co_filename)
                set $__n = PyString_AsString(co->co_name)
                printf "%s (%d): %s\n",  $__fn, f->f_lineno,
$__n
            end
            up-silently 1
        end
        select-frame 0
    end

then in gdb, type ppystack.  That may provide more info.
Good luck.


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-06-04 11:35

Message:
Logged In: YES 
user_id=133413

Deleting .pyc files does not help.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-06-04 06:30

Message:
Logged In: YES 
user_id=6656

One thing to try is deleting .pyc files.  I don't think that'll help, 
but it might...


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-06-03 22:39

Message:
Logged In: YES 
user_id=133413

Compiler: gcc version 2.95.3 20010315 (release) (built from tar)
Clean build: pretty much, but see closed bug 535545 (using a
slightly modified       configure file courtesy of Martin v.
Loewis)
Other packages: yes many, no problems
"python -S": yes, a prompt!
Do anything?: I don't really speak Python - something you
can suggest?
Other versions: Yes, 1.5.2 (same compiler); also 2.2.1rc
(forget which), which built fine after correcting
configure's error noted in bug 535545 - whereas this version
dumped core at the step of the make process quoted above
(/python -E ./setup.py build)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-03 21:20

Message:
Logged In: YES 
user_id=33168

What compiler & version are you using?
Did you start from a clean build?
Have you used the compiler for other packages?
If you start python -S, does that get a prompt?
If so, can you do anything?
Have you successfully built any other versions of Python on
this machine?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563598&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 05:48:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 04 Jun 2002 21:48:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-564601 ] patch 551410 broke xrange
Message-ID: <E17FSiy-0007i3-00@usw-sf-web4.sourceforge.net>

Bugs item #564601, was opened at 2002-06-04 16:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564601&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Raymond Hettinger (rhettinger)
Summary: patch 551410 broke xrange

Initial Comment:
Patch 551410 is broken.

>>> a = iter(xrange(10))
>>> for i in a:
...     print i    
...     if i == 4: print '*', a.next()
... 
0
1
2
3
4
* 0
5
6
7
8
9
>>>

Compare to:

>>> a = iter(range(10))
>>> for i in a:
...     print i
...     if i == 4: print '*', a.next()
... 
0
1
2
3
4
* 5
6
7
8
9
>>> 


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-04 23:48

Message:
Logged In: YES 
user_id=80475

See attached patch.
Given x=xrange(n), the patch assures that id(iter(iter(x))) 
== id(iter(x)).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564601&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 06:54:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 04 Jun 2002 22:54:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-564601 ] patch 551410 broke xrange
Message-ID: <E17FTkM-0000Oa-00@usw-sf-web2.sourceforge.net>

Bugs item #564601, was opened at 2002-06-04 16:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564601&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Raymond Hettinger (rhettinger)
Summary: patch 551410 broke xrange

Initial Comment:
Patch 551410 is broken.

>>> a = iter(xrange(10))
>>> for i in a:
...     print i    
...     if i == 4: print '*', a.next()
... 
0
1
2
3
4
* 0
5
6
7
8
9
>>>

Compare to:

>>> a = iter(range(10))
>>> for i in a:
...     print i
...     if i == 4: print '*', a.next()
... 
0
1
2
3
4
* 5
6
7
8
9
>>> 


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-05 00:54

Message:
Logged In: YES 
user_id=80475

Added alternative patch with full-blown rangeiterobject just 
like listobject.c.  Given x=xrange(n), the patch assures that 
id(iter(iter(x))) == id(iter(x)) and assures that id(iter(x))!=id
(x) so that xrange() is identical in behavior to range() in all 
iteration aspects.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-04 23:48

Message:
Logged In: YES 
user_id=80475

See attached patch.
Given x=xrange(n), the patch assures that id(iter(iter(x))) 
== id(iter(x)).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564601&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 07:09:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 04 Jun 2002 23:09:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-564729 ] FixTk.py logic wrong
Message-ID: <E17FTzU-00006k-00@usw-sf-web4.sourceforge.net>

Bugs item #564729, was opened at 2002-06-05 06:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564729&group_id=5470

Category: Tkinter
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Internet Discovery (idiscovery)
Assigned to: Nobody/Anonymous (nobody)
Summary: FixTk.py logic wrong

Initial Comment:
The logic in FixTk.py is wrong for Tix: the Tix version number
is independent of the Tk/Tcl version number.

Just duplicate the Tcl code logic for Tix, and don't reuse the 
Tcl version number.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564729&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 08:24:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 00:24:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-564601 ] patch 551410 broke xrange
Message-ID: <E17FV9v-0000uy-00@usw-sf-web4.sourceforge.net>

Bugs item #564601, was opened at 2002-06-04 23:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564601&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Raymond Hettinger (rhettinger)
Summary: patch 551410 broke xrange

Initial Comment:
Patch 551410 is broken.

>>> a = iter(xrange(10))
>>> for i in a:
...     print i    
...     if i == 4: print '*', a.next()
... 
0
1
2
3
4
* 0
5
6
7
8
9
>>>

Compare to:

>>> a = iter(range(10))
>>> for i in a:
...     print i
...     if i == 4: print '*', a.next()
... 
0
1
2
3
4
* 5
6
7
8
9
>>> 


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-05 09:24

Message:
Logged In: YES 
user_id=21627

Your patch 1 does not work:

r = xrange(3)
for i in r: print i,
for i in r: print i,

ought to print
0 1 2 0 1 2
but with your patch, it prints
0 1 2
Notice that the used flag was introduced precisely to allow
reuse of the range object in multiple loops.

So I guess the rangeiterobject is the way to go, but I
haven't reviewed the patch, yet.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-05 07:54

Message:
Logged In: YES 
user_id=80475

Added alternative patch with full-blown rangeiterobject just 
like listobject.c.  Given x=xrange(n), the patch assures that 
id(iter(iter(x))) == id(iter(x)) and assures that id(iter(x))!=id
(x) so that xrange() is identical in behavior to range() in all 
iteration aspects.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-05 06:48

Message:
Logged In: YES 
user_id=80475

See attached patch.
Given x=xrange(n), the patch assures that id(iter(iter(x))) 
== id(iter(x)).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564601&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 17:25:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 09:25:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-564601 ] patch 551410 broke xrange
Message-ID: <E17FdbS-0006gM-00@usw-sf-web2.sourceforge.net>

Bugs item #564601, was opened at 2002-06-04 16:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564601&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Raymond Hettinger (rhettinger)
Summary: patch 551410 broke xrange

Initial Comment:
Patch 551410 is broken.

>>> a = iter(xrange(10))
>>> for i in a:
...     print i    
...     if i == 4: print '*', a.next()
... 
0
1
2
3
4
* 0
5
6
7
8
9
>>>

Compare to:

>>> a = iter(range(10))
>>> for i in a:
...     print i
...     if i == 4: print '*', a.next()
... 
0
1
2
3
4
* 5
6
7
8
9
>>> 


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-05 11:25

Message:
Logged In: YES 
user_id=80475

Deleting patch 1.

Patch 2 matchs Py2.2 behavior for all the tests we've 
discussed and matches the object creation behavior of 
range().

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-05 02:24

Message:
Logged In: YES 
user_id=21627

Your patch 1 does not work:

r = xrange(3)
for i in r: print i,
for i in r: print i,

ought to print
0 1 2 0 1 2
but with your patch, it prints
0 1 2
Notice that the used flag was introduced precisely to allow
reuse of the range object in multiple loops.

So I guess the rangeiterobject is the way to go, but I
haven't reviewed the patch, yet.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-05 00:54

Message:
Logged In: YES 
user_id=80475

Added alternative patch with full-blown rangeiterobject just 
like listobject.c.  Given x=xrange(n), the patch assures that 
id(iter(iter(x))) == id(iter(x)) and assures that id(iter(x))!=id
(x) so that xrange() is identical in behavior to range() in all 
iteration aspects.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-04 23:48

Message:
Logged In: YES 
user_id=80475

See attached patch.
Given x=xrange(n), the patch assures that id(iter(iter(x))) 
== id(iter(x)).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564601&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 17:30:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 09:30:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-563598 ] Core dump with newly built Python
Message-ID: <E17FdgK-0002uO-00@usw-sf-web1.sourceforge.net>

Bugs item #563598, was opened at 2002-06-02 14:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563598&group_id=5470

Category: Build
Group: Python 2.2.1
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Nobody/Anonymous (nobody)
Summary: Core dump with newly built Python

Initial Comment:
This is on what started as a Red Hat 6.0 box currently
running a 2.4.19-pre9-ac3 kernel:

# gdb ./python ./core
GNU gdb 4.17.0.11 with Linux support
...
This GDB was configured as "i386-redhat-linux"...
Core was generated by `./python -E ./setup.py build'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libpthread.so.0...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.
#0  0x8075732 in eval_frame (f=0x812504c) at
Python/ceval.c:1310
1310                            Py_DECREF(u);

(gdb) bt 
#0  0x8075732 in eval_frame (f=0x812504c) at
Python/ceval.c:1310
#1  0x8077bee in PyEval_EvalCodeEx (co=0x81245c0,
globals=0x811ec6c, locals=0x811ec6c, args=0x0,
argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at
Python/ceval.c:2585
#2  0x8079c60 in PyEval_EvalCode (co=0x81245c0,
globals=0x811ec6c, locals=0x811ec6c) at Python/ceval.c:483
#3  0x808b53d in PyImport_ExecCodeModuleEx
(name=0xbfffe4f4 "os", co=0x81245c0, 
    pathname=0xbfffdbf4
"/usr/src/Python-2.2.1/Lib/os.pyc") at Python/import.c:502
#4  0x808ba59 in load_source_module (name=0xbfffe4f4
"os", pathname=0xbfffe064
"/usr/src/Python-2.2.1/Lib/os.py", 
    fp=0x810f710) at Python/import.c:772
#5  0x808c380 in load_module (name=0xbfffe4f4 "os",
fp=0x810f710, buf=0xbfffe064
"/usr/src/Python-2.2.1/Lib/os.py", 
    type=1) at Python/import.c:1356
#6  0x808d015 in import_submodule (mod=0x80e105c,
subname=0xbfffe4f4 "os", fullname=0xbfffe4f4 "os")
    at Python/import.c:1895
#7  0x808cbbd in load_next (mod=0x80e105c,
altmod=0x80e105c, p_name=0xbfffe900, buf=0xbfffe4f4 "os", 
    p_buflen=0xbfffe4f0) at Python/import.c:1751
#8  0x808c7eb in import_module_ex (name=0x0,
globals=0x81151cc, locals=0x81151cc, fromlist=0x80e105c)
    at Python/import.c:1602
#9  0x808dd14 in PyImport_ImportModuleEx
(name=0x8110854 "os", globals=0x81151cc,
locals=0x81151cc, fromlist=0x80e105c)
    at Python/import.c:1643
#10 0x80ca8ac in builtin___import__ (self=0x0,
args=0x81153fc) at Python/bltinmodule.c:40
#11 0x80c6e7d in PyCFunction_Call (func=0x8102998,
arg=0x81153fc, kw=0x0) at Objects/methodobject.c:80
#12 0x80a956e in PyObject_Call (func=0x8102998,
arg=0x81153fc, kw=0x0) at Objects/abstract.c:1684
#13 0x80783e0 in PyEval_CallObjectWithKeywords
(func=0x8102998, arg=0x81153fc, kw=0x0) at
Python/ceval.c:3049
#14 0x8076793 in eval_frame (f=0x8115554) at
Python/ceval.c:1839
#15 0x8077bee in PyEval_EvalCodeEx (co=0x81051d0,
globals=0x81151cc, locals=0x81151cc, args=0x0,
argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at
Python/ceval.c:2585
#16 0x8079c60 in PyEval_EvalCode (co=0x81051d0,
globals=0x81151cc, locals=0x81151cc) at Python/ceval.c:483
#17 0x808b53d in PyImport_ExecCodeModuleEx
(name=0xbffff494 "site", co=0x81051d0, 
    pathname=0xbfffeb94
"/usr/src/Python-2.2.1/Lib/site.pyc") at
Python/import.c:502
#18 0x808ba59 in load_source_module (name=0xbffff494
"site", pathname=0xbffff004
"/usr/src/Python-2.2.1/Lib/site.py", 
    fp=0x810f658) at Python/import.c:772
#19 0x808c380 in load_module (name=0xbffff494 "site",
fp=0x810f658, 
    buf=0xbffff004 "/usr/src/Python-2.2.1/Lib/site.py",
type=1) at Python/import.c:1356
#20 0x808d015 in import_submodule (mod=0x80e105c,
subname=0xbffff494 "site", fullname=0xbffff494 "site")
    at Python/import.c:1895
#21 0x808cbbd in load_next (mod=0x80e105c,
altmod=0x80e105c, p_name=0xbffff8a0, buf=0xbffff494
"site", 
    p_buflen=0xbffff490) at Python/import.c:1751
#22 0x808c7eb in import_module_ex (name=0x0,
globals=0x810f5d4, locals=0x810f5d4, fromlist=0x8107adc)
    at Python/import.c:1602
#23 0x808dd14 in PyImport_ImportModuleEx
(name=0x810f5bc "site", globals=0x810f5d4,
locals=0x810f5d4, 
    fromlist=0x8107adc) at Python/import.c:1643
#24 0x80ca8ac in builtin___import__ (self=0x0,
args=0x8107edc) at Python/bltinmodule.c:40
#25 0x80c6e7d in PyCFunction_Call (func=0x8102998,
arg=0x8107edc, kw=0x0) at Objects/methodobject.c:80
#26 0x80a956e in PyObject_Call (func=0x8102998,
arg=0x8107edc, kw=0x0) at Objects/abstract.c:1684
#27 0x80783e0 in PyEval_CallObjectWithKeywords
(func=0x8102998, arg=0x8107edc, kw=0x0) at
Python/ceval.c:3049
#28 0x80a8bee in PyObject_CallFunction
(callable=0x8102998, format=0x80d5707 "OOOO") at
Objects/abstract.c:1725
#29 0x808d4e6 in PyImport_Import
(module_name=0x810f5a8) at Python/import.c:2048
#30 0x808dc53 in PyImport_ImportModule (name=0x80d6ea3
"site") at Python/import.c:1574
#31 0x809448b in initsite () at Python/pythonrun.c:443
#32 0x8092812 in Py_Initialize () at Python/pythonrun.c:173
#33 0x8053387 in Py_Main (argc=4, argv=0xbffffb54) at
Modules/main.c:322
#34 0x8052dca in main (argc=4, argv=0xbffffb54) at
Modules/python.c:10
#35 0x400699cb in __libc_start_main (main=0x8052db4
<main>, argc=4, argv=0xbffffb54, init=0x80521e4 <_init>, 
    fini=0x80cbed4 <_fini>, rtld_fini=0x4000aea0
<_dl_fini>, stack_end=0xbffffb4c)
    at ../sysdeps/generic/libc-start.c:92
y_Initialize () at Python/pythonrun.c:173

(gdb) print u
$1 = (PyObject *) 0x0


----------------------------------------------------------------------

>Comment By: Whit Blauvelt (whit)
Date: 2002-06-05 12:30

Message:
Logged In: YES 
user_id=133413

Turns out that the bad compile was the first sign of memory
starting to fail. Swapped in other memory and Python built
well. Sorry to trouble you all on this.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-04 19:02

Message:
Logged In: YES 
user_id=33168

I'm really grasping here, but here are some more things to try:

Use python -S to start (since that's all that works):

Try each of these lines (if one crashes, restart and try a
different one):
    import os
    import site
    # the following 3 lines need to be done in order
    x = [1, 2, 3]
    x[1] = 5
    del x[1]

If you paste these lines into a .gdbinit file (or into gdb),
you can find out where in the python source the program
crashes:

    define ppystack
        while $pc < Py_Main || $pc > Py_GetArgcArgv
            if $pc > eval_frame && $pc < PyEval_EvalCodeEx
                set $__fn = PyString_AsString(co->co_filename)
                set $__n = PyString_AsString(co->co_name)
                printf "%s (%d): %s\n",  $__fn, f->f_lineno,
$__n
            end
            up-silently 1
        end
        select-frame 0
    end

then in gdb, type ppystack.  That may provide more info.
Good luck.


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-06-04 11:35

Message:
Logged In: YES 
user_id=133413

Deleting .pyc files does not help.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-06-04 06:30

Message:
Logged In: YES 
user_id=6656

One thing to try is deleting .pyc files.  I don't think that'll help, 
but it might...


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-06-03 22:39

Message:
Logged In: YES 
user_id=133413

Compiler: gcc version 2.95.3 20010315 (release) (built from tar)
Clean build: pretty much, but see closed bug 535545 (using a
slightly modified       configure file courtesy of Martin v.
Loewis)
Other packages: yes many, no problems
"python -S": yes, a prompt!
Do anything?: I don't really speak Python - something you
can suggest?
Other versions: Yes, 1.5.2 (same compiler); also 2.2.1rc
(forget which), which built fine after correcting
configure's error noted in bug 535545 - whereas this version
dumped core at the step of the make process quoted above
(/python -E ./setup.py build)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-03 21:20

Message:
Logged In: YES 
user_id=33168

What compiler & version are you using?
Did you start from a clean build?
Have you used the compiler for other packages?
If you start python -S, does that get a prompt?
If so, can you do anything?
Have you successfully built any other versions of Python on
this machine?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563598&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 17:36:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 09:36:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-564913 ] Partial Function redeffinition...
Message-ID: <E17Fdld-0006lG-00@usw-sf-web2.sourceforge.net>

Bugs item #564913, was opened at 2002-06-05 20:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564913&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex A. Naanou (alex_nanou)
Assigned to: Nobody/Anonymous (nobody)
Summary: Partial Function redeffinition...

Initial Comment:
description: 
part of the functions definition is changed in runtime (the 
value of the default parameter to exact).
 (expected to possible only by function redefinition)

expected behaver:
the default value of 'x' would stay constant, thus 
rendering the output of all cases to be the same (and 
equal to '[0]').

code: 
//see the attached file. 

test systems: 
WIN2K v.5.00.2195 SP2 
- ActivePython 2.2 //I do not remember the details
- Python 2.2 (#1, Dec 31 2001, 15:21:18) [GCC 2.95.3-5 
(cygwin special)] on cygwin 

With Respect.. 
Alex. 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564913&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 18:09:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 10:09:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-564931 ] compile traceback must include filename
Message-ID: <E17FeI7-000719-00@usw-sf-web2.sourceforge.net>

Bugs item #564931, was opened at 2002-06-05 19:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564931&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: compile traceback must include filename

Initial Comment:
> >>> compile("1+*3", "myfile.py", "exec")
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "<string>", line 1
>     1+*3
>       ^
> SyntaxError: invalid syntax
> >>>
> 
> Shouldn't it print "myfile.py" instead of "<string>"?

Yes.

--Guido van Rossum 


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564931&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 19:22:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 11:22:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-564601 ] patch 551410 broke xrange
Message-ID: <E17FfQQ-0007w9-00@usw-sf-web2.sourceforge.net>

Bugs item #564601, was opened at 2002-06-04 17:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564601&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Raymond Hettinger (rhettinger)
Summary: patch 551410 broke xrange

Initial Comment:
Patch 551410 is broken.

>>> a = iter(xrange(10))
>>> for i in a:
...     print i    
...     if i == 4: print '*', a.next()
... 
0
1
2
3
4
* 0
5
6
7
8
9
>>>

Compare to:

>>> a = iter(range(10))
>>> for i in a:
...     print i
...     if i == 4: print '*', a.next()
... 
0
1
2
3
4
* 5
6
7
8
9
>>> 


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 14:22

Message:
Logged In: YES 
user_id=6380

I have no way to test this right now, but it looks like the right 
approach. So if it passes the tests, please check it in!

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-05 12:25

Message:
Logged In: YES 
user_id=80475

Deleting patch 1.

Patch 2 matchs Py2.2 behavior for all the tests we've 
discussed and matches the object creation behavior of 
range().

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-05 03:24

Message:
Logged In: YES 
user_id=21627

Your patch 1 does not work:

r = xrange(3)
for i in r: print i,
for i in r: print i,

ought to print
0 1 2 0 1 2
but with your patch, it prints
0 1 2
Notice that the used flag was introduced precisely to allow
reuse of the range object in multiple loops.

So I guess the rangeiterobject is the way to go, but I
haven't reviewed the patch, yet.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-05 01:54

Message:
Logged In: YES 
user_id=80475

Added alternative patch with full-blown rangeiterobject just 
like listobject.c.  Given x=xrange(n), the patch assures that 
id(iter(iter(x))) == id(iter(x)) and assures that id(iter(x))!=id
(x) so that xrange() is identical in behavior to range() in all 
iteration aspects.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-05 00:48

Message:
Logged In: YES 
user_id=80475

See attached patch.
Given x=xrange(n), the patch assures that id(iter(iter(x))) 
== id(iter(x)).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564601&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 19:36:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 11:36:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-555779 ] import user doesn't work with CGIs
Message-ID: <E17Ffdw-00084F-00@usw-sf-web2.sourceforge.net>

Bugs item #555779, was opened at 2002-05-14 03:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555779&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Stephen Hansen (ixokai_)
Assigned to: Nobody/Anonymous (nobody)
Summary: import user doesn't work with CGIs

Initial Comment:
 I'm doing some CGI scripts for a job, and I've made   
some a series of libraries i'd like them to share--   
but I don't wish them to be publically installed into   
site-packages. The user mechanism seems quite suited   
to the task of easily modifying sys.path to include a   
more "private" library directory.   
  
Unfortunately, it won't work in this secnario,  
because there is no $HOME environment variable set  
when Apache calls the script.  
  
Here are a couple small patches to make it work if  
the scripts are running SUID or with Apache's suEXEC  
feature.  

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 14:36

Message:
Logged In: YES 
user_id=6380

Looks good to me. Anybody can check this in.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555779&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 19:40:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 11:40:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-557028 ] illegal use of malloc/free
Message-ID: <E17Ffhz-00086E-00@usw-sf-web2.sourceforge.net>

Bugs item #557028, was opened at 2002-05-16 20:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557028&group_id=5470

Category: Parser/Compiler
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Gustav Hållberg (gurra-g)
Assigned to: Nobody/Anonymous (nobody)
Summary: illegal use of malloc/free

Initial Comment:
com_factor() in compiler.c uses malloc/free, but should
use PyMem_Malloc/_Free.

The use of malloc/free is fatal when one has changed
Python's allocators to use something else than
malloc/free since the stuff malloc:ed there can later
on be (attempted to be) freed through a call to PyMem_Free.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 14:40

Message:
Logged In: YES 
user_id=6380

Yup, should be backported.

But note that pymalloc is known to be buggy in 2.2.x, and 
we're not going to fix that.

----------------------------------------------------------------------

Comment By: Gustav Hållberg (gurra-g)
Date: 2002-05-17 06:46

Message:
Logged In: YES 
user_id=546849

Ah, that should definitely be backported to releasebranches.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-16 21:19

Message:
Logged In: YES 
user_id=31435

Just noting that current CVS already uses PyMem_ in 
com_factor.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557028&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 19:43:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 11:43:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-557704 ] netrc module can't handle all passwords
Message-ID: <E17Ffl5-0000oo-00@usw-sf-web3.sourceforge.net>

Bugs item #557704, was opened at 2002-05-18 13:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Bram Moolenaar (vimboss)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: netrc module can't handle all passwords

Initial Comment:
When a ~/.netrc file has a password with non-word
characters parsing fails.  Since it is recommended to
use punctuation characters in passwords, this means
most netrc files can't be parsed. An example of a line
in ~/.netrc that fails:

machine piet.puk.com  	login foo 	password bar!

Additionally, entries in netrc may not have a login
name (e.g., for mail servers).  These entries should be
silently skipped. An example of a line that fails:

machine mail          password fruit

The included diff is a partial solution.  It allows all
ASCII punctuation characters to be used in passwords. 
Non-ASCII characters should probably also be allowed.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 14:43

Message:
Logged In: YES 
user_id=6380

I think Fred knows this code.

I think Eric Raymond (the original author) wrote this as an 
example of his shlex. :-)

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-06-02 08:48

Message:
Logged In: YES 
user_id=44345

I think a better solution would be to not use shlex to parse netrc files.  
Netrc files aren't shells.  The whitespace is significant if it occurs inside a 
password.  I'd just use re.split(r'(\s+)') and restore the password when I 
encounterd the "password" keyword.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-18 21:56

Message:
Logged In: YES 
user_id=80475

Expanding keyspace is generally a good idea; however, the 
significance of meta-characters is bound to bite someone in 
the behind with a hard to find error.  So, please 
reconsider single-quote, double-quote, backslash, 
greaterthan, lessthan, and pipe.

Looking at first part of the patch, consider:
- removing the TODO on line 31
- wrapping the character list in triple-quotes on line 32
- using the r'' form on line 32 to eliminate backslashes in 
the character list

Looking at the second part of the patch, I don't follow (am 
perhaps being daft) why expanding the keyspace necessitates 
changing the login logic.

The idea of allowing non-ASCII characters would be cool if 
the world had already universally accepted Latin-1 coding.  
That conflict is the reason that site.py defaults to ASCII 
encoding instead of handling non-US codings out of the box.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 19:46:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 11:46:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-558072 ]
Message-ID: <E17FfnT-0001RE-00@usw-sf-web3.sourceforge.net>

Bugs item #558072, was opened at 2002-05-19 16:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558072&group_id=5470

Category: Demos and Tools
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Reis (kiko_async)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: 

Initial Comment:


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 14:46

Message:


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558072&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 19:48:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 11:48:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-558166 ]
Message-ID: <E17Ffpo-0001So-00@usw-sf-web3.sourceforge.net>

Bugs item #558166, was opened at 2002-05-20 01:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558166&group_id=5470

Category: IDLE
Group: Python 2.2.1
Status: Open
Resolution: None
>Priority: 1
Submitted By: Phillip Ruggera (pruggera)
Assigned to: Nobody/Anonymous (nobody)
Summary: 

Initial Comment:


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 14:48

Message:


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558166&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 19:57:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 11:57:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-564931 ]
Message-ID: <E17Ffy2-00008L-00@usw-sf-web4.sourceforge.net>

Bugs item #564931, was opened at 2002-06-05 19:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564931&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: 

Initial Comment:


----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2002-06-05 20:57

Message:


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564931&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 19:58:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 11:58:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-558179 ]
Message-ID: <E17FfzU-0004TC-00@usw-sf-web1.sourceforge.net>

Bugs item #558179, was opened at 2002-05-20 03:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558179&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: KAJIYAMA, Tamito (kajiyama)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: 

Initial Comment:


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 14:58

Message:


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558179&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 20:12:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 12:12:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-558153 ]
Message-ID: <E17FgDJ-0000L4-00@usw-sf-web4.sourceforge.net>

Bugs item #558153, was opened at 2002-05-19 23:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558153&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hadfield (hadfield)
Assigned to: Fredrik Lundh (effbot)
Summary: 

Initial Comment:


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 15:12

Message:


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-29 06:27

Message:


----------------------------------------------------------------------

Comment By: Mark Hadfield (hadfield)
Date: 2002-05-19 23:17

Message:


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558153&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 20:16:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 12:16:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-558488 ]
Message-ID: <E17FgGo-0000VU-00@usw-sf-web2.sourceforge.net>

Bugs item #558488, was opened at 2002-05-20 20:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: David Aldridge (daldridge)
>Assigned to: Tim Peters (tim_one)
Summary: 

Initial Comment:


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 15:16

Message:


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 20:18:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 12:18:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-559884 ]
Message-ID: <E17FgIe-0004i3-00@usw-sf-web1.sourceforge.net>

Bugs item #559884, was opened at 2002-05-23 18:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559884&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Demaine (edemaine)
>Assigned to: Piers Lauder (pierslauder)
Summary: 

Initial Comment:


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 15:18

Message:


----------------------------------------------------------------------

Comment By: Erik Demaine (edemaine)
Date: 2002-05-30 10:06

Message:


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-24 10:36

Message:


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559884&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 20:23:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 12:23:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-560064 ]
Message-ID: <E17FgNZ-0000So-00@usw-sf-web4.sourceforge.net>

Bugs item #560064, was opened at 2002-05-24 07:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560064&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Cesar Douady (douady)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: 

Initial Comment:


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 15:23

Message:


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-24 08:58

Message:


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560064&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 20:25:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 12:25:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-560215 ]
Message-ID: <E17FgPq-0000Uf-00@usw-sf-web4.sourceforge.net>

Bugs item #560215, was opened at 2002-05-24 12:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560215&group_id=5470

Category: Type/class unification
Group: Python 2.2
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Paul Barrett (barrett)
Assigned to: Nobody/Anonymous (nobody)
Summary: 

Initial Comment:


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 15:25

Message:


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-24 12:33

Message:


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560215&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 20:33:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 12:33:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-560438 ]
Message-ID: <E17FgWo-0001zg-00@usw-sf-web3.sourceforge.net>

Bugs item #560438, was opened at 2002-05-25 04:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560438&group_id=5470

Category: Type/class unification
Group: Python 2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Steve Alexander (stevea_zope)
Assigned to: Nobody/Anonymous (nobody)
Summary: 

Initial Comment:


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 15:33

Message:


----------------------------------------------------------------------

Comment By: Steve Alexander (stevea_zope)
Date: 2002-05-31 17:16

Message:


----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2002-05-31 17:02

Message:


----------------------------------------------------------------------

Comment By: Steve Alexander (stevea_zope)
Date: 2002-05-25 05:05

Message:


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560438&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 20:36:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 12:36:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-560794 ]
Message-ID: <E17FgaG-00022C-00@usw-sf-web3.sourceforge.net>

Bugs item #560794, was opened at 2002-05-26 15:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560794&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: 

Initial Comment:


----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2002-05-26 15:35

Message:


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560794&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 20:40:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 12:40:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-563338 ]
Message-ID: <E17Fgdc-0004y3-00@usw-sf-web1.sourceforge.net>

Bugs item #563338, was opened at 2002-06-01 12:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563338&group_id=5470

Category: Documentation
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Bjorn Pettersen (bpettersen)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: 

Initial Comment:


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 15:40

Message:


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 09:09

Message:


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 09:09

Message:


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563338&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 20:40:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 12:40:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-558488 ]
Message-ID: <E17Fgds-0000nF-00@usw-sf-web2.sourceforge.net>

Bugs item #558488, was opened at 2002-05-20 20:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: David Aldridge (daldridge)
>Assigned to: Mark Hammond (mhammond)
Summary: 

Initial Comment:


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-06-05 15:40

Message:


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 15:16

Message:


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 21:09:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 13:09:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-564601 ]
Message-ID: <E17Fh6J-00017n-00@usw-sf-web2.sourceforge.net>

Bugs item #564601, was opened at 2002-06-04 16:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564601&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Raymond Hettinger (rhettinger)
Summary: 

Initial Comment:


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-05 15:09

Message:


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 13:22

Message:


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-05 11:25

Message:


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-05 02:24

Message:


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-05 00:54

Message:


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-04 23:48

Message:


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564601&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 21:36:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 13:36:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-559884 ] imaplib.IMAP4.open() typo
Message-ID: <E17FhWJ-0001Wn-00@usw-sf-web4.sourceforge.net>

Bugs item #559884, was opened at 2002-05-24 08:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559884&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Demaine (edemaine)
Assigned to: Piers Lauder (pierslauder)
Summary: imaplib.IMAP4.open() typo

Initial Comment:
Looking at imaplib.py, class IMAP4, method open(),
there are two arguments, host and port, which are never
used in the method.  Instead, self.host and self.port
(set only in __init__) are used.  This gives a
misleading notion of what open() does.  I suggest that
these arguments be removed, because currently an IMAP4
object cannot be open()ed later by an external user,
i.e., open() is really private.

----------------------------------------------------------------------

>Comment By: Piers Lauder (pierslauder)
Date: 2002-06-06 06:36

Message:
Logged In: YES 
user_id=196212

It's a bug. One should definately be able to supply
alternate host and port values when using open() from
a sub-class. Will fix.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-06 05:18

Message:
Logged In: YES 
user_id=6380

Hm, you seem to be right. Piers, what do you think?

----------------------------------------------------------------------

Comment By: Erik Demaine (edemaine)
Date: 2002-05-31 00:06

Message:
Logged In: YES 
user_id=265183

Looks OK, but shouldn't self.host and self.port be set if
they are specified in open()?  (Presumably in case another
method wants to use them.)  See attached alternative patch.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-25 00:36

Message:
Logged In: YES 
user_id=80475

The two arguments are needed because open() can be 
overridden in a sub-class.

Suggest testing to see if arguments are supplied and using 
them instead of self.host and self.port.  See attached 
patch.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559884&group_id=5470



From noreply@sourceforge.net  Wed Jun  5 23:53:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 15:53:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-559884 ] imaplib.IMAP4.open() typo
Message-ID: <E17FjeH-0004WR-00@usw-sf-web3.sourceforge.net>

Bugs item #559884, was opened at 2002-05-24 08:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559884&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Erik Demaine (edemaine)
Assigned to: Piers Lauder (pierslauder)
Summary: imaplib.IMAP4.open() typo

Initial Comment:
Looking at imaplib.py, class IMAP4, method open(),
there are two arguments, host and port, which are never
used in the method.  Instead, self.host and self.port
(set only in __init__) are used.  This gives a
misleading notion of what open() does.  I suggest that
these arguments be removed, because currently an IMAP4
object cannot be open()ed later by an external user,
i.e., open() is really private.

----------------------------------------------------------------------

>Comment By: Piers Lauder (pierslauder)
Date: 2002-06-06 08:53

Message:
Logged In: YES 
user_id=196212

Updated imaplib.py containing new versions of open for IMAP4
and IMAP4_SSL classes checked into CVS.

NB: the "self.host" and "self.port" instance variables are redundant,
but I've retained them for the sake of backwards-compatibility.


----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-06 06:36

Message:
Logged In: YES 
user_id=196212

It's a bug. One should definately be able to supply
alternate host and port values when using open() from
a sub-class. Will fix.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-06 05:18

Message:
Logged In: YES 
user_id=6380

Hm, you seem to be right. Piers, what do you think?

----------------------------------------------------------------------

Comment By: Erik Demaine (edemaine)
Date: 2002-05-31 00:06

Message:
Logged In: YES 
user_id=265183

Looks OK, but shouldn't self.host and self.port be set if
they are specified in open()?  (Presumably in case another
method wants to use them.)  See attached alternative patch.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-25 00:36

Message:
Logged In: YES 
user_id=80475

The two arguments are needed because open() can be 
overridden in a sub-class.

Suggest testing to see if arguments are supplied and using 
them instead of self.host and self.port.  See attached 
patch.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559884&group_id=5470



From noreply@sourceforge.net  Thu Jun  6 00:48:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 16:48:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-558488 ] DL_EXPORT on VC7 broken
Message-ID: <E17FkWC-0003tw-00@usw-sf-web2.sourceforge.net>

Bugs item #558488, was opened at 2002-05-20 19:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: David Aldridge (daldridge)
Assigned to: Mark Hammond (mhammond)
Summary: DL_EXPORT on VC7 broken

Initial Comment:
Extension modules (_sre, _socket, etc.) do not have 
their entry points exported correctly when building 
Python (2.1 onwards) with Microsoft Visual C++ 7 
(part of Visual Studio .NET).  (NOTE: Everything 
compiles and links without errors.  It's just the 
exports that are missing.)

Think through the prepocessor flow when compiling 
_sre.c, for example, the following happens (this is 
from memory so please excuse inaccuracies):

1) _sre.c #includes "python.h"

2) "python.h" pretty much immediatly 
#includes "config.h"

3) "config.h" has the following:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

4) USE_DL_EXPORT is NOT defined (and cannot be in the 
_sre project, or it will not import pythoncore's (?) 
exports), thus DL_EXPORT is not yet defined.

5) After preprocessing "config.h", we're back 
in "python.h", which has a block:

#ifndef DL_EXPORT
#define DL_EXPORT(RTYPE) RTYPE
#endif

6) Back in _sre.c, the extension module entry point 
is:

DL_EXPORT(void) init_sre()

This expands to

void init_sre()

And thus does not get exported.



If I change the "config.h" block above to be:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

(ie. add the DL_EXPORT line if/when USE_DL_IMPORT is 
defined), everything works correctly.  Not 
guaranteeing this is the "correct" solution, but it 
seems to work.

My specific test case was to build everything, run 
python.exe from the command line, then 
attempt "import re".

This results in a Traceback with "ImportError: 
dynamic module does not define init function 
(init_sre)".


----------------------------------------------------------------------

>Comment By: David Aldridge (daldridge)
Date: 2002-06-05 18:48

Message:
Logged In: YES 
user_id=550130

That's what I figured, too  (the "wouldn't work with VC6 either" 
comment, not the "because he's lonely" part ;-)

We were compiling/linking/using 2.1 with VC6 just fine -- no 
clue why it would be broken in VC7 (BTW, always using the 
GUI, never the cl.exe or msdev.exe/devenv.exe from the 
command line).  Perhaps the VC6->7 project converter hosed 
the .dsw/.dsps in some way, though the conversion seemed 
to work fine for all of our own stuff... *shrug*  I didn't think to 
do a visual comparison of the original .dsp's with the 
created .vcproj's (or workspace equivalents).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-05 14:40

Message:
Logged In: YES 
user_id=31435

Assigned to Mark because he's lonely <wink>.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 14:16

Message:
Logged In: YES 
user_id=6380

If you were right, it wouldn't build with VC6 either. But it does.

So what's wrong? I dunno. Asking Tim.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470



From noreply@sourceforge.net  Thu Jun  6 01:21:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 17:21:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-558488 ] DL_EXPORT on VC7 broken
Message-ID: <E17Fl1b-00042A-00@usw-sf-web4.sourceforge.net>

Bugs item #558488, was opened at 2002-05-20 20:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: David Aldridge (daldridge)
Assigned to: Mark Hammond (mhammond)
Summary: DL_EXPORT on VC7 broken

Initial Comment:
Extension modules (_sre, _socket, etc.) do not have 
their entry points exported correctly when building 
Python (2.1 onwards) with Microsoft Visual C++ 7 
(part of Visual Studio .NET).  (NOTE: Everything 
compiles and links without errors.  It's just the 
exports that are missing.)

Think through the prepocessor flow when compiling 
_sre.c, for example, the following happens (this is 
from memory so please excuse inaccuracies):

1) _sre.c #includes "python.h"

2) "python.h" pretty much immediatly 
#includes "config.h"

3) "config.h" has the following:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

4) USE_DL_EXPORT is NOT defined (and cannot be in the 
_sre project, or it will not import pythoncore's (?) 
exports), thus DL_EXPORT is not yet defined.

5) After preprocessing "config.h", we're back 
in "python.h", which has a block:

#ifndef DL_EXPORT
#define DL_EXPORT(RTYPE) RTYPE
#endif

6) Back in _sre.c, the extension module entry point 
is:

DL_EXPORT(void) init_sre()

This expands to

void init_sre()

And thus does not get exported.



If I change the "config.h" block above to be:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

(ie. add the DL_EXPORT line if/when USE_DL_IMPORT is 
defined), everything works correctly.  Not 
guaranteeing this is the "correct" solution, but it 
seems to work.

My specific test case was to build everything, run 
python.exe from the command line, then 
attempt "import re".

This results in a Traceback with "ImportError: 
dynamic module does not define init function 
(init_sre)".


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-06-05 20:21

Message:
Logged In: YES 
user_id=31435

Note that the MSVC project files we ship contain

/export:init_sre

in the linker options for the _sre project, so it doesn't 
matter whether the macros do anything in this project.  
Presumably VC7 screws this up, or the .dsp conversion 
dropped this linker flag on the floor.  MarkH and I promised 
ach other to rework this macro maze someday, but I 
haven't had time for it, and Mark hasn't either.  That's why 
I'm leaving it assigned to him <ahem>.

----------------------------------------------------------------------

Comment By: David Aldridge (daldridge)
Date: 2002-06-05 19:48

Message:
Logged In: YES 
user_id=550130

That's what I figured, too  (the "wouldn't work with VC6 either" 
comment, not the "because he's lonely" part ;-)

We were compiling/linking/using 2.1 with VC6 just fine -- no 
clue why it would be broken in VC7 (BTW, always using the 
GUI, never the cl.exe or msdev.exe/devenv.exe from the 
command line).  Perhaps the VC6->7 project converter hosed 
the .dsw/.dsps in some way, though the conversion seemed 
to work fine for all of our own stuff... *shrug*  I didn't think to 
do a visual comparison of the original .dsp's with the 
created .vcproj's (or workspace equivalents).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-05 15:40

Message:
Logged In: YES 
user_id=31435

Assigned to Mark because he's lonely <wink>.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 15:16

Message:
Logged In: YES 
user_id=6380

If you were right, it wouldn't build with VC6 either. But it does.

So what's wrong? I dunno. Asking Tim.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470



From noreply@sourceforge.net  Thu Jun  6 01:49:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 17:49:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-558488 ] DL_EXPORT on VC7 broken
Message-ID: <E17FlTF-0004Kw-00@usw-sf-web4.sourceforge.net>

Bugs item #558488, was opened at 2002-05-21 10:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: David Aldridge (daldridge)
Assigned to: Mark Hammond (mhammond)
Summary: DL_EXPORT on VC7 broken

Initial Comment:
Extension modules (_sre, _socket, etc.) do not have 
their entry points exported correctly when building 
Python (2.1 onwards) with Microsoft Visual C++ 7 
(part of Visual Studio .NET).  (NOTE: Everything 
compiles and links without errors.  It's just the 
exports that are missing.)

Think through the prepocessor flow when compiling 
_sre.c, for example, the following happens (this is 
from memory so please excuse inaccuracies):

1) _sre.c #includes "python.h"

2) "python.h" pretty much immediatly 
#includes "config.h"

3) "config.h" has the following:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

4) USE_DL_EXPORT is NOT defined (and cannot be in the 
_sre project, or it will not import pythoncore's (?) 
exports), thus DL_EXPORT is not yet defined.

5) After preprocessing "config.h", we're back 
in "python.h", which has a block:

#ifndef DL_EXPORT
#define DL_EXPORT(RTYPE) RTYPE
#endif

6) Back in _sre.c, the extension module entry point 
is:

DL_EXPORT(void) init_sre()

This expands to

void init_sre()

And thus does not get exported.



If I change the "config.h" block above to be:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

(ie. add the DL_EXPORT line if/when USE_DL_IMPORT is 
defined), everything works correctly.  Not 
guaranteeing this is the "correct" solution, but it 
seems to work.

My specific test case was to build everything, run 
python.exe from the command line, then 
attempt "import re".

This results in a Traceback with "ImportError: 
dynamic module does not define init function 
(init_sre)".


----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-06-06 10:49

Message:
Logged In: YES 
user_id=14198

This is a mess <wink>.

MSVC6 works as the linker command line specifies
"/export:init_sre" on the commandline.  It appears that the
MSVC7 migration process does *not* migrate this option. 
Hence src does not export that symbol in MSVC7.  ie, this
confirms exactly what Tim says.

As Tim says, this DL_* stuff is a mess.  I think we simply
need 2 macros - one that says "this is a public Python API
function" and another that says "this is a Python module
init function".  I see no other requirements in the core.

I am attaching a patch that fixes the VC7 build problems,
but not "once and for all".  See the comments in the patch.
 I am not necessarily suggesting it be applied.

Tim - do you agree we really only have these 2 requirements
(public Python API vs Python module init function).?  If so,
how about we just decide on names, and take the hit now?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-06 10:21

Message:
Logged In: YES 
user_id=31435

Note that the MSVC project files we ship contain

/export:init_sre

in the linker options for the _sre project, so it doesn't 
matter whether the macros do anything in this project.  
Presumably VC7 screws this up, or the .dsp conversion 
dropped this linker flag on the floor.  MarkH and I promised 
ach other to rework this macro maze someday, but I 
haven't had time for it, and Mark hasn't either.  That's why 
I'm leaving it assigned to him <ahem>.

----------------------------------------------------------------------

Comment By: David Aldridge (daldridge)
Date: 2002-06-06 09:48

Message:
Logged In: YES 
user_id=550130

That's what I figured, too  (the "wouldn't work with VC6 either" 
comment, not the "because he's lonely" part ;-)

We were compiling/linking/using 2.1 with VC6 just fine -- no 
clue why it would be broken in VC7 (BTW, always using the 
GUI, never the cl.exe or msdev.exe/devenv.exe from the 
command line).  Perhaps the VC6->7 project converter hosed 
the .dsw/.dsps in some way, though the conversion seemed 
to work fine for all of our own stuff... *shrug*  I didn't think to 
do a visual comparison of the original .dsp's with the 
created .vcproj's (or workspace equivalents).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-06 05:40

Message:
Logged In: YES 
user_id=31435

Assigned to Mark because he's lonely <wink>.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-06 05:16

Message:
Logged In: YES 
user_id=6380

If you were right, it wouldn't build with VC6 either. But it does.

So what's wrong? I dunno. Asking Tim.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470



From noreply@sourceforge.net  Thu Jun  6 01:50:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 17:50:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-558488 ] DL_EXPORT on VC7 broken
Message-ID: <E17FlUE-0000G4-00@usw-sf-web1.sourceforge.net>

Bugs item #558488, was opened at 2002-05-20 20:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470

Category: Build
Group: Platform-specific
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: David Aldridge (daldridge)
Assigned to: Mark Hammond (mhammond)
Summary: DL_EXPORT on VC7 broken

Initial Comment:
Extension modules (_sre, _socket, etc.) do not have 
their entry points exported correctly when building 
Python (2.1 onwards) with Microsoft Visual C++ 7 
(part of Visual Studio .NET).  (NOTE: Everything 
compiles and links without errors.  It's just the 
exports that are missing.)

Think through the prepocessor flow when compiling 
_sre.c, for example, the following happens (this is 
from memory so please excuse inaccuracies):

1) _sre.c #includes "python.h"

2) "python.h" pretty much immediatly 
#includes "config.h"

3) "config.h" has the following:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

4) USE_DL_EXPORT is NOT defined (and cannot be in the 
_sre project, or it will not import pythoncore's (?) 
exports), thus DL_EXPORT is not yet defined.

5) After preprocessing "config.h", we're back 
in "python.h", which has a block:

#ifndef DL_EXPORT
#define DL_EXPORT(RTYPE) RTYPE
#endif

6) Back in _sre.c, the extension module entry point 
is:

DL_EXPORT(void) init_sre()

This expands to

void init_sre()

And thus does not get exported.



If I change the "config.h" block above to be:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

(ie. add the DL_EXPORT line if/when USE_DL_IMPORT is 
defined), everything works correctly.  Not 
guaranteeing this is the "correct" solution, but it 
seems to work.

My specific test case was to build everything, run 
python.exe from the command line, then 
attempt "import re".

This results in a Traceback with "ImportError: 
dynamic module does not define init function 
(init_sre)".


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 20:50

Message:
Logged In: YES 
user_id=6380

I guess the converter didn't save the CPP flags.  The V6
project defines these in the "settings" dialog:
NDEBUG,WIN32,_WINDOWS,USE_DL_EXPORT

If you say that USE_DL_EXPORT is not defined (point 4 above)
that means the converter (or something else :-) lost that.

I'll close this now.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-06-05 20:49

Message:
Logged In: YES 
user_id=14198

This is a mess <wink>.

MSVC6 works as the linker command line specifies
"/export:init_sre" on the commandline.  It appears that the
MSVC7 migration process does *not* migrate this option. 
Hence src does not export that symbol in MSVC7.  ie, this
confirms exactly what Tim says.

As Tim says, this DL_* stuff is a mess.  I think we simply
need 2 macros - one that says "this is a public Python API
function" and another that says "this is a Python module
init function".  I see no other requirements in the core.

I am attaching a patch that fixes the VC7 build problems,
but not "once and for all".  See the comments in the patch.
 I am not necessarily suggesting it be applied.

Tim - do you agree we really only have these 2 requirements
(public Python API vs Python module init function).?  If so,
how about we just decide on names, and take the hit now?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-05 20:21

Message:
Logged In: YES 
user_id=31435

Note that the MSVC project files we ship contain

/export:init_sre

in the linker options for the _sre project, so it doesn't 
matter whether the macros do anything in this project.  
Presumably VC7 screws this up, or the .dsp conversion 
dropped this linker flag on the floor.  MarkH and I promised 
ach other to rework this macro maze someday, but I 
haven't had time for it, and Mark hasn't either.  That's why 
I'm leaving it assigned to him <ahem>.

----------------------------------------------------------------------

Comment By: David Aldridge (daldridge)
Date: 2002-06-05 19:48

Message:
Logged In: YES 
user_id=550130

That's what I figured, too  (the "wouldn't work with VC6 either" 
comment, not the "because he's lonely" part ;-)

We were compiling/linking/using 2.1 with VC6 just fine -- no 
clue why it would be broken in VC7 (BTW, always using the 
GUI, never the cl.exe or msdev.exe/devenv.exe from the 
command line).  Perhaps the VC6->7 project converter hosed 
the .dsw/.dsps in some way, though the conversion seemed 
to work fine for all of our own stuff... *shrug*  I didn't think to 
do a visual comparison of the original .dsp's with the 
created .vcproj's (or workspace equivalents).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-05 15:40

Message:
Logged In: YES 
user_id=31435

Assigned to Mark because he's lonely <wink>.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 15:16

Message:
Logged In: YES 
user_id=6380

If you were right, it wouldn't build with VC6 either. But it does.

So what's wrong? I dunno. Asking Tim.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470



From noreply@sourceforge.net  Thu Jun  6 01:57:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 17:57:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-558488 ] DL_EXPORT on VC7 broken
Message-ID: <E17Flav-0000Ks-00@usw-sf-web1.sourceforge.net>

Bugs item #558488, was opened at 2002-05-21 10:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470

Category: Build
Group: Platform-specific
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: David Aldridge (daldridge)
Assigned to: Mark Hammond (mhammond)
Summary: DL_EXPORT on VC7 broken

Initial Comment:
Extension modules (_sre, _socket, etc.) do not have 
their entry points exported correctly when building 
Python (2.1 onwards) with Microsoft Visual C++ 7 
(part of Visual Studio .NET).  (NOTE: Everything 
compiles and links without errors.  It's just the 
exports that are missing.)

Think through the prepocessor flow when compiling 
_sre.c, for example, the following happens (this is 
from memory so please excuse inaccuracies):

1) _sre.c #includes "python.h"

2) "python.h" pretty much immediatly 
#includes "config.h"

3) "config.h" has the following:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

4) USE_DL_EXPORT is NOT defined (and cannot be in the 
_sre project, or it will not import pythoncore's (?) 
exports), thus DL_EXPORT is not yet defined.

5) After preprocessing "config.h", we're back 
in "python.h", which has a block:

#ifndef DL_EXPORT
#define DL_EXPORT(RTYPE) RTYPE
#endif

6) Back in _sre.c, the extension module entry point 
is:

DL_EXPORT(void) init_sre()

This expands to

void init_sre()

And thus does not get exported.



If I change the "config.h" block above to be:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

(ie. add the DL_EXPORT line if/when USE_DL_IMPORT is 
defined), everything works correctly.  Not 
guaranteeing this is the "correct" solution, but it 
seems to work.

My specific test case was to build everything, run 
python.exe from the command line, then 
attempt "import re".

This results in a Traceback with "ImportError: 
dynamic module does not define init function 
(init_sre)".


----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-06-06 10:57

Message:
Logged In: YES 
user_id=14198

Actually, the problem is simply that the "export:init_sre"
option was dropped from the *linker*.

USE_DL_EXPORT was a noop when not building the core.  Hence,
_sre used an explicit "export:" linker option, while _winreg
(for example) just used an explicit dlexport() statement in
the code (which it could safely do as it is Windows specific)

So I am not sure that closing it is the right thing to do. 
IMO, the right thing to do is to rationalize these DL_EXPORT
macros once and for all (and I can remove yet another bit of
my shame from the core Python tree <wink>)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-06 10:50

Message:
Logged In: YES 
user_id=6380

I guess the converter didn't save the CPP flags.  The V6
project defines these in the "settings" dialog:
NDEBUG,WIN32,_WINDOWS,USE_DL_EXPORT

If you say that USE_DL_EXPORT is not defined (point 4 above)
that means the converter (or something else :-) lost that.

I'll close this now.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-06-06 10:49

Message:
Logged In: YES 
user_id=14198

This is a mess <wink>.

MSVC6 works as the linker command line specifies
"/export:init_sre" on the commandline.  It appears that the
MSVC7 migration process does *not* migrate this option. 
Hence src does not export that symbol in MSVC7.  ie, this
confirms exactly what Tim says.

As Tim says, this DL_* stuff is a mess.  I think we simply
need 2 macros - one that says "this is a public Python API
function" and another that says "this is a Python module
init function".  I see no other requirements in the core.

I am attaching a patch that fixes the VC7 build problems,
but not "once and for all".  See the comments in the patch.
 I am not necessarily suggesting it be applied.

Tim - do you agree we really only have these 2 requirements
(public Python API vs Python module init function).?  If so,
how about we just decide on names, and take the hit now?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-06 10:21

Message:
Logged In: YES 
user_id=31435

Note that the MSVC project files we ship contain

/export:init_sre

in the linker options for the _sre project, so it doesn't 
matter whether the macros do anything in this project.  
Presumably VC7 screws this up, or the .dsp conversion 
dropped this linker flag on the floor.  MarkH and I promised 
ach other to rework this macro maze someday, but I 
haven't had time for it, and Mark hasn't either.  That's why 
I'm leaving it assigned to him <ahem>.

----------------------------------------------------------------------

Comment By: David Aldridge (daldridge)
Date: 2002-06-06 09:48

Message:
Logged In: YES 
user_id=550130

That's what I figured, too  (the "wouldn't work with VC6 either" 
comment, not the "because he's lonely" part ;-)

We were compiling/linking/using 2.1 with VC6 just fine -- no 
clue why it would be broken in VC7 (BTW, always using the 
GUI, never the cl.exe or msdev.exe/devenv.exe from the 
command line).  Perhaps the VC6->7 project converter hosed 
the .dsw/.dsps in some way, though the conversion seemed 
to work fine for all of our own stuff... *shrug*  I didn't think to 
do a visual comparison of the original .dsp's with the 
created .vcproj's (or workspace equivalents).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-06 05:40

Message:
Logged In: YES 
user_id=31435

Assigned to Mark because he's lonely <wink>.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-06 05:16

Message:
Logged In: YES 
user_id=6380

If you were right, it wouldn't build with VC6 either. But it does.

So what's wrong? I dunno. Asking Tim.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470



From noreply@sourceforge.net  Thu Jun  6 02:08:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 18:08:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-558488 ] DL_EXPORT on VC7 broken
Message-ID: <E17FllZ-0005uT-00@usw-sf-web3.sourceforge.net>

Bugs item #558488, was opened at 2002-05-20 20:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470

Category: Build
Group: Platform-specific
>Status: Open
>Resolution: Later
Priority: 5
Submitted By: David Aldridge (daldridge)
Assigned to: Mark Hammond (mhammond)
Summary: DL_EXPORT on VC7 broken

Initial Comment:
Extension modules (_sre, _socket, etc.) do not have 
their entry points exported correctly when building 
Python (2.1 onwards) with Microsoft Visual C++ 7 
(part of Visual Studio .NET).  (NOTE: Everything 
compiles and links without errors.  It's just the 
exports that are missing.)

Think through the prepocessor flow when compiling 
_sre.c, for example, the following happens (this is 
from memory so please excuse inaccuracies):

1) _sre.c #includes "python.h"

2) "python.h" pretty much immediatly 
#includes "config.h"

3) "config.h" has the following:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

4) USE_DL_EXPORT is NOT defined (and cannot be in the 
_sre project, or it will not import pythoncore's (?) 
exports), thus DL_EXPORT is not yet defined.

5) After preprocessing "config.h", we're back 
in "python.h", which has a block:

#ifndef DL_EXPORT
#define DL_EXPORT(RTYPE) RTYPE
#endif

6) Back in _sre.c, the extension module entry point 
is:

DL_EXPORT(void) init_sre()

This expands to

void init_sre()

And thus does not get exported.



If I change the "config.h" block above to be:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

(ie. add the DL_EXPORT line if/when USE_DL_IMPORT is 
defined), everything works correctly.  Not 
guaranteeing this is the "correct" solution, but it 
seems to work.

My specific test case was to build everything, run 
python.exe from the command line, then 
attempt "import re".

This results in a Traceback with "ImportError: 
dynamic module does not define init function 
(init_sre)".


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-06-05 20:57

Message:
Logged In: YES 
user_id=14198

Actually, the problem is simply that the "export:init_sre"
option was dropped from the *linker*.

USE_DL_EXPORT was a noop when not building the core.  Hence,
_sre used an explicit "export:" linker option, while _winreg
(for example) just used an explicit dlexport() statement in
the code (which it could safely do as it is Windows specific)

So I am not sure that closing it is the right thing to do. 
IMO, the right thing to do is to rationalize these DL_EXPORT
macros once and for all (and I can remove yet another bit of
my shame from the core Python tree <wink>)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 20:50

Message:
Logged In: YES 
user_id=6380

I guess the converter didn't save the CPP flags.  The V6
project defines these in the "settings" dialog:
NDEBUG,WIN32,_WINDOWS,USE_DL_EXPORT

If you say that USE_DL_EXPORT is not defined (point 4 above)
that means the converter (or something else :-) lost that.

I'll close this now.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-06-05 20:49

Message:
Logged In: YES 
user_id=14198

This is a mess <wink>.

MSVC6 works as the linker command line specifies
"/export:init_sre" on the commandline.  It appears that the
MSVC7 migration process does *not* migrate this option. 
Hence src does not export that symbol in MSVC7.  ie, this
confirms exactly what Tim says.

As Tim says, this DL_* stuff is a mess.  I think we simply
need 2 macros - one that says "this is a public Python API
function" and another that says "this is a Python module
init function".  I see no other requirements in the core.

I am attaching a patch that fixes the VC7 build problems,
but not "once and for all".  See the comments in the patch.
 I am not necessarily suggesting it be applied.

Tim - do you agree we really only have these 2 requirements
(public Python API vs Python module init function).?  If so,
how about we just decide on names, and take the hit now?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-05 20:21

Message:
Logged In: YES 
user_id=31435

Note that the MSVC project files we ship contain

/export:init_sre

in the linker options for the _sre project, so it doesn't 
matter whether the macros do anything in this project.  
Presumably VC7 screws this up, or the .dsp conversion 
dropped this linker flag on the floor.  MarkH and I promised 
ach other to rework this macro maze someday, but I 
haven't had time for it, and Mark hasn't either.  That's why 
I'm leaving it assigned to him <ahem>.

----------------------------------------------------------------------

Comment By: David Aldridge (daldridge)
Date: 2002-06-05 19:48

Message:
Logged In: YES 
user_id=550130

That's what I figured, too  (the "wouldn't work with VC6 either" 
comment, not the "because he's lonely" part ;-)

We were compiling/linking/using 2.1 with VC6 just fine -- no 
clue why it would be broken in VC7 (BTW, always using the 
GUI, never the cl.exe or msdev.exe/devenv.exe from the 
command line).  Perhaps the VC6->7 project converter hosed 
the .dsw/.dsps in some way, though the conversion seemed 
to work fine for all of our own stuff... *shrug*  I didn't think to 
do a visual comparison of the original .dsp's with the 
created .vcproj's (or workspace equivalents).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-05 15:40

Message:
Logged In: YES 
user_id=31435

Assigned to Mark because he's lonely <wink>.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 15:16

Message:
Logged In: YES 
user_id=6380

If you were right, it wouldn't build with VC6 either. But it does.

So what's wrong? I dunno. Asking Tim.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470



From noreply@sourceforge.net  Thu Jun  6 02:17:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 18:17:11 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-480967 ] SHA 256/384/512 in Python 2.2
Message-ID: <E17Fltn-0004cw-00@usw-sf-web4.sourceforge.net>

Feature Requests item #480967, was opened at 2001-11-12 11:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=480967&group_id=5470

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Jesús Cea Avión (jcea)
Assigned to: Guido van Rossum (gvanrossum)
Summary: SHA 256/384/512 in Python 2.2

Initial Comment:
I know that Python 2.2. window is closing, but this
request seems to be very simple and low cost.

What about updating the SHA module to the new
SHA-256/384/512 standards?.

See, for example:

http://www.aarongifford.com/computers/sha.html

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 21:17

Message:
Logged In: YES 
user_id=6380

Closing, unresolved -- nobody ever submitted a patch AFAIK.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-11-13 03:31

Message:
Logged In: YES 
user_id=21627

Unless somebody is forthcoming RSN with a patch to Python, I
don't think the sha module can be extended before 2.2.
Notice that the last beta of 2.2 is scheduled for this week.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=480967&group_id=5470



From noreply@sourceforge.net  Thu Jun  6 02:33:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 18:33:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-558488 ] DL_EXPORT on VC7 broken
Message-ID: <E17Fm9B-0006AX-00@usw-sf-web3.sourceforge.net>

Bugs item #558488, was opened at 2002-05-20 20:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: Later
Priority: 5
Submitted By: David Aldridge (daldridge)
Assigned to: Mark Hammond (mhammond)
Summary: DL_EXPORT on VC7 broken

Initial Comment:
Extension modules (_sre, _socket, etc.) do not have 
their entry points exported correctly when building 
Python (2.1 onwards) with Microsoft Visual C++ 7 
(part of Visual Studio .NET).  (NOTE: Everything 
compiles and links without errors.  It's just the 
exports that are missing.)

Think through the prepocessor flow when compiling 
_sre.c, for example, the following happens (this is 
from memory so please excuse inaccuracies):

1) _sre.c #includes "python.h"

2) "python.h" pretty much immediatly 
#includes "config.h"

3) "config.h" has the following:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

4) USE_DL_EXPORT is NOT defined (and cannot be in the 
_sre project, or it will not import pythoncore's (?) 
exports), thus DL_EXPORT is not yet defined.

5) After preprocessing "config.h", we're back 
in "python.h", which has a block:

#ifndef DL_EXPORT
#define DL_EXPORT(RTYPE) RTYPE
#endif

6) Back in _sre.c, the extension module entry point 
is:

DL_EXPORT(void) init_sre()

This expands to

void init_sre()

And thus does not get exported.



If I change the "config.h" block above to be:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

(ie. add the DL_EXPORT line if/when USE_DL_IMPORT is 
defined), everything works correctly.  Not 
guaranteeing this is the "correct" solution, but it 
seems to work.

My specific test case was to build everything, run 
python.exe from the command line, then 
attempt "import re".

This results in a Traceback with "ImportError: 
dynamic module does not define init function 
(init_sre)".


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-06-05 21:33

Message:
Logged In: YES 
user_id=31435

I didn't say they were a mess here.  It's unkind to criticize 
in public <wink>.  I really like your idea of purpose-oriented 
names.  How about PyAPI_FUNC and PyMODINIT_FUNC?  
Would it also be helpful to distinguish public API functions 
from public API data?  We have plenty of the latter too, and 
it's always surprised me that no platform has popped up 
that requires treating cross-blob data in a different way 
than cross-blob entry points.  But maybe that's because 
only Windows Geeks enjoy pleasant support for cross-blob 
stuff of any kind <0.9 wink>.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-06-05 20:57

Message:
Logged In: YES 
user_id=14198

Actually, the problem is simply that the "export:init_sre"
option was dropped from the *linker*.

USE_DL_EXPORT was a noop when not building the core.  Hence,
_sre used an explicit "export:" linker option, while _winreg
(for example) just used an explicit dlexport() statement in
the code (which it could safely do as it is Windows specific)

So I am not sure that closing it is the right thing to do. 
IMO, the right thing to do is to rationalize these DL_EXPORT
macros once and for all (and I can remove yet another bit of
my shame from the core Python tree <wink>)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 20:50

Message:
Logged In: YES 
user_id=6380

I guess the converter didn't save the CPP flags.  The V6
project defines these in the "settings" dialog:
NDEBUG,WIN32,_WINDOWS,USE_DL_EXPORT

If you say that USE_DL_EXPORT is not defined (point 4 above)
that means the converter (or something else :-) lost that.

I'll close this now.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-06-05 20:49

Message:
Logged In: YES 
user_id=14198

This is a mess <wink>.

MSVC6 works as the linker command line specifies
"/export:init_sre" on the commandline.  It appears that the
MSVC7 migration process does *not* migrate this option. 
Hence src does not export that symbol in MSVC7.  ie, this
confirms exactly what Tim says.

As Tim says, this DL_* stuff is a mess.  I think we simply
need 2 macros - one that says "this is a public Python API
function" and another that says "this is a Python module
init function".  I see no other requirements in the core.

I am attaching a patch that fixes the VC7 build problems,
but not "once and for all".  See the comments in the patch.
 I am not necessarily suggesting it be applied.

Tim - do you agree we really only have these 2 requirements
(public Python API vs Python module init function).?  If so,
how about we just decide on names, and take the hit now?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-05 20:21

Message:
Logged In: YES 
user_id=31435

Note that the MSVC project files we ship contain

/export:init_sre

in the linker options for the _sre project, so it doesn't 
matter whether the macros do anything in this project.  
Presumably VC7 screws this up, or the .dsp conversion 
dropped this linker flag on the floor.  MarkH and I promised 
ach other to rework this macro maze someday, but I 
haven't had time for it, and Mark hasn't either.  That's why 
I'm leaving it assigned to him <ahem>.

----------------------------------------------------------------------

Comment By: David Aldridge (daldridge)
Date: 2002-06-05 19:48

Message:
Logged In: YES 
user_id=550130

That's what I figured, too  (the "wouldn't work with VC6 either" 
comment, not the "because he's lonely" part ;-)

We were compiling/linking/using 2.1 with VC6 just fine -- no 
clue why it would be broken in VC7 (BTW, always using the 
GUI, never the cl.exe or msdev.exe/devenv.exe from the 
command line).  Perhaps the VC6->7 project converter hosed 
the .dsw/.dsps in some way, though the conversion seemed 
to work fine for all of our own stuff... *shrug*  I didn't think to 
do a visual comparison of the original .dsp's with the 
created .vcproj's (or workspace equivalents).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-05 15:40

Message:
Logged In: YES 
user_id=31435

Assigned to Mark because he's lonely <wink>.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 15:16

Message:
Logged In: YES 
user_id=6380

If you were right, it wouldn't build with VC6 either. But it does.

So what's wrong? I dunno. Asking Tim.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470



From noreply@sourceforge.net  Thu Jun  6 04:31:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 05 Jun 2002 20:31:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-558166 ] Shutdown of IDLE blows up
Message-ID: <E17Fnzr-0007NG-00@usw-sf-web3.sourceforge.net>

Bugs item #558166, was opened at 2002-05-20 05:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558166&group_id=5470

Category: IDLE
Group: Python 2.2.1
Status: Open
>Resolution: Works For Me
Priority: 1
Submitted By: Phillip Ruggera (pruggera)
Assigned to: Nobody/Anonymous (nobody)
Summary: Shutdown of IDLE blows up

Initial Comment:
When I shut down IDLE on Windows 2000 Professional 
running Python 2.2.1 I get a popup with "TclNotifier: 
pythonw.exe - Application Error" in the name bar 
and "The instruction at "0x77fcb144" referenced memory 
at "0x00b3300010". The memory could not be "read"."  
in the message box.

----------------------------------------------------------------------

>Comment By: Phillip Ruggera (pruggera)
Date: 2002-06-06 03:31

Message:
Logged In: YES 
user_id=16022

I have a Norton AntiVirus 2001.  When I shut it down, IDLE 
then works fine.  When I turn it back on, IDLE still works 
fine.  Amazing.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 18:48

Message:
Logged In: YES 
user_id=6380

I'm sure you see this, and it's probably a bug somewhere, but 
nobody else is seeing this. We tested IDLE and Python 2.2.1 
on Windows 2000 and we don't see this here. So I doubt 
you're going to have much luck getting this fixed.

Do you have a virus detector installed? Try turning it off.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558166&group_id=5470



From noreply@sourceforge.net  Thu Jun  6 08:14:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 06 Jun 2002 00:14:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-563740 ] complex() doesn't use __complex__
Message-ID: <E17FrTr-00006Z-00@usw-sf-web2.sourceforge.net>

Bugs item #563740, was opened at 2002-06-03 00:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563740&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: complex() doesn't use __complex__

Initial Comment:
complex() with a new-style instance of a class that
implements __complex__ doesn't work, because it only
looks for __complex__ when the argument is a classic
instance.  It should always look for __complex__ (but
probably after checking for a complex instance).

See
http://mail.python.org/pipermail/python-dev/2002-June/024898.html
and my reply.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-06 02:14

Message:
Logged In: YES 
user_id=80475

This patch passes regression and fixes the bug:

class OS:
   def __complex__(self): return 1+2j
class NS(object):
   def __complex__(self): return 3+4j
print map(complex, [5, 6.6, 7+8j, 9L, OS(), NS(), "10+11j"])

Please confirm that I'm using the best way to detect a new-
style class instances with Py_TPFLAGS_HEAPTYPE.

Also, incidental to this bug, which error messages do you 
want for int, float, complex, and long:
-- object can't be converted to float
-- float() needs a string argument
-- float() needs a string or number argument

Right now, the messages are not consistent.  I prefer the 
third style to be used through-out.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563740&group_id=5470



From noreply@sourceforge.net  Thu Jun  6 09:53:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 06 Jun 2002 01:53:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-211481 ] os.stat() doesn't return st_rdev
Message-ID: <E17Ft18-0005RS-00@usw-sf-web1.sourceforge.net>

Bugs item #211481, was opened at 2000-08-09 15:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=211481&group_id=5470

Category: Extension Modules
Group: Feature Request
Status: Closed
Resolution: Later
Priority: 4
Submitted By: Jan Danielsson (volt)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: os.stat() doesn't return st_rdev

Initial Comment:
The call os.stat() returns the fields st_mode, st_ino,
st_nlink, st_uid, st_gid, st_size, st_atime, st_mtime
st_ctime from "struct stat".
To be able to explore device nodes on a linux system
the field st_rdev needed as the major and minor device number is stored in this field.
It would be nice if it could be added as an extra element
in the tuple returned by os.stat, os.lstat etc.


----------------------------------------------------------------------

>Comment By: Walter Dörwald (doerwalter)
Date: 2002-06-06 10:53

Message:
Logged In: YES 
user_id=89016

I guess this should be closed as fixed (and removed from PEP
42), because it works now via attributes:
>>> import os
>>> os.stat("/dev/tty0").st_rdev
1024

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2000-09-15 21:52

Message:
Added as a feature request to PEP 42.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2000-08-30 06:51

Message:
We could add an additional element to the end with the st_rdev value, but I'm not convinced that's really the right approach; some other platform that defines another field could get that added at the end of the return tuple, and the the 11th position would have incompatible values.

The "right" solution may be to create a new function (nstat?) that returns either a dictionary or other object that has entries for all the fields (using None for fields a platform doesn't provide values for).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=211481&group_id=5470



From noreply@sourceforge.net  Thu Jun  6 13:51:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 06 Jun 2002 05:51:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-558166 ] Shutdown of IDLE blows up
Message-ID: <E17Fwk5-0008FB-00@usw-sf-web1.sourceforge.net>

Bugs item #558166, was opened at 2002-05-20 01:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558166&group_id=5470

Category: IDLE
Group: Python 2.2.1
>Status: Closed
>Resolution: Invalid
Priority: 1
Submitted By: Phillip Ruggera (pruggera)
Assigned to: Nobody/Anonymous (nobody)
Summary: Shutdown of IDLE blows up

Initial Comment:
When I shut down IDLE on Windows 2000 Professional 
running Python 2.2.1 I get a popup with "TclNotifier: 
pythonw.exe - Application Error" in the name bar 
and "The instruction at "0x77fcb144" referenced memory 
at "0x00b3300010". The memory could not be "read"."  
in the message box.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-06 08:51

Message:
Logged In: YES 
user_id=6380

Antivirus software is one of the leading causes of
mysterious Python failures.

----------------------------------------------------------------------

Comment By: Phillip Ruggera (pruggera)
Date: 2002-06-05 23:31

Message:
Logged In: YES 
user_id=16022

I have a Norton AntiVirus 2001.  When I shut it down, IDLE 
then works fine.  When I turn it back on, IDLE still works 
fine.  Amazing.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 14:48

Message:
Logged In: YES 
user_id=6380

I'm sure you see this, and it's probably a bug somewhere, but 
nobody else is seeing this. We tested IDLE and Python 2.2.1 
on Windows 2000 and we don't see this here. So I doubt 
you're going to have much luck getting this fixed.

Do you have a virus detector installed? Try turning it off.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558166&group_id=5470



From noreply@sourceforge.net  Thu Jun  6 15:27:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 06 Jun 2002 07:27:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-563740 ] complex() doesn't use __complex__
Message-ID: <E17FyEq-0000ee-00@usw-sf-web1.sourceforge.net>

Bugs item #563740, was opened at 2002-06-03 01:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563740&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: complex() doesn't use __complex__

Initial Comment:
complex() with a new-style instance of a class that
implements __complex__ doesn't work, because it only
looks for __complex__ when the argument is a classic
instance.  It should always look for __complex__ (but
probably after checking for a complex instance).

See
http://mail.python.org/pipermail/python-dev/2002-June/024898.html
and my reply.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-06 10:27

Message:
Logged In: YES 
user_id=6380

- It's better not to test for any kind of instances at all
-- just take the __complex__ attribute if it exists. That
will allow extension types to support complex conversion.

- Please add a unit test.

- I like the 3rd form best too.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-06 03:14

Message:
Logged In: YES 
user_id=80475

This patch passes regression and fixes the bug:

class OS:
   def __complex__(self): return 1+2j
class NS(object):
   def __complex__(self): return 3+4j
print map(complex, [5, 6.6, 7+8j, 9L, OS(), NS(), "10+11j"])

Please confirm that I'm using the best way to detect a new-
style class instances with Py_TPFLAGS_HEAPTYPE.

Also, incidental to this bug, which error messages do you 
want for int, float, complex, and long:
-- object can't be converted to float
-- float() needs a string argument
-- float() needs a string or number argument

Right now, the messages are not consistent.  I prefer the 
third style to be used through-out.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563740&group_id=5470



From noreply@sourceforge.net  Thu Jun  6 16:09:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 06 Jun 2002 08:09:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect
Message-ID: <E17FytI-0004wb-00@usw-sf-web4.sourceforge.net>

Bugs item #549151, was opened at 2002-04-26 16:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Jeremy Hylton (jhylton)
Summary: urllib2 POSTs on redirect

Initial Comment:

urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the 
POST method on redirect, contrary to RFC1945 section 9.3:

> 9.3  Redirection 3xx
> 
>    This class of status code indicates that further action needs to be
>    taken by the user agent in order to fulfill the request. The action
>    required may be carried out by the user agent without interaction
>    with the user if and only if the method used in the subsequent
>    request is GET or HEAD. A user agent should never automatically
>    redirect a request more than 5 times, since such redirections usually
>    indicate an infinite loop.

Can be fixed in HTTPRedirectHandler.http_error_302 by replacing
        new = Request(newurl, req.get_data())

with
        new = Request(newurl)

so that GET is done on redirect instead of POST.

I suppose the limit of 10 in the same function should be changed to 5, also.


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-06 15:09

Message:
Logged In: YES 
user_id=31392

I think you need to review the current HTTP spec -- RFC 2616
-- and look at the section on redirection (10.3).  I think
urllib2 could improve its handling of redirection, but the
behavior you describe from lynx sounds incorrect.  I'd be
happy to review a patch the implemented the current spec.

Also, RFC 2616 removes the recommendation of a 5 redirect limit.




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 18:10

Message:
Logged In: YES 
user_id=6380

Fair enough. I'll leve it to Jeremy to review the proposed
fix. (Note that he's busy though.)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-29 16:29

Message:
Logged In: YES 
user_id=261020

I don't see why it shouldn't substitue a GET.  That certainly seems to be
the standard practice (well, at least that's what lynx does), and in the case
of the only site where I've encountered redirects on POST, the redirect URL
contains urlencoded stuff, so it clearly expects the user-agent to do a GET.
The site would break if this didn't happen, so I guess Netscape and IE must
do the same thing.

Clearly the RFC *does* allow this, though it doesn't require it (or specify
what should happen here in any way other than to say that a POST is not
allowed, in fact).  Since it's standard practice and allowed by the RFC, I
don't think it should be an error.

John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 00:53

Message:
Logged In: YES 
user_id=6380

Hm, the way I interpret the text you quote, if the original
request is  a POST, it should probably not substitute a GET
but report the error.

Assigning to Jeremy since it's his module.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-28 16:21

Message:
Logged In: YES 
user_id=261020

1. Bug is also in 2.2 branch

2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers:

new = Request(newurl, headers=req.headers)

3. I guess 10 should be replaced with 4, not 5.


John


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470



From noreply@sourceforge.net  Thu Jun  6 16:10:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 06 Jun 2002 08:10:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-564931 ] compile traceback must include filename
Message-ID: <E17Fyua-0004xI-00@usw-sf-web4.sourceforge.net>

Bugs item #564931, was opened at 2002-06-05 17:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564931&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
>Assigned to: Jeremy Hylton (jhylton)
Summary: compile traceback must include filename

Initial Comment:
> >>> compile("1+*3", "myfile.py", "exec")
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "<string>", line 1
>     1+*3
>       ^
> SyntaxError: invalid syntax
> >>>
> 
> Shouldn't it print "myfile.py" instead of "<string>"?

Yes.

--Guido van Rossum 


----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2002-06-05 18:57

Message:
Logged In: YES 
user_id=11105

To avoid any confusion: I (Thomas Heller) copied the 'Initial 
Comment' from a message posted to python-dev by Guido.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564931&group_id=5470



From noreply@sourceforge.net  Thu Jun  6 16:12:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 06 Jun 2002 08:12:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-564913 ] Partial Function redeffinition...
Message-ID: <E17Fywc-0004y7-00@usw-sf-web4.sourceforge.net>

Bugs item #564913, was opened at 2002-06-05 16:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564913&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Alex A. Naanou (alex_nanou)
Assigned to: Nobody/Anonymous (nobody)
Summary: Partial Function redeffinition...

Initial Comment:
description: 
part of the functions definition is changed in runtime (the 
value of the default parameter to exact).
 (expected to possible only by function redefinition)

expected behaver:
the default value of 'x' would stay constant, thus 
rendering the output of all cases to be the same (and 
equal to '[0]').

code: 
//see the attached file. 

test systems: 
WIN2K v.5.00.2195 SP2 
- ActivePython 2.2 //I do not remember the details
- Python 2.2 (#1, Dec 31 2001, 15:21:18) [GCC 2.95.3-5 
(cygwin special)] on cygwin 

With Respect.. 
Alex. 

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-06 15:12

Message:
Logged In: YES 
user_id=31392

This is not a bug.  It is the intended behavior of reference
semantics and mutable objects.  If you want a copy, ask for
it explicitly.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564913&group_id=5470



From noreply@sourceforge.net  Thu Jun  6 16:25:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 06 Jun 2002 08:25:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-559117 ] HTTPSConnection memory leakage
Message-ID: <E17Fz8S-000547-00@usw-sf-web4.sourceforge.net>

Bugs item #559117, was opened at 2002-05-22 11:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559117&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Paolo Andreetto (pandreetto)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTTPSConnection memory leakage

Initial Comment:
I've tried this test script:

import time,httplib,gc

gc.set_debug(gc.DEBUG_STATS)

while 1:
	conn=httplib.HTTPSConnection('<myhostip>')
	conn.connect()
	conn.request('GET', '/index.html')
	res=conn.getresponse()
	conn.close()
	time.sleep(1)
	print gc.collect()

and I've seen that a memory leakage occurs. The process
requires 4Kbytes every 10 seconds. The output of
garbage collector shows that at the end of each cycle a
new object is contained into last generation.
I've tried also to remove from the script both the
conn.request and the conn.getresponse but nothing has
changed; perhaps the problem is in the connect() method.
All tests run on linux (debian distribution, sid
version for i386) with kernel 2.4.18 and python 2.1.3.
The web server is apache with mod-ssl on redhat 7.2.


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-06 15:25

Message:
Logged In: YES 
user_id=31392

Several leaks were fixed just before Python 2.2b1.  It looks
like those changes were not backported to the 2.1
maintenance branch.  I don't have time to backport the
changes, but I'd be happy to review a patch.  Since the
problem wouldn't get fix until a (hypothetical) 2.1.4, you
might get more mileage out of an upgrade to 2.2.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559117&group_id=5470



From noreply@sourceforge.net  Thu Jun  6 16:37:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 06 Jun 2002 08:37:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-565373 ] IDLE needs printing
Message-ID: <E17FzKU-00059E-00@usw-sf-web4.sourceforge.net>

Bugs item #565373, was opened at 2002-06-06 11:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565373&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: IDLE needs printing

Initial Comment:
IDLE really needs a way to print.

It turns out that on Windows, you can print a text file
by invoking notepad /p filename. We can do that using
os.popen() (rather than os.system(), which opens an
ugly DOS box).

On Unix, we can invoke lpr filename in the same way.

So we can make this a standard menu item that takes the
command line to use from the configuration file.  I'll
implement this when I have time (or someone else can
implement it).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565373&group_id=5470



From noreply@sourceforge.net  Thu Jun  6 16:47:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 06 Jun 2002 08:47:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-563740 ] complex() doesn't use __complex__
Message-ID: <E17FzUD-0005DX-00@usw-sf-web4.sourceforge.net>

Bugs item #563740, was opened at 2002-06-03 00:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563740&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Raymond Hettinger (rhettinger)
Summary: complex() doesn't use __complex__

Initial Comment:
complex() with a new-style instance of a class that
implements __complex__ doesn't work, because it only
looks for __complex__ when the argument is a classic
instance.  It should always look for __complex__ (but
probably after checking for a complex instance).

See
http://mail.python.org/pipermail/python-dev/2002-June/024898.html
and my reply.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-06 10:47

Message:
Logged In: YES 
user_id=80475

Done.

Committed as:
 complexobject.c 2.60
 abstract.c 2.102
 test_b1.py 1.47

Closing bug.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-06 09:27

Message:
Logged In: YES 
user_id=6380

- It's better not to test for any kind of instances at all
-- just take the __complex__ attribute if it exists. That
will allow extension types to support complex conversion.

- Please add a unit test.

- I like the 3rd form best too.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-06 02:14

Message:
Logged In: YES 
user_id=80475

This patch passes regression and fixes the bug:

class OS:
   def __complex__(self): return 1+2j
class NS(object):
   def __complex__(self): return 3+4j
print map(complex, [5, 6.6, 7+8j, 9L, OS(), NS(), "10+11j"])

Please confirm that I'm using the best way to detect a new-
style class instances with Py_TPFLAGS_HEAPTYPE.

Also, incidental to this bug, which error messages do you 
want for int, float, complex, and long:
-- object can't be converted to float
-- float() needs a string argument
-- float() needs a string or number argument

Right now, the messages are not consistent.  I prefer the 
third style to be used through-out.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563740&group_id=5470



From noreply@sourceforge.net  Thu Jun  6 17:54:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 06 Jun 2002 09:54:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-565414 ] urllib FancyURLopener.__init__ / urlopen
Message-ID: <E17G0Wb-0007CH-00@usw-sf-web3.sourceforge.net>

Bugs item #565414, was opened at 2002-06-06 12:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565414&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: urllib FancyURLopener.__init__ / urlopen

Initial Comment:
Fred, you changed line 69 in urllib.py to call
FancyURLopener()
with kwargs, but the constructor (line 538) doesn't
accept **kwargs.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565414&group_id=5470



From noreply@sourceforge.net  Thu Jun  6 16:40:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 06 Jun 2002 08:40:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-565373 ] IDLE needs printing
Message-ID: <E17FzNT-0001AN-00@usw-sf-web1.sourceforge.net>

Bugs item #565373, was opened at 2002-06-06 11:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565373&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: IDLE needs printing

Initial Comment:
IDLE really needs a way to print.

It turns out that on Windows, you can print a text file
by invoking notepad /p filename. We can do that using
os.popen() (rather than os.system(), which opens an
ugly DOS box).

On Unix, we can invoke lpr filename in the same way.

So we can make this a standard menu item that takes the
command line to use from the configuration file.  I'll
implement this when I have time (or someone else can
implement it).


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-06 11:40

Message:
Logged In: YES 
user_id=6380

According to Mark Hammond, you can also print by copying the
file to the default printer name; if you have win32all,
win32print.GetDefaultPrinter() returns the pathname for the
default printer (e.g. \brat\canon).

Tim Peters notes that you can use "start /min notepad /p
filename" to avoid opening notepad's main window (it still
shows a dialog with a cancel button for a fraction of a
second).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565373&group_id=5470



From noreply@sourceforge.net  Thu Jun  6 22:25:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 06 Jun 2002 14:25:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect
Message-ID: <E17G4km-00014Z-00@usw-sf-web2.sourceforge.net>

Bugs item #549151, was opened at 2002-04-26 17:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Jeremy Hylton (jhylton)
Summary: urllib2 POSTs on redirect

Initial Comment:

urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the 
POST method on redirect, contrary to RFC1945 section 9.3:

> 9.3  Redirection 3xx
> 
>    This class of status code indicates that further action needs to be
>    taken by the user agent in order to fulfill the request. The action
>    required may be carried out by the user agent without interaction
>    with the user if and only if the method used in the subsequent
>    request is GET or HEAD. A user agent should never automatically
>    redirect a request more than 5 times, since such redirections usually
>    indicate an infinite loop.

Can be fixed in HTTPRedirectHandler.http_error_302 by replacing
        new = Request(newurl, req.get_data())

with
        new = Request(newurl)

so that GET is done on redirect instead of POST.

I suppose the limit of 10 in the same function should be changed to 5, also.


----------------------------------------------------------------------

>Comment By: John J Lee (jjlee)
Date: 2002-06-06 22:25

Message:
Logged In: YES 
user_id=261020

Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I
check, I see that even RFC 1945 (HTTP/1.0) has a whole set of
restrictions on 30x for particular values of x which I missed
completely.

I guess it should do what Guido suggested -- report an error if a
POST is redirected -- until somebody gets time to do it properly.
I won't have time for a couple of months, but if nobody has done
it by then I'll upload a patch.


John


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-06 16:09

Message:
Logged In: YES 
user_id=31392

I think you need to review the current HTTP spec -- RFC 2616
-- and look at the section on redirection (10.3).  I think
urllib2 could improve its handling of redirection, but the
behavior you describe from lynx sounds incorrect.  I'd be
happy to review a patch the implemented the current spec.

Also, RFC 2616 removes the recommendation of a 5 redirect limit.




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 19:10

Message:
Logged In: YES 
user_id=6380

Fair enough. I'll leve it to Jeremy to review the proposed
fix. (Note that he's busy though.)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-29 17:29

Message:
Logged In: YES 
user_id=261020

I don't see why it shouldn't substitue a GET.  That certainly seems to be
the standard practice (well, at least that's what lynx does), and in the case
of the only site where I've encountered redirects on POST, the redirect URL
contains urlencoded stuff, so it clearly expects the user-agent to do a GET.
The site would break if this didn't happen, so I guess Netscape and IE must
do the same thing.

Clearly the RFC *does* allow this, though it doesn't require it (or specify
what should happen here in any way other than to say that a POST is not
allowed, in fact).  Since it's standard practice and allowed by the RFC, I
don't think it should be an error.

John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 01:53

Message:
Logged In: YES 
user_id=6380

Hm, the way I interpret the text you quote, if the original
request is  a POST, it should probably not substitute a GET
but report the error.

Assigning to Jeremy since it's his module.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-28 17:21

Message:
Logged In: YES 
user_id=261020

1. Bug is also in 2.2 branch

2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers:

new = Request(newurl, headers=req.headers)

3. I guess 10 should be replaced with 4, not 5.


John


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470



From noreply@sourceforge.net  Fri Jun  7 01:07:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 06 Jun 2002 17:07:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-558488 ] DL_EXPORT on VC7 broken
Message-ID: <E17G7HR-00029v-00@usw-sf-web4.sourceforge.net>

Bugs item #558488, was opened at 2002-05-21 10:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: Later
Priority: 5
Submitted By: David Aldridge (daldridge)
Assigned to: Mark Hammond (mhammond)
Summary: DL_EXPORT on VC7 broken

Initial Comment:
Extension modules (_sre, _socket, etc.) do not have 
their entry points exported correctly when building 
Python (2.1 onwards) with Microsoft Visual C++ 7 
(part of Visual Studio .NET).  (NOTE: Everything 
compiles and links without errors.  It's just the 
exports that are missing.)

Think through the prepocessor flow when compiling 
_sre.c, for example, the following happens (this is 
from memory so please excuse inaccuracies):

1) _sre.c #includes "python.h"

2) "python.h" pretty much immediatly 
#includes "config.h"

3) "config.h" has the following:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

4) USE_DL_EXPORT is NOT defined (and cannot be in the 
_sre project, or it will not import pythoncore's (?) 
exports), thus DL_EXPORT is not yet defined.

5) After preprocessing "config.h", we're back 
in "python.h", which has a block:

#ifndef DL_EXPORT
#define DL_EXPORT(RTYPE) RTYPE
#endif

6) Back in _sre.c, the extension module entry point 
is:

DL_EXPORT(void) init_sre()

This expands to

void init_sre()

And thus does not get exported.



If I change the "config.h" block above to be:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

(ie. add the DL_EXPORT line if/when USE_DL_IMPORT is 
defined), everything works correctly.  Not 
guaranteeing this is the "correct" solution, but it 
seems to work.

My specific test case was to build everything, run 
python.exe from the command line, then 
attempt "import re".

This results in a Traceback with "ImportError: 
dynamic module does not define init function 
(init_sre)".


----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-06-07 10:07

Message:
Logged In: YES 
user_id=14198

OK Tim - how do we go about doing this?  I like the idea of
PyAPI_FUNC, PyAPI_DATA and PyMODINIT_FUNC - but there are
literally *hundreds* of places that need to be changed.

While the changes are largely mechanical, it will still have
a large impact.  Should we coordinate with other people that
this change is about to happen, or shall I just put together
a patch, we can check it in, and then go on vacation while
the shit hits the fan? <wink>

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-06 11:33

Message:
Logged In: YES 
user_id=31435

I didn't say they were a mess here.  It's unkind to criticize 
in public <wink>.  I really like your idea of purpose-oriented 
names.  How about PyAPI_FUNC and PyMODINIT_FUNC?  
Would it also be helpful to distinguish public API functions 
from public API data?  We have plenty of the latter too, and 
it's always surprised me that no platform has popped up 
that requires treating cross-blob data in a different way 
than cross-blob entry points.  But maybe that's because 
only Windows Geeks enjoy pleasant support for cross-blob 
stuff of any kind <0.9 wink>.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-06-06 10:57

Message:
Logged In: YES 
user_id=14198

Actually, the problem is simply that the "export:init_sre"
option was dropped from the *linker*.

USE_DL_EXPORT was a noop when not building the core.  Hence,
_sre used an explicit "export:" linker option, while _winreg
(for example) just used an explicit dlexport() statement in
the code (which it could safely do as it is Windows specific)

So I am not sure that closing it is the right thing to do. 
IMO, the right thing to do is to rationalize these DL_EXPORT
macros once and for all (and I can remove yet another bit of
my shame from the core Python tree <wink>)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-06 10:50

Message:
Logged In: YES 
user_id=6380

I guess the converter didn't save the CPP flags.  The V6
project defines these in the "settings" dialog:
NDEBUG,WIN32,_WINDOWS,USE_DL_EXPORT

If you say that USE_DL_EXPORT is not defined (point 4 above)
that means the converter (or something else :-) lost that.

I'll close this now.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-06-06 10:49

Message:
Logged In: YES 
user_id=14198

This is a mess <wink>.

MSVC6 works as the linker command line specifies
"/export:init_sre" on the commandline.  It appears that the
MSVC7 migration process does *not* migrate this option. 
Hence src does not export that symbol in MSVC7.  ie, this
confirms exactly what Tim says.

As Tim says, this DL_* stuff is a mess.  I think we simply
need 2 macros - one that says "this is a public Python API
function" and another that says "this is a Python module
init function".  I see no other requirements in the core.

I am attaching a patch that fixes the VC7 build problems,
but not "once and for all".  See the comments in the patch.
 I am not necessarily suggesting it be applied.

Tim - do you agree we really only have these 2 requirements
(public Python API vs Python module init function).?  If so,
how about we just decide on names, and take the hit now?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-06 10:21

Message:
Logged In: YES 
user_id=31435

Note that the MSVC project files we ship contain

/export:init_sre

in the linker options for the _sre project, so it doesn't 
matter whether the macros do anything in this project.  
Presumably VC7 screws this up, or the .dsp conversion 
dropped this linker flag on the floor.  MarkH and I promised 
ach other to rework this macro maze someday, but I 
haven't had time for it, and Mark hasn't either.  That's why 
I'm leaving it assigned to him <ahem>.

----------------------------------------------------------------------

Comment By: David Aldridge (daldridge)
Date: 2002-06-06 09:48

Message:
Logged In: YES 
user_id=550130

That's what I figured, too  (the "wouldn't work with VC6 either" 
comment, not the "because he's lonely" part ;-)

We were compiling/linking/using 2.1 with VC6 just fine -- no 
clue why it would be broken in VC7 (BTW, always using the 
GUI, never the cl.exe or msdev.exe/devenv.exe from the 
command line).  Perhaps the VC6->7 project converter hosed 
the .dsw/.dsps in some way, though the conversion seemed 
to work fine for all of our own stuff... *shrug*  I didn't think to 
do a visual comparison of the original .dsp's with the 
created .vcproj's (or workspace equivalents).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-06 05:40

Message:
Logged In: YES 
user_id=31435

Assigned to Mark because he's lonely <wink>.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-06 05:16

Message:
Logged In: YES 
user_id=6380

If you were right, it wouldn't build with VC6 either. But it does.

So what's wrong? I dunno. Asking Tim.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470



From noreply@sourceforge.net  Fri Jun  7 01:24:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 06 Jun 2002 17:24:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-558488 ] DL_EXPORT on VC7 broken
Message-ID: <E17G7Y9-0002Iu-00@usw-sf-web4.sourceforge.net>

Bugs item #558488, was opened at 2002-05-20 20:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: Later
Priority: 5
Submitted By: David Aldridge (daldridge)
Assigned to: Mark Hammond (mhammond)
Summary: DL_EXPORT on VC7 broken

Initial Comment:
Extension modules (_sre, _socket, etc.) do not have 
their entry points exported correctly when building 
Python (2.1 onwards) with Microsoft Visual C++ 7 
(part of Visual Studio .NET).  (NOTE: Everything 
compiles and links without errors.  It's just the 
exports that are missing.)

Think through the prepocessor flow when compiling 
_sre.c, for example, the following happens (this is 
from memory so please excuse inaccuracies):

1) _sre.c #includes "python.h"

2) "python.h" pretty much immediatly 
#includes "config.h"

3) "config.h" has the following:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

4) USE_DL_EXPORT is NOT defined (and cannot be in the 
_sre project, or it will not import pythoncore's (?) 
exports), thus DL_EXPORT is not yet defined.

5) After preprocessing "config.h", we're back 
in "python.h", which has a block:

#ifndef DL_EXPORT
#define DL_EXPORT(RTYPE) RTYPE
#endif

6) Back in _sre.c, the extension module entry point 
is:

DL_EXPORT(void) init_sre()

This expands to

void init_sre()

And thus does not get exported.



If I change the "config.h" block above to be:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

(ie. add the DL_EXPORT line if/when USE_DL_IMPORT is 
defined), everything works correctly.  Not 
guaranteeing this is the "correct" solution, but it 
seems to work.

My specific test case was to build everything, run 
python.exe from the command line, then 
attempt "import re".

This results in a Traceback with "ImportError: 
dynamic module does not define init function 
(init_sre)".


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-06-06 20:24

Message:
Logged In: YES 
user_id=31435

How about:

1. Write the new macros first, and check them in.  The old 
macros are still defined at this point.

2. Convert one module to use them, and check it in.

3. Post a brief "conversion guide" to Python-Dev.  This 
will also end up in somebody's 2.3 migration guide.

4. Let people have at it.  A little bit of this kind of 
editing is fun, mindless work, and I expect lots of people 
will do just a little bit of it.  We can clean up what's 
left.

5. When all uses have been converted, we "deprecate" the 
current macro set, and argue on Python-Dev about when they 
can go away.

It's easy if it's possible to make everyone feel guilty 
<wink>.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-06-06 20:07

Message:
Logged In: YES 
user_id=14198

OK Tim - how do we go about doing this?  I like the idea of
PyAPI_FUNC, PyAPI_DATA and PyMODINIT_FUNC - but there are
literally *hundreds* of places that need to be changed.

While the changes are largely mechanical, it will still have
a large impact.  Should we coordinate with other people that
this change is about to happen, or shall I just put together
a patch, we can check it in, and then go on vacation while
the shit hits the fan? <wink>

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-05 21:33

Message:
Logged In: YES 
user_id=31435

I didn't say they were a mess here.  It's unkind to criticize 
in public <wink>.  I really like your idea of purpose-oriented 
names.  How about PyAPI_FUNC and PyMODINIT_FUNC?  
Would it also be helpful to distinguish public API functions 
from public API data?  We have plenty of the latter too, and 
it's always surprised me that no platform has popped up 
that requires treating cross-blob data in a different way 
than cross-blob entry points.  But maybe that's because 
only Windows Geeks enjoy pleasant support for cross-blob 
stuff of any kind <0.9 wink>.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-06-05 20:57

Message:
Logged In: YES 
user_id=14198

Actually, the problem is simply that the "export:init_sre"
option was dropped from the *linker*.

USE_DL_EXPORT was a noop when not building the core.  Hence,
_sre used an explicit "export:" linker option, while _winreg
(for example) just used an explicit dlexport() statement in
the code (which it could safely do as it is Windows specific)

So I am not sure that closing it is the right thing to do. 
IMO, the right thing to do is to rationalize these DL_EXPORT
macros once and for all (and I can remove yet another bit of
my shame from the core Python tree <wink>)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 20:50

Message:
Logged In: YES 
user_id=6380

I guess the converter didn't save the CPP flags.  The V6
project defines these in the "settings" dialog:
NDEBUG,WIN32,_WINDOWS,USE_DL_EXPORT

If you say that USE_DL_EXPORT is not defined (point 4 above)
that means the converter (or something else :-) lost that.

I'll close this now.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-06-05 20:49

Message:
Logged In: YES 
user_id=14198

This is a mess <wink>.

MSVC6 works as the linker command line specifies
"/export:init_sre" on the commandline.  It appears that the
MSVC7 migration process does *not* migrate this option. 
Hence src does not export that symbol in MSVC7.  ie, this
confirms exactly what Tim says.

As Tim says, this DL_* stuff is a mess.  I think we simply
need 2 macros - one that says "this is a public Python API
function" and another that says "this is a Python module
init function".  I see no other requirements in the core.

I am attaching a patch that fixes the VC7 build problems,
but not "once and for all".  See the comments in the patch.
 I am not necessarily suggesting it be applied.

Tim - do you agree we really only have these 2 requirements
(public Python API vs Python module init function).?  If so,
how about we just decide on names, and take the hit now?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-05 20:21

Message:
Logged In: YES 
user_id=31435

Note that the MSVC project files we ship contain

/export:init_sre

in the linker options for the _sre project, so it doesn't 
matter whether the macros do anything in this project.  
Presumably VC7 screws this up, or the .dsp conversion 
dropped this linker flag on the floor.  MarkH and I promised 
ach other to rework this macro maze someday, but I 
haven't had time for it, and Mark hasn't either.  That's why 
I'm leaving it assigned to him <ahem>.

----------------------------------------------------------------------

Comment By: David Aldridge (daldridge)
Date: 2002-06-05 19:48

Message:
Logged In: YES 
user_id=550130

That's what I figured, too  (the "wouldn't work with VC6 either" 
comment, not the "because he's lonely" part ;-)

We were compiling/linking/using 2.1 with VC6 just fine -- no 
clue why it would be broken in VC7 (BTW, always using the 
GUI, never the cl.exe or msdev.exe/devenv.exe from the 
command line).  Perhaps the VC6->7 project converter hosed 
the .dsw/.dsps in some way, though the conversion seemed 
to work fine for all of our own stuff... *shrug*  I didn't think to 
do a visual comparison of the original .dsp's with the 
created .vcproj's (or workspace equivalents).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-05 15:40

Message:
Logged In: YES 
user_id=31435

Assigned to Mark because he's lonely <wink>.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 15:16

Message:
Logged In: YES 
user_id=6380

If you were right, it wouldn't build with VC6 either. But it does.

So what's wrong? I dunno. Asking Tim.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470



From noreply@sourceforge.net  Fri Jun  7 09:38:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 07 Jun 2002 01:38:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-565710 ] ImportError: No module named _socket
Message-ID: <E17GFGA-0007Z1-00@usw-sf-web4.sourceforge.net>

Bugs item #565710, was opened at 2002-06-07 10:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565710&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Philipp Kolmann (pkolmann)
Assigned to: Nobody/Anonymous (nobody)
Summary: ImportError: No module named _socket

Initial Comment:
Hi,

I just wanted to try out Mailman on a Sun Solaris
machine and compiled therefore Python 2.2.

It did compile ok, but there seems to be a problem with
the socket library:

bash-2.03$ python /opt/PYthon/lib/python2.2/socket.py
Traceback (most recent call last):
  File "/opt/PYthon/lib/python2.2/socket.py", line 41, in ?
    from _socket import *
ImportError: No module named _socket


Could you help me with this problem.

Thanks a lot
Philipp Kolmann

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565710&group_id=5470



From noreply@sourceforge.net  Fri Jun  7 11:11:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 07 Jun 2002 03:11:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-565747 ] crash on gethostbyaddr
Message-ID: <E17GGik-0000zo-00@usw-sf-web2.sourceforge.net>

Bugs item #565747, was opened at 2002-06-07 02:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565747&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Joerg Beyer (jbeyer)
Assigned to: Nobody/Anonymous (nobody)
Summary: crash on gethostbyaddr

Initial Comment:
if python is compiled with --disable-ipv6, AND the
host has ipv6 enabled. Then calling

python2.2 -c "import socket; print
socket.gethostbyaddr('::0')"

you get a

Segmentation fault

This is caused by Python copying the V6 information
returned by the OS into the V4 struct of Python.See the
attached diff for socketmodule.c for a fix.

Alternatively, one could move the memcpy at the end of
setipaddr() into the switch, so that if the system
returns "unknown address family", the invalid copy is
not executed.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565747&group_id=5470



From noreply@sourceforge.net  Fri Jun  7 13:14:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 07 Jun 2002 05:14:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-565786 ] termcap vs terminfo - AIX 4.3.3
Message-ID: <E17GIdC-0006Kw-00@usw-sf-web1.sourceforge.net>

Bugs item #565786, was opened at 2002-06-07 14:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565786&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Matthews (mcmatthews)
Assigned to: Nobody/Anonymous (nobody)
Summary: termcap vs terminfo - AIX 4.3.3

Initial Comment:
Hi,

I am compiling Python-2.2.1 on AIX 4.3.3 and do not 
have the termcap library available. 

The command:
./Modules/ld_so_aix cc_r -bI:Modules/python.exp 
build/temp.aix-4.3-2.2/_cursesmodule.o -
L/usr/local/lib -lcurses -ltermcap -o build/lib.aix-
4.3-2.2/_curses.so

fails with:
ld: 0706-006 Cannot find or open library file: -l 
termcap
        ld:open(): A file or directory in the path 
name does not exist.

So I enabled the line in Modules/Setup "#readline 
readline.c -lreadline -ltermcap" as "readline 
readline.c -lreadline" .

However the compile fails because not all of 
readline.c 's include files are available:
"./Modules/readline.c", line 17.10: 1506-296 (S) 
#include file <readline/readline.h> not found.
"./Modules/readline.c", line 18.10: 1506-296 (S) 
#include file <readline/history.h> not found.

These include files are not in the 2.0, 2.0.1 or 2.2.1 
source files.

I could not find a GNU site where I had access to 
download the source for readline. 

Am I on the right track? Or would the linker still 
fail after I compile readline.C with the missing 
include files? Should I rather be using terminfo?

Yours sincerely

Chris Matthews


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565786&group_id=5470



From noreply@sourceforge.net  Fri Jun  7 14:33:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 07 Jun 2002 06:33:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-565710 ] ImportError: No module named _socket
Message-ID: <E17GJsK-0004Uy-00@usw-sf-web3.sourceforge.net>

Bugs item #565710, was opened at 2002-06-07 08:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565710&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Philipp Kolmann (pkolmann)
Assigned to: Nobody/Anonymous (nobody)
Summary: ImportError: No module named _socket

Initial Comment:
Hi,

I just wanted to try out Mailman on a Sun Solaris
machine and compiled therefore Python 2.2.

It did compile ok, but there seems to be a problem with
the socket library:

bash-2.03$ python /opt/PYthon/lib/python2.2/socket.py
Traceback (most recent call last):
  File "/opt/PYthon/lib/python2.2/socket.py", line 41, in ?
    from _socket import *
ImportError: No module named _socket


Could you help me with this problem.

Thanks a lot
Philipp Kolmann

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-06-07 13:33

Message:
Logged In: YES 
user_id=6656

The problem is probably ssl support.  Try editing
Modules/Setup and uncommenting the line:

#_socket socketmodule.c

If you *need* ssl support, then you'll have to dig deeper...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565710&group_id=5470



From noreply@sourceforge.net  Fri Jun  7 14:34:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 07 Jun 2002 06:34:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-565747 ] crash on gethostbyaddr
Message-ID: <E17GJsr-0004VT-00@usw-sf-web3.sourceforge.net>

Bugs item #565747, was opened at 2002-06-07 10:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565747&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Joerg Beyer (jbeyer)
>Assigned to: Martin v. Löwis (loewis)
Summary: crash on gethostbyaddr

Initial Comment:
if python is compiled with --disable-ipv6, AND the
host has ipv6 enabled. Then calling

python2.2 -c "import socket; print
socket.gethostbyaddr('::0')"

you get a

Segmentation fault

This is caused by Python copying the V6 information
returned by the OS into the V4 struct of Python.See the
attached diff for socketmodule.c for a fix.

Alternatively, one could move the memcpy at the end of
setipaddr() into the switch, so that if the system
returns "unknown address family", the invalid copy is
not executed.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565747&group_id=5470



From noreply@sourceforge.net  Fri Jun  7 14:37:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 07 Jun 2002 06:37:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-565786 ] termcap vs terminfo - AIX 4.3.3
Message-ID: <E17GJwC-0004XW-00@usw-sf-web3.sourceforge.net>

Bugs item #565786, was opened at 2002-06-07 12:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565786&group_id=5470

Category: Build
Group: Platform-specific
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Chris Matthews (mcmatthews)
>Assigned to: Michael Hudson (mwh)
Summary: termcap vs terminfo - AIX 4.3.3

Initial Comment:
Hi,

I am compiling Python-2.2.1 on AIX 4.3.3 and do not 
have the termcap library available. 

The command:
./Modules/ld_so_aix cc_r -bI:Modules/python.exp 
build/temp.aix-4.3-2.2/_cursesmodule.o -
L/usr/local/lib -lcurses -ltermcap -o build/lib.aix-
4.3-2.2/_curses.so

fails with:
ld: 0706-006 Cannot find or open library file: -l 
termcap
        ld:open(): A file or directory in the path 
name does not exist.

So I enabled the line in Modules/Setup "#readline 
readline.c -lreadline -ltermcap" as "readline 
readline.c -lreadline" .

However the compile fails because not all of 
readline.c 's include files are available:
"./Modules/readline.c", line 17.10: 1506-296 (S) 
#include file <readline/readline.h> not found.
"./Modules/readline.c", line 18.10: 1506-296 (S) 
#include file <readline/history.h> not found.

These include files are not in the 2.0, 2.0.1 or 2.2.1 
source files.

I could not find a GNU site where I had access to 
download the source for readline. 

Am I on the right track? Or would the linker still 
fail after I compile readline.C with the missing 
include files? Should I rather be using terminfo?

Yours sincerely

Chris Matthews


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-06-07 13:37

Message:
Logged In: YES 
user_id=6656

Um, if you don't have readline installed you can't build the
readline module.

You should be able to get readline from any GNU mirror. 
There's a fairly enormous list of these here: 

    http://www.gnu.org/order/ftp.html

You might be able to get AIX binaries somwhere, wouldn't
know about that.

I'm closing this.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565786&group_id=5470



From noreply@sourceforge.net  Fri Jun  7 15:24:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 07 Jun 2002 07:24:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-565747 ] crash on gethostbyaddr
Message-ID: <E17GKfh-0003zO-00@usw-sf-web2.sourceforge.net>

Bugs item #565747, was opened at 2002-06-07 12:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565747&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Joerg Beyer (jbeyer)
Assigned to: Martin v. Löwis (loewis)
Summary: crash on gethostbyaddr

Initial Comment:
if python is compiled with --disable-ipv6, AND the
host has ipv6 enabled. Then calling

python2.2 -c "import socket; print
socket.gethostbyaddr('::0')"

you get a

Segmentation fault

This is caused by Python copying the V6 information
returned by the OS into the V4 struct of Python.See the
attached diff for socketmodule.c for a fix.

Alternatively, one could move the memcpy at the end of
setipaddr() into the switch, so that if the system
returns "unknown address family", the invalid copy is
not executed.

----------------------------------------------------------------------

Comment By: Jürgen Hermann (jhermann)
Date: 2002-06-07 16:24

Message:
Logged In: YES 
user_id=39128

We found out a little more: after applying the fix, we get
"unsupported address family" exceptions for IPV6 addresses,
but also we cannot open sockets any more ("could not
connect" exceptions by urllib for any URL). So the fix is
not complete. BTW, the bug appears with Python 2.2, Python
2.0 and 2.1 _do_ work on the same machine.

Another piece of information: we tried to --enable-ipv6 on
that machine (SuSE 7.0, gcc 2.9.95), and got this:

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I./Include -DHAVE_CONFIG_H
-DUSE_SSL -I/netsite/include -I/netsite/include/openssl -c
./Modules/socketmodul

./Modules/socketmodule.c: In function `makesockaddr':
./Modules/socketmodule.c:733: structure has no member named
`sin6_scope_id'
./Modules/socketmodule.c: In function `getsockaddrarg':
./Modules/socketmodule.c:846: structure has no member named
`sin6_scope_id'
./Modules/socketmodule.c: In function `PySocket_getnameinfo':
./Modules/socketmodule.c:2598: structure has no member named
`sin6_scope_id'
make: *** [Modules/socketmodule.o] Error 1 

Don't know whether that is SuSE 7.0's fault.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565747&group_id=5470



From noreply@sourceforge.net  Fri Jun  7 20:01:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 07 Jun 2002 12:01:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows)
Message-ID: <E17GOzV-0001yq-00@usw-sf-web1.sourceforge.net>

Bugs item #216289, was opened at 2000-10-07 02:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: Later
Priority: 3
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: Programs using Tkinter sometimes can't shut down (Windows)

Initial Comment:
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


----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-06-07 19:01

Message:
Logged In: YES 
user_id=143340

Hmmm. 
I run a Python Tcl/Tk application several times every day - 
the very application that prompted my bug-hunt.

I do use "pythonw.exe" to launch it, but it used to hang 
almost as badly as "python.exe".

Whilst developing this app I used "python.exe" and 
experienced no hang-ups.

The Tcl guys point out that this bug is only one of several 
possible causes of the hang-up, maybe you are just out of 
luck.

The patch has fixed the problem on three Win98 machines, 
all of which exhibited the problem before updating the DLLs.

One thought - are you sure there weren't multiple copies of 
the tcl83.dll and tk83.dll files? My (only) copies were 
in "D:\python20\DLLs"

good luck,
John.


----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-06-03 18:55

Message:
Logged In: YES 
user_id=72656

providing Tim with a fixed DLL exactly according to John 
Popplewell's patch did not fix the problem for him.  That 
makes it seem fishy that John really didn't see the problem 
any more.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-03 16:59

Message:
Logged In: YES 
user_id=31435

I tried replacing Python 2.2.1's tk83.dll and tcl83.dll (from 
Tcl/Tk 8.3.2) with newer matched sets from

A) PythonWare's py21 distribution (Tcl/Tk 8.3.3).

and again from

B) ActiveState's Tcl/Tk 8.3.4.

All the symptoms originally reported here persisted on 
Win98SE despite that.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-22 13:57

Message:
Logged In: NO 

I am new to Python and encountered this bug on my very first 
Tkinter application.  It persists in Python 2.2.1 under 
Windows Me. Needless to say, it makes a bad first 
impression.  Basically, this thread says that Tkinter has been 
broken for a year and a half on a popular platform at a time 
when Python is trying to expand its user base.  Hopefully, this 
bug will be corrected soon.

If Tcl/Tk 8.4 is not released shortly you might try repackaging 
Tkinter for Win32 with an earlier version of Tcl/Tk, such as 
8.0, that doesn't encounter this problem.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-23 03:36

Message:
Logged In: YES 
user_id=6380

The proper action is to wait until Tcl 8.3.5 is released,
and then shaming someone else in providing you with a set of
Windowsbinaries for Tcl. You may also ask Hobbs if there's a
Windows project file to build Tcl/Tk for Windows.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-03-12 02:31

Message:
Logged In: YES 
user_id=72656

I did end up back-porting this to the 8.3.4+ Tcl CVS on 
2002-02-25, which means it will be in an eventual 8.3.5.  
It is already in the release 8.4 alpha series.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-10 01:50

Message:
Logged In: YES 
user_id=31435

Back to Guido:  Do you think you know what the proper 
action is?  (You said that's why you reopened it, and 
there's been no new info here since then.)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-26 00:55

Message:
Logged In: YES 
user_id=143340

I knew I wasn't getting to the heart of it ....

Almost a one-liner!

It has been seriously spoiling my (otherwise crash free) 
Python experience on Win9x - hope it gets fixed soon.

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-25 23:39

Message:
Logged In: YES 
user_id=6380

Reopened until we know what the proper action is.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-02-25 23:32

Message:
Logged In: YES 
user_id=72656

This is mostly correct, and is fixed in the 8.4 Tcl sources 
already (I guess we can backport this).  This was mentioned 
in SF Tcl bug (account for chopped URL):

https://sourceforge.net/tracker/?
func=detail&aid=217982&group_id=10894&atid=110894

and the code comment is:

    /*
     * Only finalize the notifier if a notifier was 
installed in the
     * current thread; there is a route in which this is not
     * guaranteed to be true (when tclWin32Dll.c:DllMain() 
is called
     * with the flag DLL_PROCESS_DETACH by the OS, which 
could be
     * doing so from a thread that's never previously been 
involved
     * with Tcl, e.g. the task manager) so this check is 
important.
     *
     * Fixes Bug #217982 reported by Hugh Vu and Gene 
Leache.
     */
    if (tsdPtr == NULL) {
	return;
    }


----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 22:41

Message:
Logged In: YES 
user_id=143340

This one has been torturing me for a while.

Managed to track it down to a problem inside Tcl.
For the Tcl8.3.4 source distribution the problem is in
the file win/tclWinNotify.c 

void Tcl_FinalizeNotifier(ClientData clientData)
{
    ThreadSpecificData *tsdPtr = 
                         (ThreadSpecificData *) clientData;

    /* sometimes called with tsdPtr == NULL */
    if ( tsdPtr != NULL )
    {
        DeleteCriticalSection(&tsdPtr->crit);
        CloseHandle(tsdPtr->event);

        /*
         * Clean up the timer and messaging 
         * window for this thread.
         */

        if (tsdPtr->hwnd) {
	    KillTimer(tsdPtr->hwnd, INTERVAL_TIMER);
            DestroyWindow(tsdPtr->hwnd);
        }
    }

    /*
     * If this is the last thread to use the notifier, 
     * unregister the notifier window class.
     */

    Tcl_MutexLock(&notifierMutex);
    if ( notifierCount && !--notifierCount ) {
	UnregisterClassA( "TclNotifier", 
                          TclWinGetTclInstance());
    }
    Tcl_MutexUnlock(&notifierMutex);
}

This bodge doesn't address the underlying problem but has 
stopped me from tearing all my hair out,

cheers,
John Popplewell.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-24 22:27

Message:
Logged In: YES 
user_id=31435

FYI, you don't need an IDE to do this -- in Win9x, hit 
Ctrl+Alt+Del and kill the process directly.

A saner <wink> solution is to develop under Win2K, which 
doesn't appear to suffer this problem (the only reports 
I've seen, and experienced myself, came from Win9x boxes).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-24 08:52

Message:
Logged In: NO 

For those who are still trapped in this bug's hell, I will 
gladly share the one thing that saved my sanity:  
WingIDE's 'Kill' command will shut down the program with 
apparent 100% certainty and no fear of lockups.  WingIDE 
has its own issues, so its not a perfect solution, but if 
you are like me and Joe (above) who test in small 
iterations, then using 'Kill' to quit out of your app while 
testing is a workaround that may preserve your sanity.

Perhaps the python gods and the Wing guys can get together 
and tell us how to replicate 'kill' into our code.  For 
now, I'll use WingIDE to edit, and pythonw.exe for my final 
client's delivery.

----------------------------------------------------------------------

Comment By: Howard Lightstone (hlightstone)
Date: 2001-09-05 17:43

Message:
Logged In: YES 
user_id=66570

I sometimes get bunches of these....

A tool I use (Taskinfo2000) reports that (after killing 
winoldap):

python.exe is blocked on a mutex named OLESCELOCKMUTEX.
The reported state is "Console Terminating".  There appears 
to be only one (os) thread running.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-02 20:06

Message:
Logged In: YES 
user_id=31435

No sign of progress on this presumed Tk/Tcl Windows bug in 
over 3 months, so closing it for lack of hope.

----------------------------------------------------------------------

Comment By: Doug Henderson (djhender)
Date: 2001-02-06 05:13

Message:
This was a symptom I saw while tracking down the essence of the problem reported in #131207.  Using Win98SE, I would get an error dialog (GPF?) in the Kernel, and sometimes the dos prompt would not come back.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-12-13 02:00

Message:
Just reproduced w/ current CVS, but didn't hang until the 8th try.

http://dev.scriptics.com/software/tcltk/ says 8.3 is still the latest released version; don't know whether that URL still makes sense, though.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-12-12 20:58

Message:
Tim, can you still reproduce this with the current CVS version?

There's been one critical patch to _tkinter since the 2.0 release.

An alternative would be to try with a newer version of Tcl (isn't 8.4 out already?).


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-15 16:47

Message:
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>

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-13 14:40

Message:
Back to Tim since I have no clue what to do here.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-12 17:25

Message:
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.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-10-07 07:37

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470



From noreply@sourceforge.net  Fri Jun  7 20:21:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 07 Jun 2002 12:21:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-532646 ] Recursive class instance "error"
Message-ID: <E17GPII-00073j-00@usw-sf-web2.sourceforge.net>

Bugs item #532646, was opened at 2002-03-20 13:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Gregor Mirai (gregmi)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Recursive class instance "error"

Initial Comment:
If one writes the following code (tested on Python  
2.1, 2.2 on platforms MacOS X Server, MacOS X, Windows 
98, NT, 2000) one can easily produce several "errors".

MacOS X, MacOS X Server (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name,
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
Segmentation fault

Win98, NT, 2000 (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
foo
__repr__ __call__ __call__ __call__ ... ad inf



----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 15:21

Message:
Logged In: YES 
user_id=33168

The attached patch stops the segfault and raises an exception:
TypeError: 'A' max recursion limit (100000) exceeded

I'm not sure if this is genarally applicable, or what a
reasonable # is.
100,000 was a guess and should probably be made a #def
w/comment.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-21 04:47

Message:
Logged In: NO 

>>> a=A() 
>>> a.foo 
foo 
__repr__ __call__ __call__ __call__ ... ad inf

This is normal behavior. The code at the top is buggy. The 
correct one is:

class A:
  def __getattr__(self, name):
    if name == '__repr__':
      return self.__repr__()
    print name
    return A()

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-20 17:10

Message:
Logged In: YES 
user_id=6380

This is buggy user code.

But the segfault should be fixed if possible.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470



From noreply@sourceforge.net  Fri Jun  7 21:08:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 07 Jun 2002 13:08:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-532646 ] Recursive class instance "error"
Message-ID: <E17GQ24-0002lE-00@usw-sf-web1.sourceforge.net>

Bugs item #532646, was opened at 2002-03-20 13:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Gregor Mirai (gregmi)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Recursive class instance "error"

Initial Comment:
If one writes the following code (tested on Python  
2.1, 2.2 on platforms MacOS X Server, MacOS X, Windows 
98, NT, 2000) one can easily produce several "errors".

MacOS X, MacOS X Server (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name,
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
Segmentation fault

Win98, NT, 2000 (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
foo
__repr__ __call__ __call__ __call__ ... ad inf



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-07 16:08

Message:
Logged In: YES 
user_id=6380

Is this fix enough?  Aren't there lots of other ways to
generate the same error?  E.g. new-style classes (where this
particular example doesn't apply, but others might).

Or is this specific to instance_call?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 15:21

Message:
Logged In: YES 
user_id=33168

The attached patch stops the segfault and raises an exception:
TypeError: 'A' max recursion limit (100000) exceeded

I'm not sure if this is genarally applicable, or what a
reasonable # is.
100,000 was a guess and should probably be made a #def
w/comment.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-21 04:47

Message:
Logged In: NO 

>>> a=A() 
>>> a.foo 
foo 
__repr__ __call__ __call__ __call__ ... ad inf

This is normal behavior. The code at the top is buggy. The 
correct one is:

class A:
  def __getattr__(self, name):
    if name == '__repr__':
      return self.__repr__()
    print name
    return A()

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-20 17:10

Message:
Logged In: YES 
user_id=6380

This is buggy user code.

But the segfault should be fixed if possible.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470



From noreply@sourceforge.net  Fri Jun  7 21:23:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 07 Jun 2002 13:23:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-532646 ] Recursive class instance "error"
Message-ID: <E17GQGz-0008SM-00@usw-sf-web3.sourceforge.net>

Bugs item #532646, was opened at 2002-03-20 13:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Gregor Mirai (gregmi)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Recursive class instance "error"

Initial Comment:
If one writes the following code (tested on Python  
2.1, 2.2 on platforms MacOS X Server, MacOS X, Windows 
98, NT, 2000) one can easily produce several "errors".

MacOS X, MacOS X Server (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name,
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
Segmentation fault

Win98, NT, 2000 (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
foo
__repr__ __call__ __call__ __call__ ... ad inf



----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 16:23

Message:
Logged In: YES 
user_id=33168

I don't know.  I tried to come up with other test cases and
failed.
Tried __str__ and __getitem__.  Also tried new-style classes.

The problem was that the code bounced back and forth
between PyObject_Call() & instance_call() (mutual recursion).


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-07 16:08

Message:
Logged In: YES 
user_id=6380

Is this fix enough?  Aren't there lots of other ways to
generate the same error?  E.g. new-style classes (where this
particular example doesn't apply, but others might).

Or is this specific to instance_call?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 15:21

Message:
Logged In: YES 
user_id=33168

The attached patch stops the segfault and raises an exception:
TypeError: 'A' max recursion limit (100000) exceeded

I'm not sure if this is genarally applicable, or what a
reasonable # is.
100,000 was a guess and should probably be made a #def
w/comment.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-21 04:47

Message:
Logged In: NO 

>>> a=A() 
>>> a.foo 
foo 
__repr__ __call__ __call__ __call__ ... ad inf

This is normal behavior. The code at the top is buggy. The 
correct one is:

class A:
  def __getattr__(self, name):
    if name == '__repr__':
      return self.__repr__()
    print name
    return A()

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-20 17:10

Message:
Logged In: YES 
user_id=6380

This is buggy user code.

But the segfault should be fixed if possible.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470



From noreply@sourceforge.net  Fri Jun  7 21:27:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 07 Jun 2002 13:27:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-532646 ] Recursive class instance "error"
Message-ID: <E17GQKy-0007r6-00@usw-sf-web2.sourceforge.net>

Bugs item #532646, was opened at 2002-03-20 13:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Gregor Mirai (gregmi)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Recursive class instance "error"

Initial Comment:
If one writes the following code (tested on Python  
2.1, 2.2 on platforms MacOS X Server, MacOS X, Windows 
98, NT, 2000) one can easily produce several "errors".

MacOS X, MacOS X Server (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name,
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
Segmentation fault

Win98, NT, 2000 (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
foo
__repr__ __call__ __call__ __call__ ... ad inf



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-07 16:27

Message:
Logged In: YES 
user_id=6380

Fair enough.  Ideally this should share the recursion_limit
variable from ceval.c and the recursion_depth field of the
stack frame.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 16:23

Message:
Logged In: YES 
user_id=33168

I don't know.  I tried to come up with other test cases and
failed.
Tried __str__ and __getitem__.  Also tried new-style classes.

The problem was that the code bounced back and forth
between PyObject_Call() & instance_call() (mutual recursion).


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-07 16:08

Message:
Logged In: YES 
user_id=6380

Is this fix enough?  Aren't there lots of other ways to
generate the same error?  E.g. new-style classes (where this
particular example doesn't apply, but others might).

Or is this specific to instance_call?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 15:21

Message:
Logged In: YES 
user_id=33168

The attached patch stops the segfault and raises an exception:
TypeError: 'A' max recursion limit (100000) exceeded

I'm not sure if this is genarally applicable, or what a
reasonable # is.
100,000 was a guess and should probably be made a #def
w/comment.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-21 04:47

Message:
Logged In: NO 

>>> a=A() 
>>> a.foo 
foo 
__repr__ __call__ __call__ __call__ ... ad inf

This is normal behavior. The code at the top is buggy. The 
correct one is:

class A:
  def __getattr__(self, name):
    if name == '__repr__':
      return self.__repr__()
    print name
    return A()

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-20 17:10

Message:
Logged In: YES 
user_id=6380

This is buggy user code.

But the segfault should be fixed if possible.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470



From noreply@sourceforge.net  Fri Jun  7 21:35:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 07 Jun 2002 13:35:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-532646 ] Recursive class instance "error"
Message-ID: <E17GQRs-00008l-00@usw-sf-web3.sourceforge.net>

Bugs item #532646, was opened at 2002-03-20 13:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Gregor Mirai (gregmi)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Recursive class instance "error"

Initial Comment:
If one writes the following code (tested on Python  
2.1, 2.2 on platforms MacOS X Server, MacOS X, Windows 
98, NT, 2000) one can easily produce several "errors".

MacOS X, MacOS X Server (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name,
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
Segmentation fault

Win98, NT, 2000 (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
foo
__repr__ __call__ __call__ __call__ ... ad inf



----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 16:35

Message:
Logged In: YES 
user_id=33168

That sounds more reasonable.
I'll take a look and see if they can be integrated.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-07 16:27

Message:
Logged In: YES 
user_id=6380

Fair enough.  Ideally this should share the recursion_limit
variable from ceval.c and the recursion_depth field of the
stack frame.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 16:23

Message:
Logged In: YES 
user_id=33168

I don't know.  I tried to come up with other test cases and
failed.
Tried __str__ and __getitem__.  Also tried new-style classes.

The problem was that the code bounced back and forth
between PyObject_Call() & instance_call() (mutual recursion).


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-07 16:08

Message:
Logged In: YES 
user_id=6380

Is this fix enough?  Aren't there lots of other ways to
generate the same error?  E.g. new-style classes (where this
particular example doesn't apply, but others might).

Or is this specific to instance_call?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 15:21

Message:
Logged In: YES 
user_id=33168

The attached patch stops the segfault and raises an exception:
TypeError: 'A' max recursion limit (100000) exceeded

I'm not sure if this is genarally applicable, or what a
reasonable # is.
100,000 was a guess and should probably be made a #def
w/comment.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-21 04:47

Message:
Logged In: NO 

>>> a=A() 
>>> a.foo 
foo 
__repr__ __call__ __call__ __call__ ... ad inf

This is normal behavior. The code at the top is buggy. The 
correct one is:

class A:
  def __getattr__(self, name):
    if name == '__repr__':
      return self.__repr__()
    print name
    return A()

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-20 17:10

Message:
Logged In: YES 
user_id=6380

This is buggy user code.

But the segfault should be fixed if possible.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470



From noreply@sourceforge.net  Fri Jun  7 22:27:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 07 Jun 2002 14:27:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-565993 ] string.replace() can corrupt heap
Message-ID: <E17GRGm-0003fD-00@usw-sf-web1.sourceforge.net>

Bugs item #565993, was opened at 2002-06-07 15:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565993&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Romberg (romberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: string.replace() can corrupt heap

Initial Comment:
  I've been using a tool called mpatrol
(http://www.cbmamiga.demon.co.uk/mpatrol/) to cleanup an
embeded python application we have and ran into this
bug.  It seems to affect a stock python as well.  Under
certain
conditions it appears that one can get python to acess
freed
memory by calling string.replace or the string replace
method.

  Here is an example python command which reproduces
the problem:

python -c "a = 'a\000'; a.replace('\000', '')"

  The mpatrol library dumps the following logfile:

(see attachment)




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565993&group_id=5470



From noreply@sourceforge.net  Fri Jun  7 22:56:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 07 Jun 2002 14:56:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-566006 ] telnetlib makes Python dump core
Message-ID: <E17GRiz-0000ed-00@usw-sf-web2.sourceforge.net>

Bugs item #566006, was opened at 2002-06-07 23:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566006&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Rikard Bosnjakovic (bosna)
Assigned to: Nobody/Anonymous (nobody)
Summary: telnetlib makes Python dump core

Initial Comment:
I have a machine without network and it does not run 
DNS. It runs an irc-server, and when doing the 
following, Python crashes and dumps core:

>>> import telnetlib
>>> a = telnetlib.Telnet("localhost", 6667)
>>> dir(a)

(crash)

If i do /bin/telnet localhost 6667 it works fine, so the 
irc-server is not broken. Gdb gives me this backtrace:

(gdb) bt
#0  0x00000000 in ?? ()
#1  0x080bed79 in dict_dealloc (mp=0x815aef4) at 
Objects/dictobject.c:700
#2  0x080569ff in PyObject_Dir (arg=0x815cb0c) at 
Objects/object.c:1502
#3  0x080c405d in builtin_dir (self=0x0, 
args=0x8114f6c) at Python/bltinmodule.c:436
#4  0x080c0e4d in PyCFunction_Call 
(func=0x80f7c38, arg=0x8114f6c, kw=0x0)
    at Objects/methodobject.c:80
#5  0x08072ff3 in eval_frame (f=0x810a34c) at 
Python/ceval.c:1974
#6  0x08074002 in PyEval_EvalCodeEx 
(co=0x8142a68, globals=0x8104b7c, 
locals=0x8104b7c, 
    args=0x0, argcount=0, kws=0x0, kwcount=0, 
defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:2545
#7  0x08075f90 in PyEval_EvalCode 
(co=0x8142a68, globals=0x8104b7c, 
locals=0x8104b7c)
    at Python/ceval.c:482
#8  0x08091061 in run_node (n=0x8141878, 
filename=0x80c5795 "<stdin>", globals=0x8104b7c, 
    locals=0x8104b7c, flags=0xbffff8f4) at 
Python/pythonrun.c:1065
#9  0x0808f6c0 in PyRun_InteractiveOneFlags 
(fp=0x401672e0, filename=0x80c5795 "<stdin>", 
    flags=0xbffff8f4) at Python/pythonrun.c:579
#10 0x080909c1 in PyRun_InteractiveLoopFlags 
(fp=0x401672e0, filename=0x80c5795 "<stdin>", 
    flags=0xbffff8f4) at Python/pythonrun.c:515
#11 0x080907bb in PyRun_AnyFileExFlags 
(fp=0x401672e0, filename=0x80c5795 "<stdin>", 
    closeit=0, flags=0xbffff8f4) at 
Python/pythonrun.c:478
#12 0x08053022 in Py_Main (argc=2, 
argv=0xbffff984) at Modules/main.c:366
#13 0x080528ea in main (argc=2, argv=0xbffff984) 
at Modules/python.c:10
#14 0x4007b542 in __libc_start_main () 
from /lib/libc.so.6



The crash is reproducible. It crashes everytime I try 
the code above. Python 2.2, I have not been able to 
try it with a newer version.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566006&group_id=5470



From noreply@sourceforge.net  Fri Jun  7 23:52:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 07 Jun 2002 15:52:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-532646 ] Recursive class instance "error"
Message-ID: <E17GSbH-0000pj-00@usw-sf-web2.sourceforge.net>

Bugs item #532646, was opened at 2002-03-20 13:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Gregor Mirai (gregmi)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Recursive class instance "error"

Initial Comment:
If one writes the following code (tested on Python  
2.1, 2.2 on platforms MacOS X Server, MacOS X, Windows 
98, NT, 2000) one can easily produce several "errors".

MacOS X, MacOS X Server (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name,
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
Segmentation fault

Win98, NT, 2000 (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
foo
__repr__ __call__ __call__ __call__ ... ad inf



----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 18:52

Message:
Logged In: YES 
user_id=33168

The recursion fields are shared in the new patch.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 16:35

Message:
Logged In: YES 
user_id=33168

That sounds more reasonable.
I'll take a look and see if they can be integrated.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-07 16:27

Message:
Logged In: YES 
user_id=6380

Fair enough.  Ideally this should share the recursion_limit
variable from ceval.c and the recursion_depth field of the
stack frame.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 16:23

Message:
Logged In: YES 
user_id=33168

I don't know.  I tried to come up with other test cases and
failed.
Tried __str__ and __getitem__.  Also tried new-style classes.

The problem was that the code bounced back and forth
between PyObject_Call() & instance_call() (mutual recursion).


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-07 16:08

Message:
Logged In: YES 
user_id=6380

Is this fix enough?  Aren't there lots of other ways to
generate the same error?  E.g. new-style classes (where this
particular example doesn't apply, but others might).

Or is this specific to instance_call?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 15:21

Message:
Logged In: YES 
user_id=33168

The attached patch stops the segfault and raises an exception:
TypeError: 'A' max recursion limit (100000) exceeded

I'm not sure if this is genarally applicable, or what a
reasonable # is.
100,000 was a guess and should probably be made a #def
w/comment.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-21 04:47

Message:
Logged In: NO 

>>> a=A() 
>>> a.foo 
foo 
__repr__ __call__ __call__ __call__ ... ad inf

This is normal behavior. The code at the top is buggy. The 
correct one is:

class A:
  def __getattr__(self, name):
    if name == '__repr__':
      return self.__repr__()
    print name
    return A()

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-20 17:10

Message:
Logged In: YES 
user_id=6380

This is buggy user code.

But the segfault should be fixed if possible.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470



From noreply@sourceforge.net  Sat Jun  8 01:07:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 07 Jun 2002 17:07:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-566037 ] Popen exectuion blocking w/threads
Message-ID: <E17GTlZ-0000q7-00@usw-sf-web4.sourceforge.net>

Bugs item #566037, was opened at 2002-06-07 17:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566037&group_id=5470

Category: Threads
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Stoufer (mstoufer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Popen exectuion blocking w/threads

Initial Comment:
The following unit test hangs after the first two lines
of output. This is wholly reproducible (for us) under
2.2.1 and totaly unreproducible under 2.1. We have both
interpreters installed on a RH7.2 PC with linkings
against the apparent same /lib/libthread.so.0

import os, threading,time, sys
def read_output(self, cmd, timeout):
        print "run: %s" % cmd
        (inf,outf) = os.popen4(cmd)
        print "started! out_fd=%d" % outf.fileno()
        while 1:
            line = outf.readline()
            if line == "": break
            print len(line),line
            sys.stdout.flush()
        return
if __name__ == '__main__': 
    thr =
threading.Thread(target=read_output,args=(1,"ping -c 5
www.mit.edu",0))
    thr.start()
    print "Started thread"
    while 1: time.sleep(1)

mstoufer@dpsslx05(3)>ldd /usr/local/bin/python2.{1,2}
/usr/local/bin/python2.1:
	libpthread.so.0 => /lib/libpthread.so.0 (0x40029000)
	libdl.so.2 => /lib/libdl.so.2 (0x40040000)
	libutil.so.1 => /lib/libutil.so.1 (0x40044000)
	libstdc++-libc6.1-2.so.3 =>
/usr/local/lib/libstdc++-libc6.1-2.so.3 (0x40047000)
	libm.so.6 => /lib/libm.so.6 (0x4008f000)
	libc.so.6 => /lib/libc.so.6 (0x400b1000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
/usr/local/bin/python2.2:
	libdl.so.2 => /lib/libdl.so.2 (0x40029000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x4002d000)
	libutil.so.1 => /lib/libutil.so.1 (0x40044000)
	libm.so.6 => /lib/libm.so.6 (0x40047000)
	libc.so.6 => /lib/libc.so.6 (0x4006a000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566037&group_id=5470



From noreply@sourceforge.net  Sat Jun  8 02:57:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 07 Jun 2002 18:57:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-565993 ] string.replace() can corrupt heap
Message-ID: <E17GVTQ-0002bJ-00@usw-sf-web2.sourceforge.net>

Bugs item #565993, was opened at 2002-06-07 17:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565993&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Romberg (romberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: string.replace() can corrupt heap

Initial Comment:
  I've been using a tool called mpatrol
(http://www.cbmamiga.demon.co.uk/mpatrol/) to cleanup an
embeded python application we have and ran into this
bug.  It seems to affect a stock python as well.  Under
certain
conditions it appears that one can get python to acess
freed
memory by calling string.replace or the string replace
method.

  Here is an example python command which reproduces
the problem:

python -c "a = 'a\000'; a.replace('\000', '')"

  The mpatrol library dumps the following logfile:

(see attachment)




----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-06-07 21:57

Message:
Logged In: YES 
user_id=31435

When somebody gets a report from one of these tools, 
there are 3 possibilities:

1. It's a bug in Python.
2. It's a bug in the tool.
3. It's a bug in the platform C library, compiler, or OS.

Historical fact is that #2 is the most frequent outcome, and 
these usually burn lots of time to pin the blame, so you're 
going to have to do more work if you want this taken 
seriously.

I stepped through your test case under a debugger using 
2.2.1, and saw nothing wrong.  There's a memcpy with a 
length of 0 where your tool reports "a problem", but that's 
not an error, and the addresses passed at that point are to 
legitimate memory regardless.  It's possible that your 
platform C library optimizes memcpy under the covers by 
reading up more memory than was requested, but platform 
libraries are outside of Python's control, and platform 
library authors generally "cheat" in safe ways.

At the very least, can you get into a debugger and find 
some reason to believe there's a real problem here better 
than "some program said so"?  If not, I'm inclined to close 
this as a 3rd-party bug without burning more time on it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565993&group_id=5470



From noreply@sourceforge.net  Sat Jun  8 06:17:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 07 Jun 2002 22:17:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-558488 ] DL_EXPORT on VC7 broken
Message-ID: <E17GYba-00054t-00@usw-sf-web3.sourceforge.net>

Bugs item #558488, was opened at 2002-05-21 10:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: Later
Priority: 5
Submitted By: David Aldridge (daldridge)
Assigned to: Mark Hammond (mhammond)
Summary: DL_EXPORT on VC7 broken

Initial Comment:
Extension modules (_sre, _socket, etc.) do not have 
their entry points exported correctly when building 
Python (2.1 onwards) with Microsoft Visual C++ 7 
(part of Visual Studio .NET).  (NOTE: Everything 
compiles and links without errors.  It's just the 
exports that are missing.)

Think through the prepocessor flow when compiling 
_sre.c, for example, the following happens (this is 
from memory so please excuse inaccuracies):

1) _sre.c #includes "python.h"

2) "python.h" pretty much immediatly 
#includes "config.h"

3) "config.h" has the following:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

4) USE_DL_EXPORT is NOT defined (and cannot be in the 
_sre project, or it will not import pythoncore's (?) 
exports), thus DL_EXPORT is not yet defined.

5) After preprocessing "config.h", we're back 
in "python.h", which has a block:

#ifndef DL_EXPORT
#define DL_EXPORT(RTYPE) RTYPE
#endif

6) Back in _sre.c, the extension module entry point 
is:

DL_EXPORT(void) init_sre()

This expands to

void init_sre()

And thus does not get exported.



If I change the "config.h" block above to be:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

(ie. add the DL_EXPORT line if/when USE_DL_IMPORT is 
defined), everything works correctly.  Not 
guaranteeing this is the "correct" solution, but it 
seems to work.

My specific test case was to build everything, run 
python.exe from the command line, then 
attempt "import re".

This results in a Traceback with "ImportError: 
dynamic module does not define init function 
(init_sre)".


----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-06-08 15:17

Message:
Logged In: YES 
user_id=14198

A patch can be found at http://www.python.org/sf/566100

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-07 10:24

Message:
Logged In: YES 
user_id=31435

How about:

1. Write the new macros first, and check them in.  The old 
macros are still defined at this point.

2. Convert one module to use them, and check it in.

3. Post a brief "conversion guide" to Python-Dev.  This 
will also end up in somebody's 2.3 migration guide.

4. Let people have at it.  A little bit of this kind of 
editing is fun, mindless work, and I expect lots of people 
will do just a little bit of it.  We can clean up what's 
left.

5. When all uses have been converted, we "deprecate" the 
current macro set, and argue on Python-Dev about when they 
can go away.

It's easy if it's possible to make everyone feel guilty 
<wink>.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-06-07 10:07

Message:
Logged In: YES 
user_id=14198

OK Tim - how do we go about doing this?  I like the idea of
PyAPI_FUNC, PyAPI_DATA and PyMODINIT_FUNC - but there are
literally *hundreds* of places that need to be changed.

While the changes are largely mechanical, it will still have
a large impact.  Should we coordinate with other people that
this change is about to happen, or shall I just put together
a patch, we can check it in, and then go on vacation while
the shit hits the fan? <wink>

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-06 11:33

Message:
Logged In: YES 
user_id=31435

I didn't say they were a mess here.  It's unkind to criticize 
in public <wink>.  I really like your idea of purpose-oriented 
names.  How about PyAPI_FUNC and PyMODINIT_FUNC?  
Would it also be helpful to distinguish public API functions 
from public API data?  We have plenty of the latter too, and 
it's always surprised me that no platform has popped up 
that requires treating cross-blob data in a different way 
than cross-blob entry points.  But maybe that's because 
only Windows Geeks enjoy pleasant support for cross-blob 
stuff of any kind <0.9 wink>.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-06-06 10:57

Message:
Logged In: YES 
user_id=14198

Actually, the problem is simply that the "export:init_sre"
option was dropped from the *linker*.

USE_DL_EXPORT was a noop when not building the core.  Hence,
_sre used an explicit "export:" linker option, while _winreg
(for example) just used an explicit dlexport() statement in
the code (which it could safely do as it is Windows specific)

So I am not sure that closing it is the right thing to do. 
IMO, the right thing to do is to rationalize these DL_EXPORT
macros once and for all (and I can remove yet another bit of
my shame from the core Python tree <wink>)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-06 10:50

Message:
Logged In: YES 
user_id=6380

I guess the converter didn't save the CPP flags.  The V6
project defines these in the "settings" dialog:
NDEBUG,WIN32,_WINDOWS,USE_DL_EXPORT

If you say that USE_DL_EXPORT is not defined (point 4 above)
that means the converter (or something else :-) lost that.

I'll close this now.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-06-06 10:49

Message:
Logged In: YES 
user_id=14198

This is a mess <wink>.

MSVC6 works as the linker command line specifies
"/export:init_sre" on the commandline.  It appears that the
MSVC7 migration process does *not* migrate this option. 
Hence src does not export that symbol in MSVC7.  ie, this
confirms exactly what Tim says.

As Tim says, this DL_* stuff is a mess.  I think we simply
need 2 macros - one that says "this is a public Python API
function" and another that says "this is a Python module
init function".  I see no other requirements in the core.

I am attaching a patch that fixes the VC7 build problems,
but not "once and for all".  See the comments in the patch.
 I am not necessarily suggesting it be applied.

Tim - do you agree we really only have these 2 requirements
(public Python API vs Python module init function).?  If so,
how about we just decide on names, and take the hit now?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-06 10:21

Message:
Logged In: YES 
user_id=31435

Note that the MSVC project files we ship contain

/export:init_sre

in the linker options for the _sre project, so it doesn't 
matter whether the macros do anything in this project.  
Presumably VC7 screws this up, or the .dsp conversion 
dropped this linker flag on the floor.  MarkH and I promised 
ach other to rework this macro maze someday, but I 
haven't had time for it, and Mark hasn't either.  That's why 
I'm leaving it assigned to him <ahem>.

----------------------------------------------------------------------

Comment By: David Aldridge (daldridge)
Date: 2002-06-06 09:48

Message:
Logged In: YES 
user_id=550130

That's what I figured, too  (the "wouldn't work with VC6 either" 
comment, not the "because he's lonely" part ;-)

We were compiling/linking/using 2.1 with VC6 just fine -- no 
clue why it would be broken in VC7 (BTW, always using the 
GUI, never the cl.exe or msdev.exe/devenv.exe from the 
command line).  Perhaps the VC6->7 project converter hosed 
the .dsw/.dsps in some way, though the conversion seemed 
to work fine for all of our own stuff... *shrug*  I didn't think to 
do a visual comparison of the original .dsp's with the 
created .vcproj's (or workspace equivalents).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-06 05:40

Message:
Logged In: YES 
user_id=31435

Assigned to Mark because he's lonely <wink>.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-06 05:16

Message:
Logged In: YES 
user_id=6380

If you were right, it wouldn't build with VC6 either. But it does.

So what's wrong? I dunno. Asking Tim.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470



From noreply@sourceforge.net  Sat Jun  8 06:42:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 07 Jun 2002 22:42:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-566037 ] Popen exectuion blocking w/threads
Message-ID: <E17GYzp-0004Pu-00@usw-sf-web1.sourceforge.net>

Bugs item #566037, was opened at 2002-06-08 10:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566037&group_id=5470

Category: Threads
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Stoufer (mstoufer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Popen exectuion blocking w/threads

Initial Comment:
The following unit test hangs after the first two lines
of output. This is wholly reproducible (for us) under
2.2.1 and totaly unreproducible under 2.1. We have both
interpreters installed on a RH7.2 PC with linkings
against the apparent same /lib/libthread.so.0

import os, threading,time, sys
def read_output(self, cmd, timeout):
        print "run: %s" % cmd
        (inf,outf) = os.popen4(cmd)
        print "started! out_fd=%d" % outf.fileno()
        while 1:
            line = outf.readline()
            if line == "": break
            print len(line),line
            sys.stdout.flush()
        return
if __name__ == '__main__': 
    thr =
threading.Thread(target=read_output,args=(1,"ping -c 5
www.mit.edu",0))
    thr.start()
    print "Started thread"
    while 1: time.sleep(1)

mstoufer@dpsslx05(3)>ldd /usr/local/bin/python2.{1,2}
/usr/local/bin/python2.1:
	libpthread.so.0 => /lib/libpthread.so.0 (0x40029000)
	libdl.so.2 => /lib/libdl.so.2 (0x40040000)
	libutil.so.1 => /lib/libutil.so.1 (0x40044000)
	libstdc++-libc6.1-2.so.3 =>
/usr/local/lib/libstdc++-libc6.1-2.so.3 (0x40047000)
	libm.so.6 => /lib/libm.so.6 (0x4008f000)
	libc.so.6 => /lib/libc.so.6 (0x400b1000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
/usr/local/bin/python2.2:
	libdl.so.2 => /lib/libdl.so.2 (0x40029000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x4002d000)
	libutil.so.1 => /lib/libutil.so.1 (0x40044000)
	libm.so.6 => /lib/libm.so.6 (0x40047000)
	libc.so.6 => /lib/libc.so.6 (0x4006a000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-06-08 15:42

Message:
Logged In: YES 
user_id=14198

Just noting that current CVS Python works fine on Windows,
but also hangs on RH7.  My Linux debuggings skills are such
that I can offer no further help ;)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566037&group_id=5470



From noreply@sourceforge.net  Sat Jun  8 22:50:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 08 Jun 2002 14:50:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-566302 ] Bgen should generate 7-bit-clean code
Message-ID: <E17Go6G-0003ZC-00@usw-sf-web4.sourceforge.net>

Bugs item #566302, was opened at 2002-06-08 23:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566302&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Bgen should generate 7-bit-clean code

Initial Comment:
Bgen should generate 7-bit clean code by using hex escapes for non-ascii characters. This should circumvene the problem with MacRoman vs. Latin-1 conversion for files under CVS. The bad news is that this means bgen may need to parse the constant declarations, but maybe we can get away by just escaping all non-ascii chars (as they should only occur within either strings or comments in C header files anyway).

The same probably holds for gensuitemodule.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566302&group_id=5470



From noreply@sourceforge.net  Sun Jun  9 09:23:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 09 Jun 2002 01:23:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-566302 ] Bgen should generate 7-bit-clean code
Message-ID: <E17Gxyv-0002BQ-00@usw-sf-web1.sourceforge.net>

Bugs item #566302, was opened at 2002-06-08 23:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566302&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Bgen should generate 7-bit-clean code

Initial Comment:
Bgen should generate 7-bit clean code by using hex escapes for non-ascii characters. This should circumvene the problem with MacRoman vs. Latin-1 conversion for files under CVS. The bad news is that this means bgen may need to parse the constant declarations, but maybe we can get away by just escaping all non-ascii chars (as they should only occur within either strings or comments in C header files anyway).

The same probably holds for gensuitemodule.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 10:23

Message:
Logged In: YES 
user_id=21627

Can you give an example of code where it doesn't work
properly in this respect?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566302&group_id=5470



From noreply@sourceforge.net  Sun Jun  9 09:32:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 09 Jun 2002 01:32:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-566302 ] Bgen should generate 7-bit-clean code
Message-ID: <E17Gy7Z-0002Fz-00@usw-sf-web2.sourceforge.net>

Bugs item #566302, was opened at 2002-06-08 23:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566302&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Bgen should generate 7-bit-clean code

Initial Comment:
Bgen should generate 7-bit clean code by using hex escapes for non-ascii characters. This should circumvene the problem with MacRoman vs. Latin-1 conversion for files under CVS. The bad news is that this means bgen may need to parse the constant declarations, but maybe we can get away by just escaping all non-ascii chars (as they should only occur within either strings or comments in C header files anyway).

The same probably holds for gensuitemodule.

----------------------------------------------------------------------

>Comment By: Just van Rossum (jvr)
Date: 2002-06-09 10:32

Message:
Logged In: YES 
user_id=92689

It's not a question of "doesn't work" but more a question of brittleness: 
Mac CVS clients optionally do text file encoding conversion, but this 
means that everyone involved _have_ to use the same settings or things 
go wrong. It helps to keep source files 7-bit clean. Some .py files in the 
Mac subdirectory are currently not 7-bit clean, and some of these are 
generated by bgen. Hence this "bug".

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 10:23

Message:
Logged In: YES 
user_id=21627

Can you give an example of code where it doesn't work
properly in this respect?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566302&group_id=5470



From noreply@sourceforge.net  Sun Jun  9 09:32:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 09 Jun 2002 01:32:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-566037 ] Popen exectuion blocking w/threads
Message-ID: <E17Gy7l-0001K2-00@usw-sf-web4.sourceforge.net>

Bugs item #566037, was opened at 2002-06-08 02:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566037&group_id=5470

Category: Threads
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Stoufer (mstoufer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Popen exectuion blocking w/threads

Initial Comment:
The following unit test hangs after the first two lines
of output. This is wholly reproducible (for us) under
2.2.1 and totaly unreproducible under 2.1. We have both
interpreters installed on a RH7.2 PC with linkings
against the apparent same /lib/libthread.so.0

import os, threading,time, sys
def read_output(self, cmd, timeout):
        print "run: %s" % cmd
        (inf,outf) = os.popen4(cmd)
        print "started! out_fd=%d" % outf.fileno()
        while 1:
            line = outf.readline()
            if line == "": break
            print len(line),line
            sys.stdout.flush()
        return
if __name__ == '__main__': 
    thr =
threading.Thread(target=read_output,args=(1,"ping -c 5
www.mit.edu",0))
    thr.start()
    print "Started thread"
    while 1: time.sleep(1)

mstoufer@dpsslx05(3)>ldd /usr/local/bin/python2.{1,2}
/usr/local/bin/python2.1:
	libpthread.so.0 => /lib/libpthread.so.0 (0x40029000)
	libdl.so.2 => /lib/libdl.so.2 (0x40040000)
	libutil.so.1 => /lib/libutil.so.1 (0x40044000)
	libstdc++-libc6.1-2.so.3 =>
/usr/local/lib/libstdc++-libc6.1-2.so.3 (0x40047000)
	libm.so.6 => /lib/libm.so.6 (0x4008f000)
	libc.so.6 => /lib/libc.so.6 (0x400b1000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
/usr/local/bin/python2.2:
	libdl.so.2 => /lib/libdl.so.2 (0x40029000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x4002d000)
	libutil.so.1 => /lib/libutil.so.1 (0x40044000)
	libm.so.6 => /lib/libm.so.6 (0x40047000)
	libc.so.6 => /lib/libc.so.6 (0x4006a000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 10:32

Message:
Logged In: YES 
user_id=21627

I can't reproduce this on a SuSE system, either (which has
glibc 2.2.5), so I'm tempted to declare it a glibc 2.1 bug.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-06-08 07:42

Message:
Logged In: YES 
user_id=14198

Just noting that current CVS Python works fine on Windows,
but also hangs on RH7.  My Linux debuggings skills are such
that I can offer no further help ;)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566037&group_id=5470



From noreply@sourceforge.net  Sun Jun  9 09:35:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 09 Jun 2002 01:35:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-566006 ] telnetlib makes Python dump core
Message-ID: <E17GyB1-0001M7-00@usw-sf-web4.sourceforge.net>

Bugs item #566006, was opened at 2002-06-07 23:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566006&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Rikard Bosnjakovic (bosna)
Assigned to: Nobody/Anonymous (nobody)
Summary: telnetlib makes Python dump core

Initial Comment:
I have a machine without network and it does not run 
DNS. It runs an irc-server, and when doing the 
following, Python crashes and dumps core:

>>> import telnetlib
>>> a = telnetlib.Telnet("localhost", 6667)
>>> dir(a)

(crash)

If i do /bin/telnet localhost 6667 it works fine, so the 
irc-server is not broken. Gdb gives me this backtrace:

(gdb) bt
#0  0x00000000 in ?? ()
#1  0x080bed79 in dict_dealloc (mp=0x815aef4) at 
Objects/dictobject.c:700
#2  0x080569ff in PyObject_Dir (arg=0x815cb0c) at 
Objects/object.c:1502
#3  0x080c405d in builtin_dir (self=0x0, 
args=0x8114f6c) at Python/bltinmodule.c:436
#4  0x080c0e4d in PyCFunction_Call 
(func=0x80f7c38, arg=0x8114f6c, kw=0x0)
    at Objects/methodobject.c:80
#5  0x08072ff3 in eval_frame (f=0x810a34c) at 
Python/ceval.c:1974
#6  0x08074002 in PyEval_EvalCodeEx 
(co=0x8142a68, globals=0x8104b7c, 
locals=0x8104b7c, 
    args=0x0, argcount=0, kws=0x0, kwcount=0, 
defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:2545
#7  0x08075f90 in PyEval_EvalCode 
(co=0x8142a68, globals=0x8104b7c, 
locals=0x8104b7c)
    at Python/ceval.c:482
#8  0x08091061 in run_node (n=0x8141878, 
filename=0x80c5795 "<stdin>", globals=0x8104b7c, 
    locals=0x8104b7c, flags=0xbffff8f4) at 
Python/pythonrun.c:1065
#9  0x0808f6c0 in PyRun_InteractiveOneFlags 
(fp=0x401672e0, filename=0x80c5795 "<stdin>", 
    flags=0xbffff8f4) at Python/pythonrun.c:579
#10 0x080909c1 in PyRun_InteractiveLoopFlags 
(fp=0x401672e0, filename=0x80c5795 "<stdin>", 
    flags=0xbffff8f4) at Python/pythonrun.c:515
#11 0x080907bb in PyRun_AnyFileExFlags 
(fp=0x401672e0, filename=0x80c5795 "<stdin>", 
    closeit=0, flags=0xbffff8f4) at 
Python/pythonrun.c:478
#12 0x08053022 in Py_Main (argc=2, 
argv=0xbffff984) at Modules/main.c:366
#13 0x080528ea in main (argc=2, argv=0xbffff984) 
at Modules/python.c:10
#14 0x4007b542 in __libc_start_main () 
from /lib/libc.so.6



The crash is reproducible. It crashes everytime I try 
the code above. Python 2.2, I have not been able to 
try it with a newer version.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 10:35

Message:
Logged In: YES 
user_id=21627

What operating system? Does it fail for every port, or just
for the IRC port?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566006&group_id=5470



From noreply@sourceforge.net  Sun Jun  9 10:04:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 09 Jun 2002 02:04:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-565747 ] crash on gethostbyaddr
Message-ID: <E17GycV-0001dP-00@usw-sf-web4.sourceforge.net>

Bugs item #565747, was opened at 2002-06-07 12:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565747&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Joerg Beyer (jbeyer)
Assigned to: Martin v. Löwis (loewis)
Summary: crash on gethostbyaddr

Initial Comment:
if python is compiled with --disable-ipv6, AND the
host has ipv6 enabled. Then calling

python2.2 -c "import socket; print
socket.gethostbyaddr('::0')"

you get a

Segmentation fault

This is caused by Python copying the V6 information
returned by the OS into the V4 struct of Python.See the
attached diff for socketmodule.c for a fix.

Alternatively, one could move the memcpy at the end of
setipaddr() into the switch, so that if the system
returns "unknown address family", the invalid copy is
not executed.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 11:04

Message:
Logged In: YES 
user_id=21627

Jürgen, can you please try the attached sock.diff? This is a
slightly corrected version of Jörg's patch (IMO). I could
not observe the problem you've seen with Jörg's patch on a
SuSE 8.0 installation.

As for IPv6 not working on a SuSE 7.0 system: This is very
possible. Python requires the RFC2553 API, it might be that
this was not available in the glibc version that shipped
with SuSE 7.0.

----------------------------------------------------------------------

Comment By: Jürgen Hermann (jhermann)
Date: 2002-06-07 16:24

Message:
Logged In: YES 
user_id=39128

We found out a little more: after applying the fix, we get
"unsupported address family" exceptions for IPV6 addresses,
but also we cannot open sockets any more ("could not
connect" exceptions by urllib for any URL). So the fix is
not complete. BTW, the bug appears with Python 2.2, Python
2.0 and 2.1 _do_ work on the same machine.

Another piece of information: we tried to --enable-ipv6 on
that machine (SuSE 7.0, gcc 2.9.95), and got this:

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I./Include -DHAVE_CONFIG_H
-DUSE_SSL -I/netsite/include -I/netsite/include/openssl -c
./Modules/socketmodul

./Modules/socketmodule.c: In function `makesockaddr':
./Modules/socketmodule.c:733: structure has no member named
`sin6_scope_id'
./Modules/socketmodule.c: In function `getsockaddrarg':
./Modules/socketmodule.c:846: structure has no member named
`sin6_scope_id'
./Modules/socketmodule.c: In function `PySocket_getnameinfo':
./Modules/socketmodule.c:2598: structure has no member named
`sin6_scope_id'
make: *** [Modules/socketmodule.o] Error 1 

Don't know whether that is SuSE 7.0's fault.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565747&group_id=5470



From noreply@sourceforge.net  Sun Jun  9 10:09:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 09 Jun 2002 02:09:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-566302 ] Bgen should generate 7-bit-clean code
Message-ID: <E17GyhA-0002cV-00@usw-sf-web2.sourceforge.net>

Bugs item #566302, was opened at 2002-06-08 23:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566302&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Bgen should generate 7-bit-clean code

Initial Comment:
Bgen should generate 7-bit clean code by using hex escapes for non-ascii characters. This should circumvene the problem with MacRoman vs. Latin-1 conversion for files under CVS. The bad news is that this means bgen may need to parse the constant declarations, but maybe we can get away by just escaping all non-ascii chars (as they should only occur within either strings or comments in C header files anyway).

The same probably holds for gensuitemodule.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 11:09

Message:
Logged In: YES 
user_id=21627

I think I understand the issue of using 7-bit clean source
code. I'm still trying to understand the bgen issue: why
would it ever produce output that is not 7-bit-clean?
(again, with examples please).

I would assume that the input is already in error, in such a
case.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-06-09 10:32

Message:
Logged In: YES 
user_id=92689

It's not a question of "doesn't work" but more a question of brittleness: 
Mac CVS clients optionally do text file encoding conversion, but this 
means that everyone involved _have_ to use the same settings or things 
go wrong. It helps to keep source files 7-bit clean. Some .py files in the 
Mac subdirectory are currently not 7-bit clean, and some of these are 
generated by bgen. Hence this "bug".

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 10:23

Message:
Logged In: YES 
user_id=21627

Can you give an example of code where it doesn't work
properly in this respect?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566302&group_id=5470



From noreply@sourceforge.net  Sun Jun  9 10:10:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 09 Jun 2002 02:10:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-554676 ] unknown locale de_DE@euro on Suse 8.0 Linux
Message-ID: <E17Gyik-0002da-00@usw-sf-web2.sourceforge.net>

Bugs item #554676, was opened at 2002-05-10 23:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=554676&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: vincent wehren (vinweh)
Assigned to: Nobody/Anonymous (nobody)
Summary: unknown locale de_DE@euro on Suse 8.0 Linux

Initial Comment:
Python 2.2 (#1, Mar 26 2002, 15:46:04)   
[GCC 2.95.3 20010315 (SuSE)] on linux2   
 
When calling the locale module's getdefaultlocale() 
method on SuSe 8.0 Linux you get:   
 
>>> locale.getdefaultlocale()   
Traceback (most recent call last):   
  File "<stdin>", line 1, in ?   
  File "/usr/lib/python2.2/locale.py", line 337, in   
getdefaultlocale   
    return _parse_localename(localename)   
  File "/usr/lib/python2.2/locale.py", line 271, in   
_parse_localename   
    raise ValueError, 'unknown locale: %s' %   
localename   
ValueError: unknown locale: de_DE@euro   
  
Evidently, Python2.2's locale module is unaware of 
the "somelang_SOMELANG@euro" nomenclature  
for euro-enabled locales on Linux.  
  
 

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 11:10

Message:
Logged In: YES 
user_id=21627

Can you please explain what you need getdefaultlocale for?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=554676&group_id=5470



From noreply@sourceforge.net  Sun Jun  9 10:15:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 09 Jun 2002 02:15:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-566302 ] Bgen should generate 7-bit-clean code
Message-ID: <E17Gynj-0002gp-00@usw-sf-web2.sourceforge.net>

Bugs item #566302, was opened at 2002-06-08 23:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566302&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Bgen should generate 7-bit-clean code

Initial Comment:
Bgen should generate 7-bit clean code by using hex escapes for non-ascii characters. This should circumvene the problem with MacRoman vs. Latin-1 conversion for files under CVS. The bad news is that this means bgen may need to parse the constant declarations, but maybe we can get away by just escaping all non-ascii chars (as they should only occur within either strings or comments in C header files anyway).

The same probably holds for gensuitemodule.

----------------------------------------------------------------------

>Comment By: Just van Rossum (jvr)
Date: 2002-06-09 11:15

Message:
Logged In: YES 
user_id=92689

*sigh* Do you know what bgen does? It parses C header files. For 
certain constant definitions it translates C to Python in a fairly simplistic 
way. Any 8-bit char in the C source was passed directly to the .py files. 
And yes, some Mac headers contain 8 bit chars in string constants. 
Revision 1.28 of Tools/bgen/bgen/scantools.py,v fixes this. I'll leave the 
bug open until it's more thoroughly tested.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 11:09

Message:
Logged In: YES 
user_id=21627

I think I understand the issue of using 7-bit clean source
code. I'm still trying to understand the bgen issue: why
would it ever produce output that is not 7-bit-clean?
(again, with examples please).

I would assume that the input is already in error, in such a
case.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-06-09 10:32

Message:
Logged In: YES 
user_id=92689

It's not a question of "doesn't work" but more a question of brittleness: 
Mac CVS clients optionally do text file encoding conversion, but this 
means that everyone involved _have_ to use the same settings or things 
go wrong. It helps to keep source files 7-bit clean. Some .py files in the 
Mac subdirectory are currently not 7-bit clean, and some of these are 
generated by bgen. Hence this "bug".

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 10:23

Message:
Logged In: YES 
user_id=21627

Can you give an example of code where it doesn't work
properly in this respect?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566302&group_id=5470



From noreply@sourceforge.net  Sun Jun  9 11:51:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 09 Jun 2002 03:51:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-566302 ] Bgen should generate 7-bit-clean code
Message-ID: <E17H0I7-0004BE-00@usw-sf-web3.sourceforge.net>

Bugs item #566302, was opened at 2002-06-08 23:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566302&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Bgen should generate 7-bit-clean code

Initial Comment:
Bgen should generate 7-bit clean code by using hex escapes for non-ascii characters. This should circumvene the problem with MacRoman vs. Latin-1 conversion for files under CVS. The bad news is that this means bgen may need to parse the constant declarations, but maybe we can get away by just escaping all non-ascii chars (as they should only occur within either strings or comments in C header files anyway).

The same probably holds for gensuitemodule.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 12:51

Message:
Logged In: YES 
user_id=21627

That is precisely my question. Could you pass a copy of a
file that was used as input to bgen and shows this problem
(if for no other reason than to satisfy my curiosity)?

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-06-09 11:15

Message:
Logged In: YES 
user_id=92689

*sigh* Do you know what bgen does? It parses C header files. For 
certain constant definitions it translates C to Python in a fairly simplistic 
way. Any 8-bit char in the C source was passed directly to the .py files. 
And yes, some Mac headers contain 8 bit chars in string constants. 
Revision 1.28 of Tools/bgen/bgen/scantools.py,v fixes this. I'll leave the 
bug open until it's more thoroughly tested.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 11:09

Message:
Logged In: YES 
user_id=21627

I think I understand the issue of using 7-bit clean source
code. I'm still trying to understand the bgen issue: why
would it ever produce output that is not 7-bit-clean?
(again, with examples please).

I would assume that the input is already in error, in such a
case.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-06-09 10:32

Message:
Logged In: YES 
user_id=92689

It's not a question of "doesn't work" but more a question of brittleness: 
Mac CVS clients optionally do text file encoding conversion, but this 
means that everyone involved _have_ to use the same settings or things 
go wrong. It helps to keep source files 7-bit clean. Some .py files in the 
Mac subdirectory are currently not 7-bit clean, and some of these are 
generated by bgen. Hence this "bug".

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 10:23

Message:
Logged In: YES 
user_id=21627

Can you give an example of code where it doesn't work
properly in this respect?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566302&group_id=5470



From noreply@sourceforge.net  Sun Jun  9 12:34:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 09 Jun 2002 04:34:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-565747 ] crash on gethostbyaddr
Message-ID: <E17H0xm-0004sM-00@usw-sf-web4.sourceforge.net>

Bugs item #565747, was opened at 2002-06-07 12:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565747&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Joerg Beyer (jbeyer)
Assigned to: Martin v. Löwis (loewis)
Summary: crash on gethostbyaddr

Initial Comment:
if python is compiled with --disable-ipv6, AND the
host has ipv6 enabled. Then calling

python2.2 -c "import socket; print
socket.gethostbyaddr('::0')"

you get a

Segmentation fault

This is caused by Python copying the V6 information
returned by the OS into the V4 struct of Python.See the
attached diff for socketmodule.c for a fix.

Alternatively, one could move the memcpy at the end of
setipaddr() into the switch, so that if the system
returns "unknown address family", the invalid copy is
not executed.

----------------------------------------------------------------------

Comment By: Jürgen Hermann (jhermann)
Date: 2002-06-09 13:34

Message:
Logged In: YES 
user_id=39128

Martin,  the attachment didn't make it to the system, it seems.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 11:04

Message:
Logged In: YES 
user_id=21627

Jürgen, can you please try the attached sock.diff? This is a
slightly corrected version of Jörg's patch (IMO). I could
not observe the problem you've seen with Jörg's patch on a
SuSE 8.0 installation.

As for IPv6 not working on a SuSE 7.0 system: This is very
possible. Python requires the RFC2553 API, it might be that
this was not available in the glibc version that shipped
with SuSE 7.0.

----------------------------------------------------------------------

Comment By: Jürgen Hermann (jhermann)
Date: 2002-06-07 16:24

Message:
Logged In: YES 
user_id=39128

We found out a little more: after applying the fix, we get
"unsupported address family" exceptions for IPV6 addresses,
but also we cannot open sockets any more ("could not
connect" exceptions by urllib for any URL). So the fix is
not complete. BTW, the bug appears with Python 2.2, Python
2.0 and 2.1 _do_ work on the same machine.

Another piece of information: we tried to --enable-ipv6 on
that machine (SuSE 7.0, gcc 2.9.95), and got this:

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I./Include -DHAVE_CONFIG_H
-DUSE_SSL -I/netsite/include -I/netsite/include/openssl -c
./Modules/socketmodul

./Modules/socketmodule.c: In function `makesockaddr':
./Modules/socketmodule.c:733: structure has no member named
`sin6_scope_id'
./Modules/socketmodule.c: In function `getsockaddrarg':
./Modules/socketmodule.c:846: structure has no member named
`sin6_scope_id'
./Modules/socketmodule.c: In function `PySocket_getnameinfo':
./Modules/socketmodule.c:2598: structure has no member named
`sin6_scope_id'
make: *** [Modules/socketmodule.o] Error 1 

Don't know whether that is SuSE 7.0's fault.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565747&group_id=5470



From noreply@sourceforge.net  Sun Jun  9 18:14:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 09 Jun 2002 10:14:38 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-558238 ] Pickling bound methods
Message-ID: <E17H6H0-000896-00@usw-sf-web2.sourceforge.net>

Feature Requests item #558238, was opened at 2002-05-20 13:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=558238&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Konrad Hinsen (hinsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pickling bound methods

Initial Comment:
Last week I noticed that the pickle and cPickle modules
cannot handle bound methods. I found a solution that is
simple and (I think) general, so perhaps it should
become part of the standard library.

Here is my code:

import copy_reg

def pickle_bound_method(method):
    return getattr, (method.im_self, method.__name__)

class _Foo:
    def bar(self):
        pass

_foo = _Foo()

copy_reg.constructor(getattr)
copy_reg.pickle(type(_foo.bar), pickle_bound_method)



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 19:14

Message:
Logged In: YES 
user_id=21627

Making getattr a safe_constructor has security implictions
which make this approach dangerous. It seems that unpickling
might invoke arbitrary __getattr__ implementations. Adding a
protocol to declare classes as "safe for getattr" might help.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=558238&group_id=5470



From noreply@sourceforge.net  Sun Jun  9 18:18:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 09 Jun 2002 10:18:24 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-539907 ] Tkinter lock conflicts extension widgets
Message-ID: <E17H6Ke-0007IX-00@usw-sf-web4.sourceforge.net>

Feature Requests item #539907, was opened at 2002-04-05 20:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=539907&group_id=5470

Category: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jyrki Alakuijala (jyrkialakuijala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tkinter lock conflicts extension widgets

Initial Comment:
I need to access the thread lock in the _tkinter.c.

I have the following callgraph:
1) Python code
2) Tcl/Tk event loop (tkinter mainloop->)
3) Mouse callback to my own Tk extension widget
4) A lot of C++ stuff, which is also called directly
   from python
5) Python
6) Calling tk (which crashes due to the tk lock)

It is be possible to avoid this by creating a
tcl event with a python callback instead of calling
c++ from the tk extension widget. However, in a
painting program this is not ok for performance.
The real time capabilities of Python are pretty
bad and mouse movement becomes stopped for a few
milliseconds every now and then, leaving significant
discontinuities in the mouse tracking.

I have been able to have excellent behavior by
exposing the thread lock of _tkinter.c and release
the tk-lock when the call from the widget enters
the C++ side and lock it again when the C++ side
returns.

However, this is not possible with the standard
_tkinter.c, because the lock is a static member.
There are two possible solutions that would fix
my problems:

1) real-time python mode, that allows for turning
off GC and all other possible delays in the
interpreter. Then I could use the python for
managing tk events without mouse jumps.

2) exposing the thread lock with a simple api that
allows the use of LEAVE_TCL and ENTER_TCL outside
_tkinter.

The 2) is simpler. It consists of removing a keyword
"static" in _tkinter.c, while real-time python
is probably a 3.0 thing? Thus I would vote for a
fix in _tkinter.c for allowing me not to compile
my own python.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 19:18

Message:
Logged In: YES 
user_id=21627

Just removing the static on the lock is not sufficient, if
_tkinter.so is a shared library. Instead, providing a
CObject in _tkinter would help.

Would you like to produce a patch for that?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=539907&group_id=5470



From noreply@sourceforge.net  Sun Jun  9 18:25:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 09 Jun 2002 10:25:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-221208 ] Advanced email module
Message-ID: <E17H6RI-00086l-00@usw-sf-web1.sourceforge.net>

Bugs item #221208, was opened at 2000-11-03 14:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=221208&group_id=5470

Category: Extension Modules
Group: Feature Request
Status: Closed
Resolution: None
Priority: 5
Submitted By: Dirk Holtwick (holtwick)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Advanced email module

Initial Comment:
A nice new module to have would be a mime enabled email composer. I posted a sample to SourceForge that is still very basic:

http://sourceforge.net/snippet/detail.php?type=snippet&id=100444

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 19:25

Message:
Logged In: YES 
user_id=21627

Is this covered by the email pacakge?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-12-13 17:19

Message:
I've added this feature request to PEP 42.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-11-03 21:49

Message:
Hey, I didn't know about the SD "Snippet" feature! Cool!

But I'm not sure that this should be a standard library -- it's pretty application specific. Any other opinions?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=221208&group_id=5470



From noreply@sourceforge.net  Sun Jun  9 20:40:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 09 Jun 2002 12:40:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-566302 ] Bgen should generate 7-bit-clean code
Message-ID: <E17H8Xt-00017O-00@usw-sf-web1.sourceforge.net>

Bugs item #566302, was opened at 2002-06-08 23:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566302&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Bgen should generate 7-bit-clean code

Initial Comment:
Bgen should generate 7-bit clean code by using hex escapes for non-ascii characters. This should circumvene the problem with MacRoman vs. Latin-1 conversion for files under CVS. The bad news is that this means bgen may need to parse the constant declarations, but maybe we can get away by just escaping all non-ascii chars (as they should only occur within either strings or comments in C header files anyway).

The same probably holds for gensuitemodule.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-06-09 21:40

Message:
Logged In: YES 
user_id=45365

The problem is mainly with MacOS "OSType" style values. OSType values are 32 bit longs, but they are customarily encoded as 4-char character constants (a rather obscure feature of C). These OSType values are ubiquitous in MacOS: creator and file type for files ('APPL' is the filetype for an executable, 'Pyth' is the creator code for MacPython), resource types ('DLOG' for dialog resources), AppleEvent/Open Scripting event type and subtype (send 'core'/'odoc' to open a document), etc etc etc.

Example of an OSType value that occur within the Python core is 'GU
I' (that's a Sigma there) for a resource that influences the I/O behaviour of the GUSI library. And all code that is generated by gensuitemodule or bgen will also contain lots of them.

Especially the Python code generated is error-prone as it may be used both by MacPython and MachoPython. This isn't true for core usage (which is MacPython-only, as far as I am aware).

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 12:51

Message:
Logged In: YES 
user_id=21627

That is precisely my question. Could you pass a copy of a
file that was used as input to bgen and shows this problem
(if for no other reason than to satisfy my curiosity)?

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-06-09 11:15

Message:
Logged In: YES 
user_id=92689

*sigh* Do you know what bgen does? It parses C header files. For 
certain constant definitions it translates C to Python in a fairly simplistic 
way. Any 8-bit char in the C source was passed directly to the .py files. 
And yes, some Mac headers contain 8 bit chars in string constants. 
Revision 1.28 of Tools/bgen/bgen/scantools.py,v fixes this. I'll leave the 
bug open until it's more thoroughly tested.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 11:09

Message:
Logged In: YES 
user_id=21627

I think I understand the issue of using 7-bit clean source
code. I'm still trying to understand the bgen issue: why
would it ever produce output that is not 7-bit-clean?
(again, with examples please).

I would assume that the input is already in error, in such a
case.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-06-09 10:32

Message:
Logged In: YES 
user_id=92689

It's not a question of "doesn't work" but more a question of brittleness: 
Mac CVS clients optionally do text file encoding conversion, but this 
means that everyone involved _have_ to use the same settings or things 
go wrong. It helps to keep source files 7-bit clean. Some .py files in the 
Mac subdirectory are currently not 7-bit clean, and some of these are 
generated by bgen. Hence this "bug".

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 10:23

Message:
Logged In: YES 
user_id=21627

Can you give an example of code where it doesn't work
properly in this respect?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566302&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 01:18:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 09 Jun 2002 17:18:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-551412 ] possible to fail to calc mro's
Message-ID: <E17HCtB-0004nd-00@usw-sf-web3.sourceforge.net>

Bugs item #551412, was opened at 2002-05-02 09:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551412&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Open
Resolution: Fixed
>Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Guido van Rossum (gvanrossum)
Summary: possible to fail to calc mro's

Initial Comment:
This only crashes on the release22-maint branch, and
only when coredump is true:

class UserLong(object):
    def __pow__(self, *args):
        pass

coredump = 1

if not coredump:
   int.__mro__

pow(0, UserLong(), 0)

It's the type of the first argument to pow() that's
relavent: if you change it to "pow(0L, UserLong(), 0)"
you then have to change "int.__mro__" to "long.__mro__"
to avoid the crash.

Maybe it was the "typeobject.c refactoring" patch that
accidentally fixed this on the trunk?

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-09 20:18

Message:
Logged In: YES 
user_id=6380

I'm reopening this (as a reminder to myself). Calling
PyType_Ready() from _PyType_Lookup() is fishy. It may be
that the real problem is in slot_nb_power(), which tries to
call self.__pow__(other, modulus) without checking that
self...nb_power is inseed slot_nb_power.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-03 15:55

Message:
Logged In: YES 
user_id=6380

OK, fixed that too in 2.2.x and in 2.3, by calling
PyErr_Clear().  Not ideal, but not bad either.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 17:46

Message:
Logged In: YES 
user_id=6380

Argh, reopening.

There's one little detail left:
_PyType_Lookup() promises not
to set an exception.  If the call
to PyType_Ready() fails, this
promise is broken...

What to do?  PyErr_Clear()
and return NULL comes to mind...

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 17:42

Message:
Logged In: YES 
user_id=6380

OK, I nailed it.

The fix is to call PyType_Ready()
in _PyType_Lookup() when mro is NULL.

Fixed in both 2.3 and 2.2.
A test case added only for 2.3.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 17:20

Message:
Logged In: YES 
user_id=6380

In fact, this still crashes in 2.2:
pow(0L, UserLong(), 0L)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 17:10

Message:
Logged In: YES 
user_id=6380

Hm, this is serious.

This can happen whenever a built-in type
isn't initialized by PyType_Ready() yet,
and for many that is pretty common.
(The call to int.__mro__ goes through
type_getattro which calls PyType_Ready().)

I'm not sure which refactoring patch
you are referring to, and I'm actually
not at all sure that this can't happen
in 2.3 (despite the fact that this
particular example doesn't core dump there).

I'll investigate more...


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551412&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 01:25:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 09 Jun 2002 17:25:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-566631 ] PyUnicode_Find() returns wrong results
Message-ID: <E17HCzd-0004Hj-00@usw-sf-web2.sourceforge.net>

Bugs item #566631, was opened at 2002-06-09 20:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566631&group_id=5470

Category: Unicode
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: M.-A. Lemburg (lemburg)
Summary: PyUnicode_Find() returns wrong results

Initial Comment:
The following is used to search for u'h' inside
the string u'+#&.' (stored in self->seperator)

static PyObject *
Splitter_test(Splitter *self) {
    PyObject *test, *res, *word;

    test = Py_BuildValue("s","h");
    word =
PyUnicode_FromEncodedObject(test,"ascii","strict");

    printf("seperator: ");
    PyObject_Print(self->seperator, stdout, 0);
    puts("");

    printf("Searching for: ");
    PyObject_Print(word, stdout, 0);
    puts("");

    res = PyUnicode_Find(self->seperator, word, 0,
PyUnicode_GET_SIZE(self->seperator), 1);
    if (res==0) puts("not found");
    else puts("found");

}

The output is: 

yetix(366)% python2.1 test.py
seperator: u'+#&.'
Searching for: u'h'
found

So PyUnicode_Find() returns a match although
u'h' is not contained within self->seperator.

Env: Linux 2.4, Python 2.1.3





----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566631&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 01:58:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 09 Jun 2002 17:58:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-221208 ] Advanced email module
Message-ID: <E17HDVv-0005Dd-00@usw-sf-web3.sourceforge.net>

Bugs item #221208, was opened at 2000-11-03 08:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=221208&group_id=5470

Category: Extension Modules
Group: Feature Request
Status: Closed
Resolution: None
Priority: 5
Submitted By: Dirk Holtwick (holtwick)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Advanced email module

Initial Comment:
A nice new module to have would be a mime enabled email composer. I posted a sample to SourceForge that is still very basic:

http://sourceforge.net/snippet/detail.php?type=snippet&id=100444

----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-06-09 20:58

Message:
Logged In: YES 
user_id=12800

Basically, yes, although email doesn't do any actually
sending (you'd pump email's output through sendmail for
that).  The APIs are different, but I think email's is more
general.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 13:25

Message:
Logged In: YES 
user_id=21627

Is this covered by the email pacakge?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-12-13 11:19

Message:
I've added this feature request to PEP 42.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-11-03 15:49

Message:
Hey, I didn't know about the SD "Snippet" feature! Cool!

But I'm not sure that this should be a standard library -- it's pretty application specific. Any other opinions?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=221208&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 10:17:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 02:17:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-566631 ] PyUnicode_Find() returns wrong results
Message-ID: <E17HLIq-0001PE-00@usw-sf-web1.sourceforge.net>

Bugs item #566631, was opened at 2002-06-10 00:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566631&group_id=5470

Category: Unicode
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: M.-A. Lemburg (lemburg)
Summary: PyUnicode_Find() returns wrong results

Initial Comment:
The following is used to search for u'h' inside
the string u'+#&.' (stored in self->seperator)

static PyObject *
Splitter_test(Splitter *self) {
    PyObject *test, *res, *word;

    test = Py_BuildValue("s","h");
    word =
PyUnicode_FromEncodedObject(test,"ascii","strict");

    printf("seperator: ");
    PyObject_Print(self->seperator, stdout, 0);
    puts("");

    printf("Searching for: ");
    PyObject_Print(word, stdout, 0);
    puts("");

    res = PyUnicode_Find(self->seperator, word, 0,
PyUnicode_GET_SIZE(self->seperator), 1);
    if (res==0) puts("not found");
    else puts("found");

}

The output is: 

yetix(366)% python2.1 test.py
seperator: u'+#&.'
Searching for: u'h'
found

So PyUnicode_Find() returns a match although
u'h' is not contained within self->seperator.

Env: Linux 2.4, Python 2.1.3





----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-10 09:17

Message:
Logged In: YES 
user_id=38388

You should check what res actually is rather then doing
the check for == 0. Note that res == -1 means
"not found", res == 0 maps to: match found at position
0.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566631&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 11:45:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 03:45:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-566631 ] PyUnicode_Find() returns wrong results
Message-ID: <E17HMfw-0001Ts-00@usw-sf-web4.sourceforge.net>

Bugs item #566631, was opened at 2002-06-09 20:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566631&group_id=5470

Category: Unicode
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: M.-A. Lemburg (lemburg)
Summary: PyUnicode_Find() returns wrong results

Initial Comment:
The following is used to search for u'h' inside
the string u'+#&.' (stored in self->seperator)

static PyObject *
Splitter_test(Splitter *self) {
    PyObject *test, *res, *word;

    test = Py_BuildValue("s","h");
    word =
PyUnicode_FromEncodedObject(test,"ascii","strict");

    printf("seperator: ");
    PyObject_Print(self->seperator, stdout, 0);
    puts("");

    printf("Searching for: ");
    PyObject_Print(word, stdout, 0);
    puts("");

    res = PyUnicode_Find(self->seperator, word, 0,
PyUnicode_GET_SIZE(self->seperator), 1);
    if (res==0) puts("not found");
    else puts("found");

}

The output is: 

yetix(366)% python2.1 test.py
seperator: u'+#&.'
Searching for: u'h'
found

So PyUnicode_Find() returns a match although
u'h' is not contained within self->seperator.

Env: Linux 2.4, Python 2.1.3





----------------------------------------------------------------------

>Comment By: Andreas Jung (ajung)
Date: 2002-06-10 06:45

Message:
Logged In: YES 
user_id=11084

So what does PyUnicode_Find() return?

>From the docs:
PyObject* PyUnicode_Find(PyObject *str, PyObject *substr,
int start, int end, int direction)
    Return value: New reference.
Return the first position of substr in str[start:end] using
the given direction (direction == 1 means to do a forward
search, direction == -1 a backward search), 0 otherwise. 

Does it return an int with the position or a PyObject * ?

-aj

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-10 05:17

Message:
Logged In: YES 
user_id=38388

You should check what res actually is rather then doing
the check for == 0. Note that res == -1 means
"not found", res == 0 maps to: match found at position
0.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566631&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 11:48:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 03:48:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-566631 ] PyUnicode_Find() returns wrong results
Message-ID: <E17HMix-0002Rt-00@usw-sf-web1.sourceforge.net>

Bugs item #566631, was opened at 2002-06-09 20:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566631&group_id=5470

Category: Unicode
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: M.-A. Lemburg (lemburg)
Summary: PyUnicode_Find() returns wrong results

Initial Comment:
The following is used to search for u'h' inside
the string u'+#&.' (stored in self->seperator)

static PyObject *
Splitter_test(Splitter *self) {
    PyObject *test, *res, *word;

    test = Py_BuildValue("s","h");
    word =
PyUnicode_FromEncodedObject(test,"ascii","strict");

    printf("seperator: ");
    PyObject_Print(self->seperator, stdout, 0);
    puts("");

    printf("Searching for: ");
    PyObject_Print(word, stdout, 0);
    puts("");

    res = PyUnicode_Find(self->seperator, word, 0,
PyUnicode_GET_SIZE(self->seperator), 1);
    if (res==0) puts("not found");
    else puts("found");

}

The output is: 

yetix(366)% python2.1 test.py
seperator: u'+#&.'
Searching for: u'h'
found

So PyUnicode_Find() returns a match although
u'h' is not contained within self->seperator.

Env: Linux 2.4, Python 2.1.3





----------------------------------------------------------------------

>Comment By: Andreas Jung (ajung)
Date: 2002-06-10 06:48

Message:
Logged In: YES 
user_id=11084

Looking it the source, it is a documentation bug since 
PyUnicode_Find()  really returns int. 

Can you assign this issue to Fred to fix the docs *wink*?

-aj

----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2002-06-10 06:45

Message:
Logged In: YES 
user_id=11084

So what does PyUnicode_Find() return?

>From the docs:
PyObject* PyUnicode_Find(PyObject *str, PyObject *substr,
int start, int end, int direction)
    Return value: New reference.
Return the first position of substr in str[start:end] using
the given direction (direction == 1 means to do a forward
search, direction == -1 a backward search), 0 otherwise. 

Does it return an int with the position or a PyObject * ?

-aj

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-10 05:17

Message:
Logged In: YES 
user_id=38388

You should check what res actually is rather then doing
the check for == 0. Note that res == -1 means
"not found", res == 0 maps to: match found at position
0.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566631&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 11:52:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 03:52:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-566631 ] PyUnicode_Find() returns wrong results
Message-ID: <E17HMn5-0003Dy-00@usw-sf-web3.sourceforge.net>

Bugs item #566631, was opened at 2002-06-09 20:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566631&group_id=5470

Category: Unicode
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Jung (ajung)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: PyUnicode_Find() returns wrong results

Initial Comment:
The following is used to search for u'h' inside
the string u'+#&.' (stored in self->seperator)

static PyObject *
Splitter_test(Splitter *self) {
    PyObject *test, *res, *word;

    test = Py_BuildValue("s","h");
    word =
PyUnicode_FromEncodedObject(test,"ascii","strict");

    printf("seperator: ");
    PyObject_Print(self->seperator, stdout, 0);
    puts("");

    printf("Searching for: ");
    PyObject_Print(word, stdout, 0);
    puts("");

    res = PyUnicode_Find(self->seperator, word, 0,
PyUnicode_GET_SIZE(self->seperator), 1);
    if (res==0) puts("not found");
    else puts("found");

}

The output is: 

yetix(366)% python2.1 test.py
seperator: u'+#&.'
Searching for: u'h'
found

So PyUnicode_Find() returns a match although
u'h' is not contained within self->seperator.

Env: Linux 2.4, Python 2.1.3





----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2002-06-10 06:48

Message:
Logged In: YES 
user_id=11084

Looking it the source, it is a documentation bug since 
PyUnicode_Find()  really returns int. 

Can you assign this issue to Fred to fix the docs *wink*?

-aj

----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2002-06-10 06:45

Message:
Logged In: YES 
user_id=11084

So what does PyUnicode_Find() return?

>From the docs:
PyObject* PyUnicode_Find(PyObject *str, PyObject *substr,
int start, int end, int direction)
    Return value: New reference.
Return the first position of substr in str[start:end] using
the given direction (direction == 1 means to do a forward
search, direction == -1 a backward search), 0 otherwise. 

Does it return an int with the position or a PyObject * ?

-aj

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-10 05:17

Message:
Logged In: YES 
user_id=38388

You should check what res actually is rather then doing
the check for == 0. Note that res == -1 means
"not found", res == 0 maps to: match found at position
0.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566631&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 11:52:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 03:52:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-566631 ] PyUnicode_Find() returns wrong results
Message-ID: <E17HMn6-0003E2-00@usw-sf-web3.sourceforge.net>

Bugs item #566631, was opened at 2002-06-10 00:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566631&group_id=5470

Category: Unicode
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: PyUnicode_Find() returns wrong results

Initial Comment:
The following is used to search for u'h' inside
the string u'+#&.' (stored in self->seperator)

static PyObject *
Splitter_test(Splitter *self) {
    PyObject *test, *res, *word;

    test = Py_BuildValue("s","h");
    word =
PyUnicode_FromEncodedObject(test,"ascii","strict");

    printf("seperator: ");
    PyObject_Print(self->seperator, stdout, 0);
    puts("");

    printf("Searching for: ");
    PyObject_Print(word, stdout, 0);
    puts("");

    res = PyUnicode_Find(self->seperator, word, 0,
PyUnicode_GET_SIZE(self->seperator), 1);
    if (res==0) puts("not found");
    else puts("found");

}

The output is: 

yetix(366)% python2.1 test.py
seperator: u'+#&.'
Searching for: u'h'
found

So PyUnicode_Find() returns a match although
u'h' is not contained within self->seperator.

Env: Linux 2.4, Python 2.1.3





----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-10 10:52

Message:
Logged In: YES 
user_id=38388

The docs should say it's an int.

----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2002-06-10 10:48

Message:
Logged In: YES 
user_id=11084

Looking it the source, it is a documentation bug since 
PyUnicode_Find()  really returns int. 

Can you assign this issue to Fred to fix the docs *wink*?

-aj

----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2002-06-10 10:45

Message:
Logged In: YES 
user_id=11084

So what does PyUnicode_Find() return?

>From the docs:
PyObject* PyUnicode_Find(PyObject *str, PyObject *substr,
int start, int end, int direction)
    Return value: New reference.
Return the first position of substr in str[start:end] using
the given direction (direction == 1 means to do a forward
search, direction == -1 a backward search), 0 otherwise. 

Does it return an int with the position or a PyObject * ?

-aj

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-10 09:17

Message:
Logged In: YES 
user_id=38388

You should check what res actually is rather then doing
the check for == 0. Note that res == -1 means
"not found", res == 0 maps to: match found at position
0.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566631&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 11:53:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 03:53:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-566631 ] PyUnicode_Find() returns wrong results
Message-ID: <E17HMo8-0002VS-00@usw-sf-web1.sourceforge.net>

Bugs item #566631, was opened at 2002-06-09 20:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566631&group_id=5470

Category: Unicode
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: PyUnicode_Find() returns wrong results

Initial Comment:
The following is used to search for u'h' inside
the string u'+#&.' (stored in self->seperator)

static PyObject *
Splitter_test(Splitter *self) {
    PyObject *test, *res, *word;

    test = Py_BuildValue("s","h");
    word =
PyUnicode_FromEncodedObject(test,"ascii","strict");

    printf("seperator: ");
    PyObject_Print(self->seperator, stdout, 0);
    puts("");

    printf("Searching for: ");
    PyObject_Print(word, stdout, 0);
    puts("");

    res = PyUnicode_Find(self->seperator, word, 0,
PyUnicode_GET_SIZE(self->seperator), 1);
    if (res==0) puts("not found");
    else puts("found");

}

The output is: 

yetix(366)% python2.1 test.py
seperator: u'+#&.'
Searching for: u'h'
found

So PyUnicode_Find() returns a match although
u'h' is not contained within self->seperator.

Env: Linux 2.4, Python 2.1.3





----------------------------------------------------------------------

>Comment By: Andreas Jung (ajung)
Date: 2002-06-10 06:53

Message:
Logged In: YES 
user_id=11084

Fred, could you please fix the docs for PyUnicode_Find()?
The return value is an int instead of a PyObject *. Also -1
is returned for "not found" instead of 0.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-10 06:52

Message:
Logged In: YES 
user_id=38388

The docs should say it's an int.

----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2002-06-10 06:48

Message:
Logged In: YES 
user_id=11084

Looking it the source, it is a documentation bug since 
PyUnicode_Find()  really returns int. 

Can you assign this issue to Fred to fix the docs *wink*?

-aj

----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2002-06-10 06:45

Message:
Logged In: YES 
user_id=11084

So what does PyUnicode_Find() return?

>From the docs:
PyObject* PyUnicode_Find(PyObject *str, PyObject *substr,
int start, int end, int direction)
    Return value: New reference.
Return the first position of substr in str[start:end] using
the given direction (direction == 1 means to do a forward
search, direction == -1 a backward search), 0 otherwise. 

Does it return an int with the position or a PyObject * ?

-aj

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-10 05:17

Message:
Logged In: YES 
user_id=38388

You should check what res actually is rather then doing
the check for == 0. Note that res == -1 means
"not found", res == 0 maps to: match found at position
0.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566631&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 12:09:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 04:09:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-566631 ] PyUnicode_Find() returns wrong results
Message-ID: <E17HN2l-0003SD-00@usw-sf-web3.sourceforge.net>

Bugs item #566631, was opened at 2002-06-09 20:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566631&group_id=5470

>Category: Documentation
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: PyUnicode_Find() returns wrong results

Initial Comment:
The following is used to search for u'h' inside
the string u'+#&.' (stored in self->seperator)

static PyObject *
Splitter_test(Splitter *self) {
    PyObject *test, *res, *word;

    test = Py_BuildValue("s","h");
    word =
PyUnicode_FromEncodedObject(test,"ascii","strict");

    printf("seperator: ");
    PyObject_Print(self->seperator, stdout, 0);
    puts("");

    printf("Searching for: ");
    PyObject_Print(word, stdout, 0);
    puts("");

    res = PyUnicode_Find(self->seperator, word, 0,
PyUnicode_GET_SIZE(self->seperator), 1);
    if (res==0) puts("not found");
    else puts("found");

}

The output is: 

yetix(366)% python2.1 test.py
seperator: u'+#&.'
Searching for: u'h'
found

So PyUnicode_Find() returns a match although
u'h' is not contained within self->seperator.

Env: Linux 2.4, Python 2.1.3





----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-06-10 07:09

Message:
Logged In: YES 
user_id=31435

Thanks for spotting this, Andreas!

Changed Category to Docs.

Fred, the correct return conditions are documented in 
unicodeobject.h:

"""
Return the first position of substr in str[start:end] using the
given search direction or -1 if not found. -2 is returned in
case  an error occurred and an exception is set.
"""

While looking that up, I noticed that PyUnicode_Count is 
similarly misdocumented.  There may well be others.

----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2002-06-10 06:53

Message:
Logged In: YES 
user_id=11084

Fred, could you please fix the docs for PyUnicode_Find()?
The return value is an int instead of a PyObject *. Also -1
is returned for "not found" instead of 0.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-10 06:52

Message:
Logged In: YES 
user_id=38388

The docs should say it's an int.

----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2002-06-10 06:48

Message:
Logged In: YES 
user_id=11084

Looking it the source, it is a documentation bug since 
PyUnicode_Find()  really returns int. 

Can you assign this issue to Fred to fix the docs *wink*?

-aj

----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2002-06-10 06:45

Message:
Logged In: YES 
user_id=11084

So what does PyUnicode_Find() return?

>From the docs:
PyObject* PyUnicode_Find(PyObject *str, PyObject *substr,
int start, int end, int direction)
    Return value: New reference.
Return the first position of substr in str[start:end] using
the given direction (direction == 1 means to do a forward
search, direction == -1 a backward search), 0 otherwise. 

Does it return an int with the position or a PyObject * ?

-aj

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-10 05:17

Message:
Logged In: YES 
user_id=38388

You should check what res actually is rather then doing
the check for == 0. Note that res == -1 means
"not found", res == 0 maps to: match found at position
0.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566631&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 12:59:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 04:59:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-566302 ] Bgen should generate 7-bit-clean code
Message-ID: <E17HNpj-0002N4-00@usw-sf-web4.sourceforge.net>

Bugs item #566302, was opened at 2002-06-08 23:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566302&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Bgen should generate 7-bit-clean code

Initial Comment:
Bgen should generate 7-bit clean code by using hex escapes for non-ascii characters. This should circumvene the problem with MacRoman vs. Latin-1 conversion for files under CVS. The bad news is that this means bgen may need to parse the constant declarations, but maybe we can get away by just escaping all non-ascii chars (as they should only occur within either strings or comments in C header files anyway).

The same probably holds for gensuitemodule.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-10 13:59

Message:
Logged In: YES 
user_id=21627

I see, thanks for the explanation. I would still maintain
that it is a bug in the header files, then, since this is
implementation-defined behaviour as well, in C.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-06-09 21:40

Message:
Logged In: YES 
user_id=45365

The problem is mainly with MacOS "OSType" style values. OSType values are 32 bit longs, but they are customarily encoded as 4-char character constants (a rather obscure feature of C). These OSType values are ubiquitous in MacOS: creator and file type for files ('APPL' is the filetype for an executable, 'Pyth' is the creator code for MacPython), resource types ('DLOG' for dialog resources), AppleEvent/Open Scripting event type and subtype (send 'core'/'odoc' to open a document), etc etc etc.

Example of an OSType value that occur within the Python core is 'GU
I' (that's a Sigma there) for a resource that influences the I/O behaviour of the GUSI library. And all code that is generated by gensuitemodule or bgen will also contain lots of them.

Especially the Python code generated is error-prone as it may be used both by MacPython and MachoPython. This isn't true for core usage (which is MacPython-only, as far as I am aware).

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 12:51

Message:
Logged In: YES 
user_id=21627

That is precisely my question. Could you pass a copy of a
file that was used as input to bgen and shows this problem
(if for no other reason than to satisfy my curiosity)?

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-06-09 11:15

Message:
Logged In: YES 
user_id=92689

*sigh* Do you know what bgen does? It parses C header files. For 
certain constant definitions it translates C to Python in a fairly simplistic 
way. Any 8-bit char in the C source was passed directly to the .py files. 
And yes, some Mac headers contain 8 bit chars in string constants. 
Revision 1.28 of Tools/bgen/bgen/scantools.py,v fixes this. I'll leave the 
bug open until it's more thoroughly tested.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 11:09

Message:
Logged In: YES 
user_id=21627

I think I understand the issue of using 7-bit clean source
code. I'm still trying to understand the bgen issue: why
would it ever produce output that is not 7-bit-clean?
(again, with examples please).

I would assume that the input is already in error, in such a
case.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-06-09 10:32

Message:
Logged In: YES 
user_id=92689

It's not a question of "doesn't work" but more a question of brittleness: 
Mac CVS clients optionally do text file encoding conversion, but this 
means that everyone involved _have_ to use the same settings or things 
go wrong. It helps to keep source files 7-bit clean. Some .py files in the 
Mac subdirectory are currently not 7-bit clean, and some of these are 
generated by bgen. Hence this "bug".

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 10:23

Message:
Logged In: YES 
user_id=21627

Can you give an example of code where it doesn't work
properly in this respect?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566302&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 15:11:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 07:11:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-566859 ] rotormodule's set_key calls strlen
Message-ID: <E17HPtc-0003qp-00@usw-sf-web4.sourceforge.net>

Bugs item #566859, was opened at 2002-06-10 14:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566859&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Brueck (dbrueck)
Assigned to: Nobody/Anonymous (nobody)
Summary: rotormodule's set_key calls strlen

Initial Comment:
In rotormodule.c's set_key function a call is made to strlen 
on the user-supplied key. According to the documenation, 
the key can contain arbitrary binary data (including zeros 
that would confuse strlen).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566859&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 15:35:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 07:35:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-551412 ] possible to fail to calc mro's
Message-ID: <E17HQGR-0005li-00@usw-sf-web3.sourceforge.net>

Bugs item #551412, was opened at 2002-05-02 09:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551412&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Guido van Rossum (gvanrossum)
Summary: possible to fail to calc mro's

Initial Comment:
This only crashes on the release22-maint branch, and
only when coredump is true:

class UserLong(object):
    def __pow__(self, *args):
        pass

coredump = 1

if not coredump:
   int.__mro__

pow(0, UserLong(), 0)

It's the type of the first argument to pow() that's
relavent: if you change it to "pow(0L, UserLong(), 0)"
you then have to change "int.__mro__" to "long.__mro__"
to avoid the crash.

Maybe it was the "typeobject.c refactoring" patch that
accidentally fixed this on the trunk?

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 10:35

Message:
Logged In: YES 
user_id=6380

Fixed again, this time properly (I hope :-).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-09 20:18

Message:
Logged In: YES 
user_id=6380

I'm reopening this (as a reminder to myself). Calling
PyType_Ready() from _PyType_Lookup() is fishy. It may be
that the real problem is in slot_nb_power(), which tries to
call self.__pow__(other, modulus) without checking that
self...nb_power is inseed slot_nb_power.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-03 15:55

Message:
Logged In: YES 
user_id=6380

OK, fixed that too in 2.2.x and in 2.3, by calling
PyErr_Clear().  Not ideal, but not bad either.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 17:46

Message:
Logged In: YES 
user_id=6380

Argh, reopening.

There's one little detail left:
_PyType_Lookup() promises not
to set an exception.  If the call
to PyType_Ready() fails, this
promise is broken...

What to do?  PyErr_Clear()
and return NULL comes to mind...

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 17:42

Message:
Logged In: YES 
user_id=6380

OK, I nailed it.

The fix is to call PyType_Ready()
in _PyType_Lookup() when mro is NULL.

Fixed in both 2.3 and 2.2.
A test case added only for 2.3.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 17:20

Message:
Logged In: YES 
user_id=6380

In fact, this still crashes in 2.2:
pow(0L, UserLong(), 0L)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 17:10

Message:
Logged In: YES 
user_id=6380

Hm, this is serious.

This can happen whenever a built-in type
isn't initialized by PyType_Ready() yet,
and for many that is pretty common.
(The call to int.__mro__ goes through
type_getattro which calls PyType_Ready().)

I'm not sure which refactoring patch
you are referring to, and I'm actually
not at all sure that this can't happen
in 2.3 (despite the fact that this
particular example doesn't core dump there).

I'll investigate more...


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551412&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 15:37:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 07:37:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-566869 ] Typo in "What's new in Python 2.3"
Message-ID: <E17HQIY-00055f-00@usw-sf-web1.sourceforge.net>

Bugs item #566869, was opened at 2002-06-10 09:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566869&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Chermside (mcherm)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Typo in "What's new in Python 2.3"

Initial Comment:
Section 6 New and Improved Modules
 >>  bullet Dictionary "pop" method
 >>  >> "Dictionaries have a new method,
methodpop(key)..." should be "Dictionaries have a new
method, pop(key)..."

Great work... nicely written docs!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566869&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 16:53:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 08:53:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-566869 ] Typo in "What's new in Python 2.3"
Message-ID: <E17HRUI-0005js-00@usw-sf-web2.sourceforge.net>

Bugs item #566869, was opened at 2002-06-10 10:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566869&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michael Chermside (mcherm)
>Assigned to: A.M. Kuchling (akuchling)
>Summary: Typo in "What's new in Python 2.3"

Initial Comment:
Section 6 New and Improved Modules
 >>  bullet Dictionary "pop" method
 >>  >> "Dictionaries have a new method,
methodpop(key)..." should be "Dictionaries have a new
method, pop(key)..."

Great work... nicely written docs!

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-06-10 11:53

Message:
Logged In: YES 
user_id=11375

Typo fixed in CVS; the Web page will be updated the next 
time Fred updates the HTML version.  Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566869&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 17:08:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 09:08:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-532646 ] Recursive class instance "error"
Message-ID: <E17HRit-0005uQ-00@usw-sf-web2.sourceforge.net>

Bugs item #532646, was opened at 2002-03-20 13:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Gregor Mirai (gregmi)
>Assigned to: Neal Norwitz (nnorwitz)
>Summary: Recursive class instance "error"

Initial Comment:
If one writes the following code (tested on Python  
2.1, 2.2 on platforms MacOS X Server, MacOS X, Windows 
98, NT, 2000) one can easily produce several "errors".

MacOS X, MacOS X Server (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name,
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
Segmentation fault

Win98, NT, 2000 (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
foo
__repr__ __call__ __call__ __call__ ... ad inf



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 12:08

Message:
Logged In: YES 
user_id=6380

Can you explain how the fix works? Why does the first
comment say

/* this shouldn't be reached, but just in case */

and why is this test necesary

if (tstate->recursion_depth < Py_GetRecursionLimit()) {

???

And who *does* report the recursion error?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 18:52

Message:
Logged In: YES 
user_id=33168

The recursion fields are shared in the new patch.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 16:35

Message:
Logged In: YES 
user_id=33168

That sounds more reasonable.
I'll take a look and see if they can be integrated.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-07 16:27

Message:
Logged In: YES 
user_id=6380

Fair enough.  Ideally this should share the recursion_limit
variable from ceval.c and the recursion_depth field of the
stack frame.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 16:23

Message:
Logged In: YES 
user_id=33168

I don't know.  I tried to come up with other test cases and
failed.
Tried __str__ and __getitem__.  Also tried new-style classes.

The problem was that the code bounced back and forth
between PyObject_Call() & instance_call() (mutual recursion).


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-07 16:08

Message:
Logged In: YES 
user_id=6380

Is this fix enough?  Aren't there lots of other ways to
generate the same error?  E.g. new-style classes (where this
particular example doesn't apply, but others might).

Or is this specific to instance_call?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 15:21

Message:
Logged In: YES 
user_id=33168

The attached patch stops the segfault and raises an exception:
TypeError: 'A' max recursion limit (100000) exceeded

I'm not sure if this is genarally applicable, or what a
reasonable # is.
100,000 was a guess and should probably be made a #def
w/comment.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-21 04:47

Message:
Logged In: NO 

>>> a=A() 
>>> a.foo 
foo 
__repr__ __call__ __call__ __call__ ... ad inf

This is normal behavior. The code at the top is buggy. The 
correct one is:

class A:
  def __getattr__(self, name):
    if name == '__repr__':
      return self.__repr__()
    print name
    return A()

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-20 17:10

Message:
Logged In: YES 
user_id=6380

This is buggy user code.

But the segfault should be fixed if possible.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 18:21:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 10:21:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-566970 ] __imul__ broken for 'object's
Message-ID: <E17HSrJ-0006jN-00@usw-sf-web1.sourceforge.net>

Bugs item #566970, was opened at 2002-06-10 17:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566970&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Schmolck (aschmolck)
Assigned to: Nobody/Anonymous (nobody)
Summary: __imul__ broken for 'object's

Initial Comment:
class Breaky(object):
    def __imul__(self, other):
        print "imuling"
        return self
sq = Breaky()
sq *=1.

gives:

Traceback (most recent call last):[...] line 10, in ?
    sq *=1.
TypeError: can't multiply sequence to non-int


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566970&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 20:23:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 12:23:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-563750 ] os.tmpfile should use w+b, not w+
Message-ID: <E17HUla-00080U-00@usw-sf-web2.sourceforge.net>

Bugs item #563750, was opened at 2002-06-03 01:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563750&group_id=5470

Category: Python Library
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Alex Martelli (aleax)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.tmpfile should use w+b, not w+

Initial Comment:
os.tmpfile is only present on Unix and Windows, and on 
Unix it makes no difference.  On Windows, Microsoft's
docs indicate tmpfile uses mode w+b -- which makes a lot 
of sense as it lets you shunt temporarily to disk binary 
stuff without any ill effect for text stuff.  Unfortunately the 
implementation of os.tmpfile in Modules/posixmodule.c 
calls PyFile_FromFile with 'w+', not 'w+b', so that's what 
gets recorded as the mode attribute of the file object.

So, a careful function which receives a file object 
argument
and checks that its mode contains a 'b' (because it needs
to to binary I/O on the file) will diagnose inexistent 
problems
when it's called with an argument that's a file object 
returned
from os.tmpfile().

Suggested fix: change 'w+' to 'w+b' in posixmodule.c and
in the docs for module os, function tmpfile in each case.

This could only possibly break carelessly coded functions
that check the mode attribute and require it to be identical
to 'w+' when they actually can work perfectly well with
'w+b' (because w+b is what they actually GET, though it
falsely claims to be w+).  I think this hypothetical 
breakage
(I know of no such function, and anybody careful enough 
to
check the mode is likely also careful enough to do the 
RIGHT check) is quite tolerable in exchange for having 
the
os.tmpfile function reflect reality and let careful well-coded
functions work naturally and correctly.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 15:23

Message:
Logged In: YES 
user_id=6380

Thanks! Fixed, and marked as bugfix candidate.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563750&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 20:25:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 12:25:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-564729 ] FixTk.py logic wrong
Message-ID: <E17HUnC-00087K-00@usw-sf-web1.sourceforge.net>

Bugs item #564729, was opened at 2002-06-05 02:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564729&group_id=5470

Category: Tkinter
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Internet Discovery (idiscovery)
Assigned to: Nobody/Anonymous (nobody)
Summary: FixTk.py logic wrong

Initial Comment:
The logic in FixTk.py is wrong for Tix: the Tix version number
is independent of the Tk/Tcl version number.

Just duplicate the Tcl code logic for Tix, and don't reuse the 
Tcl version number.



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 15:25

Message:
Logged In: YES 
user_id=6380

Can you please supply a patch?

The code in 2.2 and later is different; is that still
broken?  If so, please supply two patches!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=564729&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 20:26:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 12:26:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-565373 ] IDLE needs printing
Message-ID: <E17HUo0-0006ae-00@usw-sf-web4.sourceforge.net>

Bugs item #565373, was opened at 2002-06-06 11:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565373&group_id=5470

Category: IDLE
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: IDLE needs printing

Initial Comment:
IDLE really needs a way to print.

It turns out that on Windows, you can print a text file
by invoking notepad /p filename. We can do that using
os.popen() (rather than os.system(), which opens an
ugly DOS box).

On Unix, we can invoke lpr filename in the same way.

So we can make this a standard menu item that takes the
command line to use from the configuration file.  I'll
implement this when I have time (or someone else can
implement it).


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 15:26

Message:
Logged In: YES 
user_id=6380

I've added a simple Print Window command that does this
using Tim's suggestion.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-06 11:40

Message:
Logged In: YES 
user_id=6380

According to Mark Hammond, you can also print by copying the
file to the default printer name; if you have win32all,
win32print.GetDefaultPrinter() returns the pathname for the
default printer (e.g. \brat\canon).

Tim Peters notes that you can use "start /min notepad /p
filename" to avoid opening notepad's main window (it still
shows a dialog with a cancel button for a fraction of a
second).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565373&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 20:30:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 12:30:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-565710 ] ImportError: No module named _socket
Message-ID: <E17HUs5-0006dN-00@usw-sf-web4.sourceforge.net>

Bugs item #565710, was opened at 2002-06-07 04:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565710&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
>Priority: 3
Submitted By: Philipp Kolmann (pkolmann)
Assigned to: Nobody/Anonymous (nobody)
Summary: ImportError: No module named _socket

Initial Comment:
Hi,

I just wanted to try out Mailman on a Sun Solaris
machine and compiled therefore Python 2.2.

It did compile ok, but there seems to be a problem with
the socket library:

bash-2.03$ python /opt/PYthon/lib/python2.2/socket.py
Traceback (most recent call last):
  File "/opt/PYthon/lib/python2.2/socket.py", line 41, in ?
    from _socket import *
ImportError: No module named _socket


Could you help me with this problem.

Thanks a lot
Philipp Kolmann

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 15:30

Message:
Logged In: YES 
user_id=6380

MWH: I don't see the connection with SSL. More likely
somehow the socket module didn't get built. Quite possibly
his whole installation is hosed. Reducing the priority since
local configuration errors are usually not something that
Python can do anything about.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-06-07 09:33

Message:
Logged In: YES 
user_id=6656

The problem is probably ssl support.  Try editing
Modules/Setup and uncommenting the line:

#_socket socketmodule.c

If you *need* ssl support, then you'll have to dig deeper...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565710&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 20:28:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 12:28:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-565414 ] urllib FancyURLopener.__init__ / urlopen
Message-ID: <E17HUq5-00084c-00@usw-sf-web2.sourceforge.net>

Bugs item #565414, was opened at 2002-06-06 12:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565414&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: urllib FancyURLopener.__init__ / urlopen

Initial Comment:
Fred, you changed line 69 in urllib.py to call
FancyURLopener()
with kwargs, but the constructor (line 538) doesn't
accept **kwargs.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 15:28

Message:
Logged In: YES 
user_id=6380

Neal, the fix is to add support for kwargs in
FancyURLOpener.__init__, and to pass it on? You can check
this in yourself.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565414&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 20:32:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 12:32:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-565993 ] string.replace() can corrupt heap
Message-ID: <E17HUu3-0008LY-00@usw-sf-web3.sourceforge.net>

Bugs item #565993, was opened at 2002-06-07 17:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565993&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
>Priority: 3
Submitted By: Mike Romberg (romberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: string.replace() can corrupt heap

Initial Comment:
  I've been using a tool called mpatrol
(http://www.cbmamiga.demon.co.uk/mpatrol/) to cleanup an
embeded python application we have and ran into this
bug.  It seems to affect a stock python as well.  Under
certain
conditions it appears that one can get python to acess
freed
memory by calling string.replace or the string replace
method.

  Here is an example python command which reproduces
the problem:

python -c "a = 'a\000'; a.replace('\000', '')"

  The mpatrol library dumps the following logfile:

(see attachment)




----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-07 21:57

Message:
Logged In: YES 
user_id=31435

When somebody gets a report from one of these tools, 
there are 3 possibilities:

1. It's a bug in Python.
2. It's a bug in the tool.
3. It's a bug in the platform C library, compiler, or OS.

Historical fact is that #2 is the most frequent outcome, and 
these usually burn lots of time to pin the blame, so you're 
going to have to do more work if you want this taken 
seriously.

I stepped through your test case under a debugger using 
2.2.1, and saw nothing wrong.  There's a memcpy with a 
length of 0 where your tool reports "a problem", but that's 
not an error, and the addresses passed at that point are to 
legitimate memory regardless.  It's possible that your 
platform C library optimizes memcpy under the covers by 
reading up more memory than was requested, but platform 
libraries are outside of Python's control, and platform 
library authors generally "cheat" in safe ways.

At the very least, can you get into a debugger and find 
some reason to believe there's a real problem here better 
than "some program said so"?  If not, I'm inclined to close 
this as a 3rd-party bug without burning more time on it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565993&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 20:37:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 12:37:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-566006 ] telnetlib makes Python dump core
Message-ID: <E17HUyL-0006is-00@usw-sf-web4.sourceforge.net>

Bugs item #566006, was opened at 2002-06-07 17:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566006&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
>Priority: 3
Submitted By: Rikard Bosnjakovic (bosna)
Assigned to: Nobody/Anonymous (nobody)
Summary: telnetlib makes Python dump core

Initial Comment:
I have a machine without network and it does not run 
DNS. It runs an irc-server, and when doing the 
following, Python crashes and dumps core:

>>> import telnetlib
>>> a = telnetlib.Telnet("localhost", 6667)
>>> dir(a)

(crash)

If i do /bin/telnet localhost 6667 it works fine, so the 
irc-server is not broken. Gdb gives me this backtrace:

(gdb) bt
#0  0x00000000 in ?? ()
#1  0x080bed79 in dict_dealloc (mp=0x815aef4) at 
Objects/dictobject.c:700
#2  0x080569ff in PyObject_Dir (arg=0x815cb0c) at 
Objects/object.c:1502
#3  0x080c405d in builtin_dir (self=0x0, 
args=0x8114f6c) at Python/bltinmodule.c:436
#4  0x080c0e4d in PyCFunction_Call 
(func=0x80f7c38, arg=0x8114f6c, kw=0x0)
    at Objects/methodobject.c:80
#5  0x08072ff3 in eval_frame (f=0x810a34c) at 
Python/ceval.c:1974
#6  0x08074002 in PyEval_EvalCodeEx 
(co=0x8142a68, globals=0x8104b7c, 
locals=0x8104b7c, 
    args=0x0, argcount=0, kws=0x0, kwcount=0, 
defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:2545
#7  0x08075f90 in PyEval_EvalCode 
(co=0x8142a68, globals=0x8104b7c, 
locals=0x8104b7c)
    at Python/ceval.c:482
#8  0x08091061 in run_node (n=0x8141878, 
filename=0x80c5795 "<stdin>", globals=0x8104b7c, 
    locals=0x8104b7c, flags=0xbffff8f4) at 
Python/pythonrun.c:1065
#9  0x0808f6c0 in PyRun_InteractiveOneFlags 
(fp=0x401672e0, filename=0x80c5795 "<stdin>", 
    flags=0xbffff8f4) at Python/pythonrun.c:579
#10 0x080909c1 in PyRun_InteractiveLoopFlags 
(fp=0x401672e0, filename=0x80c5795 "<stdin>", 
    flags=0xbffff8f4) at Python/pythonrun.c:515
#11 0x080907bb in PyRun_AnyFileExFlags 
(fp=0x401672e0, filename=0x80c5795 "<stdin>", 
    closeit=0, flags=0xbffff8f4) at 
Python/pythonrun.c:478
#12 0x08053022 in Py_Main (argc=2, 
argv=0xbffff984) at Modules/main.c:366
#13 0x080528ea in main (argc=2, argv=0xbffff984) 
at Modules/python.c:10
#14 0x4007b542 in __libc_start_main () 
from /lib/libc.so.6



The crash is reproducible. It crashes everytime I try 
the code above. Python 2.2, I have not been able to 
try it with a newer version.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 15:37

Message:
Logged In: YES 
user_id=6380

Your line numbers seem off.  Can you try again with a debug
build?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 04:35

Message:
Logged In: YES 
user_id=21627

What operating system? Does it fail for every port, or just
for the IRC port?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566006&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 20:39:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 12:39:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-566037 ] Popen exectuion blocking w/threads
Message-ID: <E17HV0u-0008DU-00@usw-sf-web2.sourceforge.net>

Bugs item #566037, was opened at 2002-06-07 20:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566037&group_id=5470

Category: Threads
Group: Python 2.2.1
Status: Open
Resolution: None
>Priority: 3
Submitted By: Martin Stoufer (mstoufer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Popen exectuion blocking w/threads

Initial Comment:
The following unit test hangs after the first two lines
of output. This is wholly reproducible (for us) under
2.2.1 and totaly unreproducible under 2.1. We have both
interpreters installed on a RH7.2 PC with linkings
against the apparent same /lib/libthread.so.0

import os, threading,time, sys
def read_output(self, cmd, timeout):
        print "run: %s" % cmd
        (inf,outf) = os.popen4(cmd)
        print "started! out_fd=%d" % outf.fileno()
        while 1:
            line = outf.readline()
            if line == "": break
            print len(line),line
            sys.stdout.flush()
        return
if __name__ == '__main__': 
    thr =
threading.Thread(target=read_output,args=(1,"ping -c 5
www.mit.edu",0))
    thr.start()
    print "Started thread"
    while 1: time.sleep(1)

mstoufer@dpsslx05(3)>ldd /usr/local/bin/python2.{1,2}
/usr/local/bin/python2.1:
	libpthread.so.0 => /lib/libpthread.so.0 (0x40029000)
	libdl.so.2 => /lib/libdl.so.2 (0x40040000)
	libutil.so.1 => /lib/libutil.so.1 (0x40044000)
	libstdc++-libc6.1-2.so.3 =>
/usr/local/lib/libstdc++-libc6.1-2.so.3 (0x40047000)
	libm.so.6 => /lib/libm.so.6 (0x4008f000)
	libc.so.6 => /lib/libc.so.6 (0x400b1000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
/usr/local/bin/python2.2:
	libdl.so.2 => /lib/libdl.so.2 (0x40029000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x4002d000)
	libutil.so.1 => /lib/libutil.so.1 (0x40044000)
	libm.so.6 => /lib/libm.so.6 (0x40047000)
	libc.so.6 => /lib/libc.so.6 (0x4006a000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 15:39

Message:
Logged In: YES 
user_id=6380

Mixing forks and threads is often asking for trouble...

Does this also hang with another command that produces more
than two lines of output, or is it limited to ping?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 04:32

Message:
Logged In: YES 
user_id=21627

I can't reproduce this on a SuSE system, either (which has
glibc 2.2.5), so I'm tempted to declare it a glibc 2.1 bug.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-06-08 01:42

Message:
Logged In: YES 
user_id=14198

Just noting that current CVS Python works fine on Windows,
but also hangs on RH7.  My Linux debuggings skills are such
that I can offer no further help ;)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566037&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 20:47:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 12:47:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-566859 ] rotormodule's set_key calls strlen
Message-ID: <E17HV8s-0008Oq-00@usw-sf-web1.sourceforge.net>

Bugs item #566859, was opened at 2002-06-10 10:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566859&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Dave Brueck (dbrueck)
Assigned to: Nobody/Anonymous (nobody)
Summary: rotormodule's set_key calls strlen

Initial Comment:
In rotormodule.c's set_key function a call is made to strlen 
on the user-supplied key. According to the documenation, 
the key can contain arbitrary binary data (including zeros 
that would confuse strlen).

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 15:47

Message:
Logged In: YES 
user_id=6380

The rotor module is too old to fix (we're considering
retiring it, since it is cryptographically weak), so I've
opted for documenting this fact.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566859&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 21:45:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 13:45:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-558072 ] faqwiz.py could do email obfuscation
Message-ID: <E17HW2P-0007bj-00@usw-sf-web4.sourceforge.net>

Bugs item #558072, was opened at 2002-05-19 16:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558072&group_id=5470

Category: Demos and Tools
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Reis (kiko_async)
Assigned to: Guido van Rossum (gvanrossum)
Summary: faqwiz.py could do email obfuscation

Initial Comment:
Faqwiz.py could obfuscate emails very easily, simply by
replacing @ by some other symbol in it's output. I've
homecooked a solution that basically involves:

adding to faqconf.py:

 # Obfuscate @ symbol as

 OBFUSCATE="-at-"

and changing interpolate() in faqwiz.py:

 def _interpolate(format, args, kw):
    try:
        quote = kw['_quote']
    except KeyError:
        quote = 1 
    d = (kw,) + args + (faqconf.__dict__,)
    m = MagicDict(d, quote)
    return string.replace(format % m, '@', OBFUSCATE)

This isn't my favourite solution, though, but since I
find the code a bit hard to follow, it suffices for
now. I'm willing to work a bit more on this if it
interests people.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 16:45

Message:
Logged In: YES 
user_id=6380

Clearly this does too much -- interpolate is used in a
number of contexts where a @ shouldn't be obfuscated, e.g.
commands to be executed by the shell.

I'm unclear on *where* you'd like to obfuscate email
addresses. Do you only want to obfuscate the email address
of the person who modified the entry, or do you want to
obfuscate all @ signs anywhere in the text? The latter seems
overkill, and can cause breakage in code samples that happen
to use @ signs.

BTW, you're right that this code is hard to follow! It could
benefit from a few comments here or there... :-(

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 14:46

Message:
Logged In: YES 
user_id=6380

Good idea.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558072&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 22:10:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 14:10:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-560794 ] deepcopy can't handle custom metaclasses
Message-ID: <E17HWQx-0000JM-00@usw-sf-web4.sourceforge.net>

Bugs item #560794, was opened at 2002-05-26 15:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560794&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Guido van Rossum (gvanrossum)
Summary: deepcopy can't handle custom metaclasses

Initial Comment:
This is essentially the same problem as that reported in 
bug 494904 for pickle: deepcopy should treat instances 
of custom metaclasses the same way it treats 
instances of type 'type'.  I've attached a provisional fix 
which is basically a copy of the patch made to pickle (it 
checks to see if the type of the thing being deepcopied 
is a subclass of type).

One question: it seems to me that the exception 
handling code is unnecessary both here and in the 
pickle module.  In both cases, the first parameter to 
subclass is the result of a call to 'type' and the second 
is type 'type' itself, so it doesn't seem like there's any 
reason to worry about a TypeError.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 17:10

Message:
Logged In: YES 
user_id=6380

Thanks; I've checked this in. For the reason of the except
clause, see python.org/sf/502085.

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2002-05-26 15:35

Message:
Logged In: YES 
user_id=86307

I changed the patch so that issubclass is called before the 
attempt to access __deepcopy__ (to avoid unbound instance 
method problem methioned in 494904).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560794&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 22:10:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 14:10:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-560794 ] deepcopy can't handle custom metaclasses
Message-ID: <E17HWRC-0000zd-00@usw-sf-web1.sourceforge.net>

Bugs item #560794, was opened at 2002-05-26 15:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560794&group_id=5470

Category: Python Library
Group: Python 2.2.1
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Guido van Rossum (gvanrossum)
Summary: deepcopy can't handle custom metaclasses

Initial Comment:
This is essentially the same problem as that reported in 
bug 494904 for pickle: deepcopy should treat instances 
of custom metaclasses the same way it treats 
instances of type 'type'.  I've attached a provisional fix 
which is basically a copy of the patch made to pickle (it 
checks to see if the type of the thing being deepcopied 
is a subclass of type).

One question: it seems to me that the exception 
handling code is unnecessary both here and in the 
pickle module.  In both cases, the first parameter to 
subclass is the result of a call to 'type' and the second 
is type 'type' itself, so it doesn't seem like there's any 
reason to worry about a TypeError.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 17:10

Message:
Logged In: YES 
user_id=6380

Thanks; I've checked this in. For the reason of the except
clause, see python.org/sf/502085.

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2002-05-26 15:35

Message:
Logged In: YES 
user_id=86307

I changed the patch so that issubclass is called before the 
attempt to access __deepcopy__ (to avoid unbound instance 
method problem methioned in 494904).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560794&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 22:13:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 14:13:54 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-458253 ] pre-allocated dictionaries
Message-ID: <E17HWU6-0000Q6-00@usw-sf-web3.sourceforge.net>

Feature Requests item #458253, was opened at 2001-09-03 23:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=458253&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Nobody/Anonymous (nobody)
Summary: pre-allocated dictionaries

Initial Comment:
Steve Kirsch (of Propel) expects that he may need to
pre-allocate a dictionary with a given hash table size,
to avoid frequent stops due to resizing. This would be
easy to add by using a keyword argument to dict_init(),
I believe. But note that Kirsch has no evidence yet of
a slowdown.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 17:13

Message:
Logged In: YES 
user_id=6380

Let's call this a Yagni.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=458253&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 22:18:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 14:18:14 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-454896 ] Add unsigneds to ParseTuple/BuildValue
Message-ID: <E17HWYI-0000xs-00@usw-sf-web2.sourceforge.net>

Feature Requests item #454896, was opened at 2001-08-24 05:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=454896&group_id=5470

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add unsigneds to ParseTuple/BuildValue

Initial Comment:
From: David Beazley <beazley@cs.uchicago.edu>

Since "integers" can now have arbitrary precision and
can represent large unsigned values, can you add three
new format characters to PyArg_ParseTuple() and
Py_BuildValue() for the C datatypes "unsigned int", 
"unsigned long", and "unsigned long long"?  

The "u" and "l" namespace is a little crowded (and I
don't think you would want to break that).  However,
here's one idea:

'I'     -  unsigned int  (consistent with H and B)
'p'     -  unsigned long ('p' is for positive)
'P'     -  unsigned long long


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 17:18

Message:
Logged In: YES 
user_id=6380

Thank you.

I've moved this feature request to PEP 42, "Feature Requests".


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=454896&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 22:26:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 14:26:45 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-458253 ] pre-allocated dictionaries
Message-ID: <E17HWgX-000139-00@usw-sf-web2.sourceforge.net>

Feature Requests item #458253, was opened at 2001-09-03 23:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=458253&group_id=5470

Category: None
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Nobody/Anonymous (nobody)
Summary: pre-allocated dictionaries

Initial Comment:
Steve Kirsch (of Propel) expects that he may need to
pre-allocate a dictionary with a given hash table size,
to avoid frequent stops due to resizing. This would be
easy to add by using a keyword argument to dict_init(),
I believe. But note that Kirsch has no evidence yet of
a slowdown.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-06-10 17:26

Message:
Logged In: YES 
user_id=31435

I agree with closing this.  Resizing can't be frequent, as the 
number of resizes total is roughly the log base 2 of the dict 
size.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 17:13

Message:
Logged In: YES 
user_id=6380

Let's call this a Yagni.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=458253&group_id=5470



From noreply@sourceforge.net  Mon Jun 10 23:46:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 15:46:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-566006 ] telnetlib makes Python dump core
Message-ID: <E17HXvR-0001NT-00@usw-sf-web4.sourceforge.net>

Bugs item #566006, was opened at 2002-06-07 23:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566006&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 3
Submitted By: Rikard Bosnjakovic (bosna)
Assigned to: Nobody/Anonymous (nobody)
Summary: telnetlib makes Python dump core

Initial Comment:
I have a machine without network and it does not run 
DNS. It runs an irc-server, and when doing the 
following, Python crashes and dumps core:

>>> import telnetlib
>>> a = telnetlib.Telnet("localhost", 6667)
>>> dir(a)

(crash)

If i do /bin/telnet localhost 6667 it works fine, so the 
irc-server is not broken. Gdb gives me this backtrace:

(gdb) bt
#0  0x00000000 in ?? ()
#1  0x080bed79 in dict_dealloc (mp=0x815aef4) at 
Objects/dictobject.c:700
#2  0x080569ff in PyObject_Dir (arg=0x815cb0c) at 
Objects/object.c:1502
#3  0x080c405d in builtin_dir (self=0x0, 
args=0x8114f6c) at Python/bltinmodule.c:436
#4  0x080c0e4d in PyCFunction_Call 
(func=0x80f7c38, arg=0x8114f6c, kw=0x0)
    at Objects/methodobject.c:80
#5  0x08072ff3 in eval_frame (f=0x810a34c) at 
Python/ceval.c:1974
#6  0x08074002 in PyEval_EvalCodeEx 
(co=0x8142a68, globals=0x8104b7c, 
locals=0x8104b7c, 
    args=0x0, argcount=0, kws=0x0, kwcount=0, 
defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:2545
#7  0x08075f90 in PyEval_EvalCode 
(co=0x8142a68, globals=0x8104b7c, 
locals=0x8104b7c)
    at Python/ceval.c:482
#8  0x08091061 in run_node (n=0x8141878, 
filename=0x80c5795 "<stdin>", globals=0x8104b7c, 
    locals=0x8104b7c, flags=0xbffff8f4) at 
Python/pythonrun.c:1065
#9  0x0808f6c0 in PyRun_InteractiveOneFlags 
(fp=0x401672e0, filename=0x80c5795 "<stdin>", 
    flags=0xbffff8f4) at Python/pythonrun.c:579
#10 0x080909c1 in PyRun_InteractiveLoopFlags 
(fp=0x401672e0, filename=0x80c5795 "<stdin>", 
    flags=0xbffff8f4) at Python/pythonrun.c:515
#11 0x080907bb in PyRun_AnyFileExFlags 
(fp=0x401672e0, filename=0x80c5795 "<stdin>", 
    closeit=0, flags=0xbffff8f4) at 
Python/pythonrun.c:478
#12 0x08053022 in Py_Main (argc=2, 
argv=0xbffff984) at Modules/main.c:366
#13 0x080528ea in main (argc=2, argv=0xbffff984) 
at Modules/python.c:10
#14 0x4007b542 in __libc_start_main () 
from /lib/libc.so.6



The crash is reproducible. It crashes everytime I try 
the code above. Python 2.2, I have not been able to 
try it with a newer version.

----------------------------------------------------------------------

>Comment By: Rikard Bosnjakovic (bosna)
Date: 2002-06-11 00:46

Message:
Logged In: YES 
user_id=98428

It seems that the version I'm using is 2.2a1 (I guess that's 
why the line numbers seem to be wrong), I will try to 
download the latest version and compile with debuginfo and 
see if I can reproduce the error.

And no, it does not fail to any other port (ftp, telnet, sshd, 
etc), just the IRC one.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 21:37

Message:
Logged In: YES 
user_id=6380

Your line numbers seem off.  Can you try again with a debug
build?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 10:35

Message:
Logged In: YES 
user_id=21627

What operating system? Does it fail for every port, or just
for the IRC port?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566006&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 00:15:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 16:15:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-567127 ] Syntax typo in Python Tutorial
Message-ID: <E17HYO1-0001hJ-00@usw-sf-web4.sourceforge.net>

Bugs item #567127, was opened at 2002-06-10 23:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567127&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brighten Godfrey (godfreyb)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Syntax typo in Python Tutorial

Initial Comment:
In the Python Tutorial, Section 5.1, "More on Lists",
the usage for the pop function is given as

    pop([i])

but should of course be just

    pop(i)

You can see this at:

    http://www.python.org/doc/current/tut/node7.html

Thank you all very much for your work on Python.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567127&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 01:19:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 17:19:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-566006 ] telnetlib makes Python dump core
Message-ID: <E17HZNi-0002MZ-00@usw-sf-web4.sourceforge.net>

Bugs item #566006, was opened at 2002-06-07 17:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566006&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Rikard Bosnjakovic (bosna)
Assigned to: Nobody/Anonymous (nobody)
Summary: telnetlib makes Python dump core

Initial Comment:
I have a machine without network and it does not run 
DNS. It runs an irc-server, and when doing the 
following, Python crashes and dumps core:

>>> import telnetlib
>>> a = telnetlib.Telnet("localhost", 6667)
>>> dir(a)

(crash)

If i do /bin/telnet localhost 6667 it works fine, so the 
irc-server is not broken. Gdb gives me this backtrace:

(gdb) bt
#0  0x00000000 in ?? ()
#1  0x080bed79 in dict_dealloc (mp=0x815aef4) at 
Objects/dictobject.c:700
#2  0x080569ff in PyObject_Dir (arg=0x815cb0c) at 
Objects/object.c:1502
#3  0x080c405d in builtin_dir (self=0x0, 
args=0x8114f6c) at Python/bltinmodule.c:436
#4  0x080c0e4d in PyCFunction_Call 
(func=0x80f7c38, arg=0x8114f6c, kw=0x0)
    at Objects/methodobject.c:80
#5  0x08072ff3 in eval_frame (f=0x810a34c) at 
Python/ceval.c:1974
#6  0x08074002 in PyEval_EvalCodeEx 
(co=0x8142a68, globals=0x8104b7c, 
locals=0x8104b7c, 
    args=0x0, argcount=0, kws=0x0, kwcount=0, 
defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:2545
#7  0x08075f90 in PyEval_EvalCode 
(co=0x8142a68, globals=0x8104b7c, 
locals=0x8104b7c)
    at Python/ceval.c:482
#8  0x08091061 in run_node (n=0x8141878, 
filename=0x80c5795 "<stdin>", globals=0x8104b7c, 
    locals=0x8104b7c, flags=0xbffff8f4) at 
Python/pythonrun.c:1065
#9  0x0808f6c0 in PyRun_InteractiveOneFlags 
(fp=0x401672e0, filename=0x80c5795 "<stdin>", 
    flags=0xbffff8f4) at Python/pythonrun.c:579
#10 0x080909c1 in PyRun_InteractiveLoopFlags 
(fp=0x401672e0, filename=0x80c5795 "<stdin>", 
    flags=0xbffff8f4) at Python/pythonrun.c:515
#11 0x080907bb in PyRun_AnyFileExFlags 
(fp=0x401672e0, filename=0x80c5795 "<stdin>", 
    closeit=0, flags=0xbffff8f4) at 
Python/pythonrun.c:478
#12 0x08053022 in Py_Main (argc=2, 
argv=0xbffff984) at Modules/main.c:366
#13 0x080528ea in main (argc=2, argv=0xbffff984) 
at Modules/python.c:10
#14 0x4007b542 in __libc_start_main () 
from /lib/libc.so.6



The crash is reproducible. It crashes everytime I try 
the code above. Python 2.2, I have not been able to 
try it with a newer version.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 20:19

Message:
Logged In: YES 
user_id=6380

Um, that alpha version had many bugs, being an alpha. :-)

I don't expect you can reproduce this with 2.2.1. I'm
closing this issue.

If you do, please open a new bug report. It would be nice to
know what the irc server is saying.

----------------------------------------------------------------------

Comment By: Rikard Bosnjakovic (bosna)
Date: 2002-06-10 18:46

Message:
Logged In: YES 
user_id=98428

It seems that the version I'm using is 2.2a1 (I guess that's 
why the line numbers seem to be wrong), I will try to 
download the latest version and compile with debuginfo and 
see if I can reproduce the error.

And no, it does not fail to any other port (ftp, telnet, sshd, 
etc), just the IRC one.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 15:37

Message:
Logged In: YES 
user_id=6380

Your line numbers seem off.  Can you try again with a debug
build?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 04:35

Message:
Logged In: YES 
user_id=21627

What operating system? Does it fail for every port, or just
for the IRC port?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566006&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 02:38:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 18:38:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-567127 ] Syntax typo in Python Tutorial
Message-ID: <E17HacC-0003BH-00@usw-sf-web4.sourceforge.net>

Bugs item #567127, was opened at 2002-06-10 23:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567127&group_id=5470

Category: Documentation
Group: None
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: Brighten Godfrey (godfreyb)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Syntax typo in Python Tutorial

Initial Comment:
In the Python Tutorial, Section 5.1, "More on Lists",
the usage for the pop function is given as

    pop([i])

but should of course be just

    pop(i)

You can see this at:

    http://www.python.org/doc/current/tut/node7.html

Thank you all very much for your work on Python.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567127&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 03:59:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 19:59:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-567127 ] Syntax typo in Python Tutorial
Message-ID: <E17HbsP-00040u-00@usw-sf-web4.sourceforge.net>

Bugs item #567127, was opened at 2002-06-10 19:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567127&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Brighten Godfrey (godfreyb)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Syntax typo in Python Tutorial

Initial Comment:
In the Python Tutorial, Section 5.1, "More on Lists",
the usage for the pop function is given as

    pop([i])

but should of course be just

    pop(i)

You can see this at:

    http://www.python.org/doc/current/tut/node7.html

Thank you all very much for your work on Python.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-10 22:59

Message:
Logged In: YES 
user_id=3066

There is a bug there, but not what you describe.  You're
right that the square brackets should not be typed, but
those are actually there to denote an optional parameter. 
This is the first introduction of this notation in the
tutorial, and should be explained.

I've modified the notation to be more clear and precisely
match that used in the Python Library Reference, and added
an explanation of the notation.

This is fixed for all future 2.1.x, 2.2.x, and 2.3 releases.
 The changes are commited at Doc/tut/tut.tex revisions
1.163, 1.156.4.1.2.3, and 1.133.2.7.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567127&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 06:45:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 10 Jun 2002 22:45:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-565747 ] crash on gethostbyaddr
Message-ID: <E17HeSr-0006Nn-00@usw-sf-web2.sourceforge.net>

Bugs item #565747, was opened at 2002-06-07 12:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565747&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Joerg Beyer (jbeyer)
Assigned to: Martin v. Löwis (loewis)
Summary: crash on gethostbyaddr

Initial Comment:
if python is compiled with --disable-ipv6, AND the
host has ipv6 enabled. Then calling

python2.2 -c "import socket; print
socket.gethostbyaddr('::0')"

you get a

Segmentation fault

This is caused by Python copying the V6 information
returned by the OS into the V4 struct of Python.See the
attached diff for socketmodule.c for a fix.

Alternatively, one could move the memcpy at the end of
setipaddr() into the switch, so that if the system
returns "unknown address family", the invalid copy is
not executed.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-11 07:45

Message:
Logged In: YES 
user_id=21627

Sorry about that; the patch is attached now.

----------------------------------------------------------------------

Comment By: Jürgen Hermann (jhermann)
Date: 2002-06-09 13:34

Message:
Logged In: YES 
user_id=39128

Martin,  the attachment didn't make it to the system, it seems.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 11:04

Message:
Logged In: YES 
user_id=21627

Jürgen, can you please try the attached sock.diff? This is a
slightly corrected version of Jörg's patch (IMO). I could
not observe the problem you've seen with Jörg's patch on a
SuSE 8.0 installation.

As for IPv6 not working on a SuSE 7.0 system: This is very
possible. Python requires the RFC2553 API, it might be that
this was not available in the glibc version that shipped
with SuSE 7.0.

----------------------------------------------------------------------

Comment By: Jürgen Hermann (jhermann)
Date: 2002-06-07 16:24

Message:
Logged In: YES 
user_id=39128

We found out a little more: after applying the fix, we get
"unsupported address family" exceptions for IPV6 addresses,
but also we cannot open sockets any more ("could not
connect" exceptions by urllib for any URL). So the fix is
not complete. BTW, the bug appears with Python 2.2, Python
2.0 and 2.1 _do_ work on the same machine.

Another piece of information: we tried to --enable-ipv6 on
that machine (SuSE 7.0, gcc 2.9.95), and got this:

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I./Include -DHAVE_CONFIG_H
-DUSE_SSL -I/netsite/include -I/netsite/include/openssl -c
./Modules/socketmodul

./Modules/socketmodule.c: In function `makesockaddr':
./Modules/socketmodule.c:733: structure has no member named
`sin6_scope_id'
./Modules/socketmodule.c: In function `getsockaddrarg':
./Modules/socketmodule.c:846: structure has no member named
`sin6_scope_id'
./Modules/socketmodule.c: In function `PySocket_getnameinfo':
./Modules/socketmodule.c:2598: structure has no member named
`sin6_scope_id'
make: *** [Modules/socketmodule.o] Error 1 

Don't know whether that is SuSE 7.0's fault.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565747&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 10:14:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 02:14:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-565710 ] ImportError: No module named _socket
Message-ID: <E17HhjD-0000MQ-00@usw-sf-web2.sourceforge.net>

Bugs item #565710, was opened at 2002-06-07 08:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565710&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Philipp Kolmann (pkolmann)
Assigned to: Nobody/Anonymous (nobody)
Summary: ImportError: No module named _socket

Initial Comment:
Hi,

I just wanted to try out Mailman on a Sun Solaris
machine and compiled therefore Python 2.2.

It did compile ok, but there seems to be a problem with
the socket library:

bash-2.03$ python /opt/PYthon/lib/python2.2/socket.py
Traceback (most recent call last):
  File "/opt/PYthon/lib/python2.2/socket.py", line 41, in ?
    from _socket import *
ImportError: No module named _socket


Could you help me with this problem.

Thanks a lot
Philipp Kolmann

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-06-11 09:14

Message:
Logged In: YES 
user_id=6656

But the usual reason for the _socket module not to build on
solaris is ssl issues.  Without more info it's hard to say
anything more (hint, hint, Philipp).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 19:30

Message:
Logged In: YES 
user_id=6380

MWH: I don't see the connection with SSL. More likely
somehow the socket module didn't get built. Quite possibly
his whole installation is hosed. Reducing the priority since
local configuration errors are usually not something that
Python can do anything about.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-06-07 13:33

Message:
Logged In: YES 
user_id=6656

The problem is probably ssl support.  Try editing
Modules/Setup and uncommenting the line:

#_socket socketmodule.c

If you *need* ssl support, then you'll have to dig deeper...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565710&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 10:48:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 02:48:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-450803 ] smtpd.py needs documentation
Message-ID: <E17HiGU-0000GT-00@usw-sf-web3.sourceforge.net>

Bugs item #450803, was opened at 2001-08-14 14:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450803&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: smtpd.py needs documentation

Initial Comment:
smtpd.py needs documentation for the standard library

----------------------------------------------------------------------

>Comment By: Moshe Zadka (moshez)
Date: 2002-06-11 09:48

Message:
Logged In: YES 
user_id=11645

Here's something you can use as a start, Barry.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450803&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 11:01:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 03:01:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-546558 ] Windows getpass bug
Message-ID: <E17HiSp-0000qG-00@usw-sf-web2.sourceforge.net>

Bugs item #546558, was opened at 2002-04-20 18:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546558&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Allan Crooks (amc1)
Assigned to: Mark Hammond (mhammond)
Summary: Windows getpass bug

Initial Comment:
I'm currently running Python 2.2.1 on a Windows 98 
box, and this is the code I have just run.

-------

Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import getpass
>>> def x():
...    secret = getpass.getpass('Tell me a secret: ')
...    stuff = raw_input ('Tell me something else: ')
...    print 'The user told me the secret was "%s" and 
the other thing was "%s"'
 % (secret, stuff)
...
>>> x()
Tell me a secret:
Tell me something else:
The user told me the secret was "Autechre" and the 
other thing was ""
>>>

-------

This may seem normal, but I didn't get the opportunity 
to enter anything when the raw_input was called. I'm 
assuming that getpass leaves the newline character in 
the input buffer, which is then used by raw_input, 
leaving you unable to enter anything.

----------------------------------------------------------------------

>Comment By: Allan Crooks (amc1)
Date: 2002-06-11 10:01

Message:
Logged In: YES 
user_id=39733

I've currently written a module which attempts to fix this 
problem, which you can get from here: 
http://ccec.sf.net/getpassfix.html

However, as I've mentioned in the documentation, it is a hack, 
but the "platform" based solution should become a more 
suitable candidate as it is tested.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-20 20:10

Message:
Logged In: YES 
user_id=31435

Assigning to MarkH in case he has a bright idea.  I don't.

The problem is that getpass on Windows is implemented via 
raw Windows console I/O, and console I/O buffers interact 
in strange and undocumented ways with C's stdio buffers.  
I've never found a reliable way to keep them in synch, and 
MS says you can't mix the two, period.  The only workaround 
I know of is to build your own raw_input() workalike out of 
the msvcrt module's console I/O routines (getch(), etc).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546558&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 11:01:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 03:01:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-210655 ] getpass.getpass on Windows (PR#349)
Message-ID: <E17HiTA-0000ql-00@usw-sf-web2.sourceforge.net>

Bugs item #210655, was opened at 2000-07-31 21:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210655&group_id=5470

Category: None
Group: Platform-specific
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Mark Hammond (mhammond)
Summary: getpass.getpass on Windows (PR#349)

Initial Comment:
Jitterbug-Id: 349
Submitted-By: ctalley@caci.com
Date: Thu,  8 Jun 2000 15:52:19 -0400 (EDT)
Version: 1.5.2
OS: W95


When using this code, the third line is skipped.  That is, the prompt
appears, but the program doesn't pause to accept input data.  It goes
right to the fourth line and pauses there.  I end up with a null string
for "fromaddr".

username=raw_input('Enter FTP server account username: ')
password=getpass.getpass('Enter FTP server account password: ')
fromaddr=raw_input('Enter your e-mail address: ')
toaddr=raw_input('Enter e-mail address for notification: ')

When using this code, everything works (although echo of the
password isn't suppressed.)

username=raw_input('Enter FTP server account username: ')
password=raw_input('Enter FTP server account password: ')
fromaddr=raw_input('Enter your e-mail address: ')
toaddr=raw_input('Enter e-mail address for notification: ')

The difference between the two code segments is that the first uses
the getpass method on the second line and the second uses raw_input.
What I think is happening is that getpass is leaving some garbage
in a buffer somewhere which is seen by raw_input as data.  raw_input
happily accepts the data and goes to the next line.  I've devised
several workarounds including "flush_input_buffer=raw_input('')"
immediately following the call to getpass.  It's ugly, but it works.

Thanks,
Carl Talley



====================================================================
Audit trail:
Tue Jul 11 08:25:59 2000	guido	moved from incoming to open

----------------------------------------------------------------------

Comment By: Allan Crooks (amc1)
Date: 2002-06-11 10:01

Message:
Logged In: YES 
user_id=39733

I've currently written a module which attempts to fix this 
problem, which you can get from here: 
http://ccec.sf.net/getpassfix.html

However, as I've mentioned in the documentation, it is a hack, 
but the "platform" based solution should become a more 
suitable candidate as it is tested.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-09-14 09:05

Message:
Mark, I assigned this to you on the chance you know a better trick.  Note that I already closed it as "Won't Fix", so if you *don't* know a better trick you don't have to do anything here.


This can't be fixed on Windows.  As the MS docs say, "The console I/O routines are not compatible with stream I/O or low-level I/O library routines", and getpass uses the console I/O routines on Windows.  Mixing console I/O with C stdio is undefined, and C stdio doesn't provide a way to do non-echo'ing input itself.

About the best you can do is to define your own raw_input variant that uses console I/O too.  For example,

def phony_raw_input(prompt=""):
    from msvcrt import putch, getche
    for ch in prompt:
        putch(ch)
    s = ""
    while 1:
        c = getche()
        if c in "\r\n":
            break
        elif c == '\003':
            raise KeyboardInterrupt
        elif c == '\b':
            s = s[:-1]
        else:
            s = s + c
    putch('\r')
    putch('\n')
    return s

Use phony_raw_input instead of raw_input in your example and it will work as you hoped.  It may screw up the *next* read from stdin, though!  All of the keyboard buffer, MS-DOS buffer, and stdio buffers get mixed into this, and MS doesn't define or guarantee the way all those interact across Windows flavors.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-13 10:23

Message:
Confirmed with Python 2.0b1 on Win98SE.
The bug does not occur on Linux.
Tim, the getpass code for Windows is different than on Unix, so please have a look!

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-07 22:04

Message:
Please do triage on this bug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210655&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 12:02:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 04:02:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-565747 ] crash on gethostbyaddr
Message-ID: <E17HjQ2-0001b1-00@usw-sf-web2.sourceforge.net>

Bugs item #565747, was opened at 2002-06-07 02:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565747&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Joerg Beyer (jbeyer)
Assigned to: Martin v. Löwis (loewis)
Summary: crash on gethostbyaddr

Initial Comment:
if python is compiled with --disable-ipv6, AND the
host has ipv6 enabled. Then calling

python2.2 -c "import socket; print
socket.gethostbyaddr('::0')"

you get a

Segmentation fault

This is caused by Python copying the V6 information
returned by the OS into the V4 struct of Python.See the
attached diff for socketmodule.c for a fix.

Alternatively, one could move the memcpy at the end of
setipaddr() into the switch, so that if the system
returns "unknown address family", the invalid copy is
not executed.

----------------------------------------------------------------------

>Comment By: Joerg Beyer (jbeyer)
Date: 2002-06-11 03:02

Message:
Logged In: YES 
user_id=103570

Martin, I took your fix and changed the "sizeof(addr)" to
"sizeof(*addr)" ot the explicit type. With this combined
patch my testcases work again. 

./python -c "import urllib;
urllib.urlopen('https://kalender.web.de/').read(256)"

(of course, you could use any rechable ssl webserver)

Could you test my testcase with your version? If it fails,
could you
test the "socketmodule.c.diff2" patch?


Thanks for your help.

    Joerg

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-10 21:45

Message:
Logged In: YES 
user_id=21627

Sorry about that; the patch is attached now.

----------------------------------------------------------------------

Comment By: Jürgen Hermann (jhermann)
Date: 2002-06-09 03:34

Message:
Logged In: YES 
user_id=39128

Martin,  the attachment didn't make it to the system, it seems.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 01:04

Message:
Logged In: YES 
user_id=21627

Jürgen, can you please try the attached sock.diff? This is a
slightly corrected version of Jörg's patch (IMO). I could
not observe the problem you've seen with Jörg's patch on a
SuSE 8.0 installation.

As for IPv6 not working on a SuSE 7.0 system: This is very
possible. Python requires the RFC2553 API, it might be that
this was not available in the glibc version that shipped
with SuSE 7.0.

----------------------------------------------------------------------

Comment By: Jürgen Hermann (jhermann)
Date: 2002-06-07 06:24

Message:
Logged In: YES 
user_id=39128

We found out a little more: after applying the fix, we get
"unsupported address family" exceptions for IPV6 addresses,
but also we cannot open sockets any more ("could not
connect" exceptions by urllib for any URL). So the fix is
not complete. BTW, the bug appears with Python 2.2, Python
2.0 and 2.1 _do_ work on the same machine.

Another piece of information: we tried to --enable-ipv6 on
that machine (SuSE 7.0, gcc 2.9.95), and got this:

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I./Include -DHAVE_CONFIG_H
-DUSE_SSL -I/netsite/include -I/netsite/include/openssl -c
./Modules/socketmodul

./Modules/socketmodule.c: In function `makesockaddr':
./Modules/socketmodule.c:733: structure has no member named
`sin6_scope_id'
./Modules/socketmodule.c: In function `getsockaddrarg':
./Modules/socketmodule.c:846: structure has no member named
`sin6_scope_id'
./Modules/socketmodule.c: In function `PySocket_getnameinfo':
./Modules/socketmodule.c:2598: structure has no member named
`sin6_scope_id'
make: *** [Modules/socketmodule.o] Error 1 

Don't know whether that is SuSE 7.0's fault.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565747&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 13:08:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 05:08:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-567374 ] os.stat() can't handle unicode filenames
Message-ID: <E17HkS3-0002P4-00@usw-sf-web1.sourceforge.net>

Bugs item #567374, was opened at 2002-06-11 13:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567374&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Andy Jewell (cybervegan)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.stat() can't handle unicode filenames

Initial Comment:
OS: Windows NT(WP)

Idle version info string: "Python 2.1.3 (#35, Apr  8 2002, 
17:47:50) [MSC 32 bit (Intel)] on win32"

Error Message: "OSError: [Errno 2] No such file or 
directory: 'r:/doobery\xa3.FM3' "

Any calls with filenames containing unicode characters 
to os.* library functions that in turn use os.stat() fail 
with 'Fiile or directory does not exist' errors.

This happens on local drives, windows shares and novell 
mapped drives, and seems to afflict even DOS 8.3 
filenames.

For example, the pound stirling sign (£) causes this 
problem.

I've tried tracing module os through to the stat() 
definition, but found that it's in a module named nt, 
which I can't find!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567374&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 13:10:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 05:10:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-567376 ] __imul__ broken for new-style classes
Message-ID: <E17HkU0-0002OQ-00@usw-sf-web2.sourceforge.net>

Bugs item #567376, was opened at 2002-06-11 07:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567376&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
Summary: __imul__ broken for new-style classes

Initial Comment:
Taken from python-list:

From: Alexander Schmolck <a.schmolck@gmx.net>:
-----

OK, after unsuccessfully trying for about half an hour to 
submit this to the
sf bug tracker, I gave up:

class Breaky(object):
    def __imul__(self, other):
        print "imuling"
        return self
sq = Breaky()
sq *=1.

gives:

Traceback (most recent call last):[...] line 10, in ?
    sq *=1.
TypeError: can't multiply sequence to non-int

Unless I'm overlooking something, this is a fairly serious 
bug and I can't see
a way to work around it (getattribute would presumably 
work, but slow
everything down unacceptably, so the only 'solution' 
seems to be to have no
inplace-multiplication).

I had the same behavior on two different machines 
(running Mandrake 8.2 and
Suse 7.3).

alex

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567376&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 13:13:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 05:13:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-567376 ] __imul__ broken for new-style classes
Message-ID: <E17HkWs-0002QD-00@usw-sf-web2.sourceforge.net>

Bugs item #567376, was opened at 2002-06-11 07:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567376&group_id=5470

Category: None
Group: None
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
Summary: __imul__ broken for new-style classes

Initial Comment:
Taken from python-list:

From: Alexander Schmolck <a.schmolck@gmx.net>:
-----

OK, after unsuccessfully trying for about half an hour to 
submit this to the
sf bug tracker, I gave up:

class Breaky(object):
    def __imul__(self, other):
        print "imuling"
        return self
sq = Breaky()
sq *=1.

gives:

Traceback (most recent call last):[...] line 10, in ?
    sq *=1.
TypeError: can't multiply sequence to non-int

Unless I'm overlooking something, this is a fairly serious 
bug and I can't see
a way to work around it (getattribute would presumably 
work, but slow
everything down unacceptably, so the only 'solution' 
seems to be to have no
inplace-multiplication).

I had the same behavior on two different machines 
(running Mandrake 8.2 and
Suse 7.3).

alex

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567376&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 13:13:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 05:13:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-567376 ] __imul__ broken for new-style classes
Message-ID: <E17HkX6-0002QJ-00@usw-sf-web2.sourceforge.net>

Bugs item #567376, was opened at 2002-06-11 07:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567376&group_id=5470

Category: None
Group: None
Status: Deleted
Resolution: None
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
Summary: __imul__ broken for new-style classes

Initial Comment:
Taken from python-list:

From: Alexander Schmolck <a.schmolck@gmx.net>:
-----

OK, after unsuccessfully trying for about half an hour to 
submit this to the
sf bug tracker, I gave up:

class Breaky(object):
    def __imul__(self, other):
        print "imuling"
        return self
sq = Breaky()
sq *=1.

gives:

Traceback (most recent call last):[...] line 10, in ?
    sq *=1.
TypeError: can't multiply sequence to non-int

Unless I'm overlooking something, this is a fairly serious 
bug and I can't see
a way to work around it (getattribute would presumably 
work, but slow
everything down unacceptably, so the only 'solution' 
seems to be to have no
inplace-multiplication).

I had the same behavior on two different machines 
(running Mandrake 8.2 and
Suse 7.3).

alex

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567376&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 13:14:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 05:14:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-567376 ] __imul__ broken for new-style classes
Message-ID: <E17HkXm-0002Qz-00@usw-sf-web2.sourceforge.net>

Bugs item #567376, was opened at 2002-06-11 07:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567376&group_id=5470

Category: None
Group: None
Status: Deleted
>Resolution: Duplicate
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
Summary: __imul__ broken for new-style classes

Initial Comment:
Taken from python-list:

From: Alexander Schmolck <a.schmolck@gmx.net>:
-----

OK, after unsuccessfully trying for about half an hour to 
submit this to the
sf bug tracker, I gave up:

class Breaky(object):
    def __imul__(self, other):
        print "imuling"
        return self
sq = Breaky()
sq *=1.

gives:

Traceback (most recent call last):[...] line 10, in ?
    sq *=1.
TypeError: can't multiply sequence to non-int

Unless I'm overlooking something, this is a fairly serious 
bug and I can't see
a way to work around it (getattribute would presumably 
work, but slow
everything down unacceptably, so the only 'solution' 
seems to be to have no
inplace-multiplication).

I had the same behavior on two different machines 
(running Mandrake 8.2 and
Suse 7.3).

alex

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567376&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 13:33:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 05:33:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-567374 ] os.stat() can't handle unicode filenames
Message-ID: <E17HkqV-0002iS-00@usw-sf-web1.sourceforge.net>

Bugs item #567374, was opened at 2002-06-11 13:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567374&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Andy Jewell (cybervegan)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.stat() can't handle unicode filenames

Initial Comment:
OS: Windows NT(WP)

Idle version info string: "Python 2.1.3 (#35, Apr  8 2002, 
17:47:50) [MSC 32 bit (Intel)] on win32"

Error Message: "OSError: [Errno 2] No such file or 
directory: 'r:/doobery\xa3.FM3' "

Any calls with filenames containing unicode characters 
to os.* library functions that in turn use os.stat() fail 
with 'Fiile or directory does not exist' errors.

This happens on local drives, windows shares and novell 
mapped drives, and seems to afflict even DOS 8.3 
filenames.

For example, the pound stirling sign (£) causes this 
problem.

I've tried tracing module os through to the stat() 
definition, but found that it's in a module named nt, 
which I can't find!

----------------------------------------------------------------------

>Comment By: Andy Jewell (cybervegan)
Date: 2002-06-11 13:33

Message:
Logged In: YES 
user_id=561310

This is not a bug.

Binary floating point cannot represent decimal fractions exactly,
so some rounding always occurs (even in Python 1.5.2).

What changed is that Python 2.0 shows more precision than before
in certain circumstances (repr() and the interactive prompt). 

You can use str() or print to get the old, rounded output: 

>>> print 0.1+0.1
0.2
>>>

Follow the link for more information:

http://www.python.org/doc/2.2.1/tut/node14.html

----------------------------------------------------------------------

Comment By: Andy Jewell (cybervegan)
Date: 2002-06-11 13:33

Message:
Logged In: YES 
user_id=561310

Further investigation reveals that it's probably NOT a unicode 
problem - \xa3 is the escaped encoding for ASCII character 
163, the £ symbol. 

Maybe stat is just not converting escapes to their character 
equivalents?

Maybe os.path.listdir() shouldn't be escape-encoding non-
ascii characters?

MAYBE USERS SHOULDN'T USE DUMB FILENAMES :-)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567374&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 14:41:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 06:41:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-567374 ] os.stat() can't handle unicode filenames
Message-ID: <E17HluE-0002rc-00@usw-sf-web3.sourceforge.net>

Bugs item #567374, was opened at 2002-06-11 13:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567374&group_id=5470

Category: Python Library
Group: Python 2.1.2
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Andy Jewell (cybervegan)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.stat() can't handle unicode filenames

Initial Comment:
OS: Windows NT(WP)

Idle version info string: "Python 2.1.3 (#35, Apr  8 2002, 
17:47:50) [MSC 32 bit (Intel)] on win32"

Error Message: "OSError: [Errno 2] No such file or 
directory: 'r:/doobery\xa3.FM3' "

Any calls with filenames containing unicode characters 
to os.* library functions that in turn use os.stat() fail 
with 'Fiile or directory does not exist' errors.

This happens on local drives, windows shares and novell 
mapped drives, and seems to afflict even DOS 8.3 
filenames.

For example, the pound stirling sign (£) causes this 
problem.

I've tried tracing module os through to the stat() 
definition, but found that it's in a module named nt, 
which I can't find!

----------------------------------------------------------------------

>Comment By: Andy Jewell (cybervegan)
Date: 2002-06-11 14:41

Message:
Logged In: YES 
user_id=561310

Ok, I feel stupid now.  I've just done some more testing: this 
seems to be a bug in MS Novell Client.  When I tried it on 
another m/c with the Novell Client for XP, it seems to work!

Typical of MS to throw a spanner in the works!

----------------------------------------------------------------------

Comment By: Andy Jewell (cybervegan)
Date: 2002-06-11 13:33

Message:
Logged In: YES 
user_id=561310

This is not a bug.

Binary floating point cannot represent decimal fractions exactly,
so some rounding always occurs (even in Python 1.5.2).

What changed is that Python 2.0 shows more precision than before
in certain circumstances (repr() and the interactive prompt). 

You can use str() or print to get the old, rounded output: 

>>> print 0.1+0.1
0.2
>>>

Follow the link for more information:

http://www.python.org/doc/2.2.1/tut/node14.html

----------------------------------------------------------------------

Comment By: Andy Jewell (cybervegan)
Date: 2002-06-11 13:33

Message:
Logged In: YES 
user_id=561310

Further investigation reveals that it's probably NOT a unicode 
problem - \xa3 is the escaped encoding for ASCII character 
163, the £ symbol. 

Maybe stat is just not converting escapes to their character 
equivalents?

Maybe os.path.listdir() shouldn't be escape-encoding non-
ascii characters?

MAYBE USERS SHOULDN'T USE DUMB FILENAMES :-)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567374&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 14:42:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 06:42:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-565414 ] urllib FancyURLopener.__init__ / urlopen
Message-ID: <E17HluO-0003Qz-00@usw-sf-web1.sourceforge.net>

Bugs item #565414, was opened at 2002-06-06 12:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565414&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: urllib FancyURLopener.__init__ / urlopen

Initial Comment:
Fred, you changed line 69 in urllib.py to call
FancyURLopener()
with kwargs, but the constructor (line 538) doesn't
accept **kwargs.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-11 09:42

Message:
Logged In: YES 
user_id=33168

No problem, checked in as urllib.py 1.148.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 15:28

Message:
Logged In: YES 
user_id=6380

Neal, the fix is to add support for kwargs in
FancyURLOpener.__init__, and to pass it on? You can check
this in yourself.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565414&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 18:00:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 10:00:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-473985 ] str, __getitem__ and slices
Message-ID: <E17Hp09-0005Da-00@usw-sf-web1.sourceforge.net>

Bugs item #473985, was opened at 2001-10-23 06:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=473985&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: Remind
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Guido van Rossum (gvanrossum)
Summary: str, __getitem__ and slices

Initial Comment:
Using slices with __getitem__ doesn't work with 
classes derived from str:
---
class S(str):
   def __getitem__(self, index):
      print "getitem", index
      return str.__getitem__(self, index)
   def __setitem__(self, index, value):
      print "setitem", index, value

s = S("foo")
print s[0]
print s[0:2]
s[0] = "b"
s[0:2] = "bar"
---
This prints:
---
getitem 0
f
fo
setitem 0 b
setitem slice(0, 2, None) bar
---
instead of
---
getitem 0
f
getitem slice(0, 2, None)
fo
setitem 0 b
setitem slice(0, 2, None) bar
---
i.e. when no __getslice__ is defined s[0:2] will not 
be forwarded to __getitem__, but it seems to work for 
__setitem__.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-11 13:00

Message:
Logged In: YES 
user_id=6380

Um, that patch doesn't change the fact that strings have a 
__getslice__ method. Maybe that can be thrown out now 
though? str.__getitem__ now supports slice objects, so 
there's no need to have __getslice__ as well.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-03 17:01

Message:
Logged In: YES 
user_id=6380

See (revived) patch 400998?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:45

Message:
Logged In: YES 
user_id=6380

Raising the priority slightly and marking as a 2.3 issue.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-10-23 10:50

Message:
Logged In: YES 
user_id=6380

I've thought about this some more.

It should be fixed, but the fix is complex, and think I'd
rather not make this change in 2.2 -- (1) I have little
time, and (2) we've already issued a beta release and a
declared a feature freeze. So I'd like to put this on hold
until I can start working on 2.3. This is what would have to
be done:

- Change all built-in sequence types to get rid of the
sq_slice and sq_ass_slice dispatch functions; instead, add a
mapping extension to these types and add mp_subscript and
mp_ass_subscript dispatch functions that recognize slice
objects.

- We'd probably also have to get rid of the sq_item and
sq_ass_item dispatch functions, to roll them into
mp_subscript and mp_ass_subscript.

- Possibly, the whole "PySequenceMethods" structure should
be deprecated; all the operations there are overloading
either numerical or mapping operations.

Extension types that define a sequence methods structure
should continue to work, but the recommendation would be to
migrate these out.

I wish I could do this in 2.2, but it's really too much work
to start now, *and* it would be a serious incompatibility
between 2.2b1 and 2.2b2.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-10-23 10:05

Message:
Logged In: YES 
user_id=89016

Oops, this wasn't meant to be a patch. Should have gone 
into the bugs category.

The problems is that http://python.sourceforge.net/devel-
docs/ref/sequence-methods.html says, that __getslice__ 
is "Deprecated since release 2.0", so the user will want to 
implement __getslice__ via __getitem__.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-10-23 09:48

Message:
Logged In: YES 
user_id=6380

I don't think this is a bug. S inherits __getslice__ from
the str base class, but since str is immutable, it doesn't
define a __setslice__ to inherit for S.

BTW I'm reclassifying this as a bug, not a patch. This will
unfortunately invalidate the old URL you had for this entry
(SF doesn't really like reclassification that much.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=473985&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 19:51:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 11:51:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-567538 ] Generator can crash the interpreter.
Message-ID: <E17HqkB-0005l3-00@usw-sf-web3.sourceforge.net>

Bugs item #567538, was opened at 2002-06-11 20:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567538&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Finn Bock (bckfnn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Generator can crash the interpreter.

Initial Comment:
Tested with:

Python 2.3a0 (#4, Jun 11 2002, 13:35:00)
[GCC 2.95.3-5 (cygwin special)] on cygwin

and with:

Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit
(Intel)] on win32

Running the example cause a hard crash (seg fault).


Python 2.3a0 (#4, Jun 11 2002, 13:35:00)
[GCC 2.95.3-5 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> from __future__ import generators
>>>
>>> def f():
...     for i in range(3):
...         try:
...             continue
...         finally:
...             yield 1
...
>>> g = f()
>>> print g.next()
1
>>> print g.next()
Segmentation fault (core dumped)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567538&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 20:38:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 12:38:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-567568 ] future division broken w/ PYTHONSTARTUP
Message-ID: <E17HrSt-00073M-00@usw-sf-web1.sourceforge.net>

Bugs item #567568, was opened at 2002-06-11 12:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567568&group_id=5470

Category: Parser/Compiler
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: TEd Drain (teddrain)
Assigned to: Nobody/Anonymous (nobody)
Summary: future division broken w/ PYTHONSTARTUP

Initial Comment:
Version: 2.2.1
Compiler: gcc 2.95.3
Platform: linux (2.4 kernel)

If I create a file startup.py:
from __future__ import division
a = 1/2
print a

then setenv PYTHONSTARTUP startup.py
and launch python, it prints 0.5 like it should and the
variable a is available to me.  But, the future
division is not propagated to the interpreter.

~: setenv PYTHONSTARTUP startup.py
~: python
Python 2.2.1 (#1, May 16 2002, 16:10:22)
[GCC 2.95.3 20010315 (release)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
0.5
>>> print a
0.5
>>> 1/2
0
It looks like the compiler flags from the PYTHONSTARTUP
file are not be passed to the interpreter. 




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567568&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 20:54:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 12:54:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-567576 ] tarball to untar into a single dir
Message-ID: <E17HrjH-00071i-00@usw-sf-web2.sourceforge.net>

Bugs item #567576, was opened at 2002-06-11 14:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567576&group_id=5470

Category: Documentation
Group: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: andrei kulakov (rainy)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: tarball to untar into a single dir

Initial Comment:
Python documentation tarball untars into many dirs and
files. Unix programs and archives usually untar into
one dir so as not to clutter ~user when untarred there.
Please fix!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567576&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 21:23:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 13:23:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-567605 ] setup.py ignores env and uses wrong libs
Message-ID: <E17HsB9-0007dc-00@usw-sf-web1.sourceforge.net>

Bugs item #567605, was opened at 2002-06-11 22:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567605&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Marc Lehmann (pcg)
Assigned to: Nobody/Anonymous (nobody)
Summary: setup.py ignores env and uses wrong libs

Initial Comment:
tcl/tk and lot's of other libs reside in /opt/lib and
/opt/include on my system. CPPFLAGS and LDFLAGS reflect
this. python doesn't find anything in /opt, though, as
setup.py completely ignores this.

To debug this, I added a print libdirs after the line:

        lib_dirs = self.compiler.library_dirs +
['/lib', '/usr/lib']

and found that "lib_dirs" contains "/usr/local/lib",
which is completely bogus (but not wrong) (prefix is
/opt/python, my compiler doesn't search for /usr/local
etc.), "/lib" and "/usr/lib".

My system:

linux (2.4), glibc-2.2.5, every package is in
/opt/packagename, symlinked to common subdirs in
/opt/lib etc,,

LDFLAGS=-L/usr/app/lib -L/opt/lib
CPPFLAGS=-I/usr/app/include -I/opt/include
CFLAGS=-O3 -g -pipe -march=pentium -mcpu=pentiumpro
-momit-leaf-frame-pointer



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567605&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 21:26:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 13:26:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-567607 ] whatsnew explains noargs incorrectly
Message-ID: <E17HsE0-0006td-00@usw-sf-web4.sourceforge.net>

Bugs item #567607, was opened at 2002-06-11 22:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567607&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: A.M. Kuchling (akuchling)
Summary: whatsnew explains noargs incorrectly

Initial Comment:
http://www.python.org/dev/doc/devel/whatsnew/node8.html

says that PyArg_NoArgs is deprectated and that
ParseTuple should be used instead. I believe that the
recommendations should be to use METH_NOARGS instead.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567607&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 21:28:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 13:28:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-567605 ] setup.py ignores env and uses wrong libs
Message-ID: <E17HsFg-0006vY-00@usw-sf-web4.sourceforge.net>

Bugs item #567605, was opened at 2002-06-11 22:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567605&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Marc Lehmann (pcg)
Assigned to: Nobody/Anonymous (nobody)
Summary: setup.py ignores env and uses wrong libs

Initial Comment:
tcl/tk and lot's of other libs reside in /opt/lib and
/opt/include on my system. CPPFLAGS and LDFLAGS reflect
this. python doesn't find anything in /opt, though, as
setup.py completely ignores this.

To debug this, I added a print libdirs after the line:

        lib_dirs = self.compiler.library_dirs +
['/lib', '/usr/lib']

and found that "lib_dirs" contains "/usr/local/lib",
which is completely bogus (but not wrong) (prefix is
/opt/python, my compiler doesn't search for /usr/local
etc.), "/lib" and "/usr/lib".

My system:

linux (2.4), glibc-2.2.5, every package is in
/opt/packagename, symlinked to common subdirs in
/opt/lib etc,,

LDFLAGS=-L/usr/app/lib -L/opt/lib
CPPFLAGS=-I/usr/app/include -I/opt/include
CFLAGS=-O3 -g -pipe -march=pentium -mcpu=pentiumpro
-momit-leaf-frame-pointer



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-11 22:28

Message:
Logged In: YES 
user_id=21627

I don't think this is a bug. If you use a certain
configuration not supported by setup.py, you need to edit
Modules/Setup manually.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567605&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 21:56:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 13:56:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-567568 ] future division broken w/ PYTHONSTARTUP
Message-ID: <E17HsgV-0008Ps-00@usw-sf-web1.sourceforge.net>

Bugs item #567568, was opened at 2002-06-11 15:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567568&group_id=5470

Category: Parser/Compiler
Group: Python 2.2.1
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: TEd Drain (teddrain)
Assigned to: Nobody/Anonymous (nobody)
Summary: future division broken w/ PYTHONSTARTUP

Initial Comment:
Version: 2.2.1
Compiler: gcc 2.95.3
Platform: linux (2.4 kernel)

If I create a file startup.py:
from __future__ import division
a = 1/2
print a

then setenv PYTHONSTARTUP startup.py
and launch python, it prints 0.5 like it should and the
variable a is available to me.  But, the future
division is not propagated to the interpreter.

~: setenv PYTHONSTARTUP startup.py
~: python
Python 2.2.1 (#1, May 16 2002, 16:10:22)
[GCC 2.95.3 20010315 (release)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
0.5
>>> print a
0.5
>>> 1/2
0
It looks like the compiler flags from the PYTHONSTARTUP
file are not be passed to the interpreter. 




----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-06-11 16:56

Message:
Logged In: YES 
user_id=31435

Not a bug.  All .py files are distinct modules, whether or not 
run at startup, and the effect of a future statement is 
limited to the module in which it appears.  There is no way 
to make a future statement (division or otherwise) apply 
globally.

For the specific case of future division, you can try the 
experimental -Qnew command-line argument.  As the PEP 
says, this isn't recommended yet, but I do it <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567568&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 22:03:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 14:03:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-567538 ] Generator can crash the interpreter.
Message-ID: <E17Hsn9-0008PK-00@usw-sf-web2.sourceforge.net>

Bugs item #567538, was opened at 2002-06-11 14:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567538&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Finn Bock (bckfnn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Generator can crash the interpreter.

Initial Comment:
Tested with:

Python 2.3a0 (#4, Jun 11 2002, 13:35:00)
[GCC 2.95.3-5 (cygwin special)] on cygwin

and with:

Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit
(Intel)] on win32

Running the example cause a hard crash (seg fault).


Python 2.3a0 (#4, Jun 11 2002, 13:35:00)
[GCC 2.95.3-5 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> from __future__ import generators
>>>
>>> def f():
...     for i in range(3):
...         try:
...             continue
...         finally:
...             yield 1
...
>>> g = f()
>>> print g.next()
1
>>> print g.next()
Segmentation fault (core dumped)

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-11 17:03

Message:
Logged In: YES 
user_id=6380

I'll have a look at this.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567538&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 22:06:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 14:06:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-567568 ] future division broken w/ PYTHONSTARTUP
Message-ID: <E17Hsqp-0007vT-00@usw-sf-web4.sourceforge.net>

Bugs item #567568, was opened at 2002-06-11 12:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567568&group_id=5470

Category: Parser/Compiler
Group: Python 2.2.1
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: TEd Drain (teddrain)
Assigned to: Nobody/Anonymous (nobody)
Summary: future division broken w/ PYTHONSTARTUP

Initial Comment:
Version: 2.2.1
Compiler: gcc 2.95.3
Platform: linux (2.4 kernel)

If I create a file startup.py:
from __future__ import division
a = 1/2
print a

then setenv PYTHONSTARTUP startup.py
and launch python, it prints 0.5 like it should and the
variable a is available to me.  But, the future
division is not propagated to the interpreter.

~: setenv PYTHONSTARTUP startup.py
~: python
Python 2.2.1 (#1, May 16 2002, 16:10:22)
[GCC 2.95.3 20010315 (release)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
0.5
>>> print a
0.5
>>> 1/2
0
It looks like the compiler flags from the PYTHONSTARTUP
file are not be passed to the interpreter. 




----------------------------------------------------------------------

>Comment By: TEd Drain (teddrain)
Date: 2002-06-11 14:06

Message:
Logged In: YES 
user_id=561567

The problem with the statement is that the startup script is
NOT a separate module.  If it was, variables defined in it
and modules (other that future) would not be in the main
interpreter module when I startup.

It's very confusing to me that if I add 'import sys' to the
startup script, it will make the sys module available
automatically.  So this means import future has a different
behavior than any other import.  Why should import future
behave completely differently that import module or variable
declarations?  I think it would make a lot more sense if
import behaved the same regardless of the arguments in the
startup script.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-11 13:56

Message:
Logged In: YES 
user_id=31435

Not a bug.  All .py files are distinct modules, whether or not 
run at startup, and the effect of a future statement is 
limited to the module in which it appears.  There is no way 
to make a future statement (division or otherwise) apply 
globally.

For the specific case of future division, you can try the 
experimental -Qnew command-line argument.  As the PEP 
says, this isn't recommended yet, but I do it <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567568&group_id=5470



From noreply@sourceforge.net  Tue Jun 11 22:09:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 14:09:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-513033 ] unsafe call to PyThreadState_Swap
Message-ID: <E17HstZ-00007E-00@usw-sf-web2.sourceforge.net>

Bugs item #513033, was opened at 2002-02-04 16:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=513033&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Jake McGuire (jamcguir)
Assigned to: Guido van Rossum (gvanrossum)
Summary: unsafe call to PyThreadState_Swap

Initial Comment:
It appears that there is a blatantly unsafe call to 
PyThreadState_Swap in the functions on_hook and 
on_completer in Modules/Readline.c

The diff adding these calls is viewable at 
http://cvs.sourceforge.net/cgi-
bin/viewcvs.cgi/python/python/dist/src/Modules/readline
.c.diff?r1=2.5&r2=2.6&only_with_tag=MAIN

The call to PyThreadState_Swap is added directly below 
a comment pointing out that readline() is called with 
the interpreter lock released.  Viewing the code shows 
that the interpreter lock is indeed released before 
calling readline (in myreadline.c).

Multithreaded programs that define callback functions 
suffer from intermittent crashes, often Py_FatalError-
ing claiming "tstate mix-up" from ceval.c

Removing the calls to PyThreadState_Swap makes these 
problems go away.

Can someone explain how the call to PyThreadState_Swap 
is indeed the right thing to be doing?

----------------------------------------------------------------------

Comment By: Stephan A. Terre (sfiedler)
Date: 2002-06-11 14:09

Message:
Logged In: YES 
user_id=246063

Just wanted to note that this problem is affecting my users
as well, I believe in the on_completion branch rather than
the on_hook branch. We're using Python to write
multi-threaded scientific applications; with other Python
threads active, pressing TAB for interactive completion
occasionally yields the tstate mix-up.

We are perfectly happy to wait for Python 2.3 for a fix.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-17 20:15

Message:
Logged In: YES 
user_id=6380

That's ancient history and will take some time to wrap my
brains around. I don't have time for this tonight, maybe
tomorrow but I doubt the priority can be raised enough to
catch my attention long enough to matter. But it should be
fixed for 2.3.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-16 10:40

Message:
Logged In: YES 
user_id=6656

jamcguir (or indeed anyone else), can you provide a patch
for this pronto?  I'd kind of like to have it fixed in
2.2.1, but this is obscure enough that I'm not going to hold
up the release for it.

----------------------------------------------------------------------

Comment By: Jake McGuire (jamcguir)
Date: 2002-02-04 16:55

Message:
Logged In: YES 
user_id=448911

Unfortunately, the scenario isn't really *simple*.

I think it goes like this:

Thread A defines a readline startup hook.
Thread A calls PyOS_Readline() in myreadline.c
Thread A calls Py_BEGIN_ALLOW_THREADS, saving its thread 
state and setting the global thread state to NULL.
Thread A calls readline.
Thread A gets blocked, and Thread B gets scheduled.
Thread B grabs the global interpreter lock, and restores 
its thread state.
Thread B gets suspended, and Thread A gets scheduled.
-- note: Thread B has the intepreter lock --
Thread A calls PyThreadState_Swap in on_hook(), setting the 
current global thread state to NULL
Thread A calls PyEval_RestoreThread, which blocks waiting 
for the global interpreter lock
Thread B gets scheduled, tries to run, but finds that the 
global thread state is NULL.  Bad things happen.

Proposed solution:
Change Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS in 
myreadline.c:PyOS_Readline to calls to PyEval_SaveThread 
and PyEval_RestoreThread.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-04 16:41

Message:
Logged In: YES 
user_id=31435

Guido's checkin comment said:

"""
Darn.  When thread support is disabled, the BEGIN/END 
macros don't save and restore the tstate, but explicitly 
calling PyEval_SaveThread() does reset it!  While I think 
about how to fix this for real, here's a fix that avoids 
getting a fatal error.
"""

Therefore I assigned the bug to Guido <wink>.  It would 
help if you could describe a specific simple scenario that 
provokes the problems you're seeing.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=513033&group_id=5470



From noreply@sourceforge.net  Wed Jun 12 00:24:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 16:24:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-567568 ] future division broken w/ PYTHONSTARTUP
Message-ID: <E17Hv0D-0004A5-00@usw-sf-web2.sourceforge.net>

Bugs item #567568, was opened at 2002-06-11 15:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567568&group_id=5470

Category: Parser/Compiler
Group: Python 2.2.1
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: TEd Drain (teddrain)
Assigned to: Nobody/Anonymous (nobody)
Summary: future division broken w/ PYTHONSTARTUP

Initial Comment:
Version: 2.2.1
Compiler: gcc 2.95.3
Platform: linux (2.4 kernel)

If I create a file startup.py:
from __future__ import division
a = 1/2
print a

then setenv PYTHONSTARTUP startup.py
and launch python, it prints 0.5 like it should and the
variable a is available to me.  But, the future
division is not propagated to the interpreter.

~: setenv PYTHONSTARTUP startup.py
~: python
Python 2.2.1 (#1, May 16 2002, 16:10:22)
[GCC 2.95.3 20010315 (release)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
0.5
>>> print a
0.5
>>> 1/2
0
It looks like the compiler flags from the PYTHONSTARTUP
file are not be passed to the interpreter. 




----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-06-11 19:24

Message:
Logged In: YES 
user_id=31435

You have a point, but it's not going to help you.  startup.py 
acts as if executed via the execfile() function, which means 
it's a separate code block that uses the global namespace 
of its caller.  The effect of a future statement still can't 
escape the code block.  This isn't going to change unless 
someone wants to volunteer a crazy amout of work for a 
gimmick of minor value.

That "from __future__" acts differently from other 
statements that begin with "from" is akin to that "in" means 
different things depending on context too.  "from __future__ 
import division"  *is* an import statement in the sense that 
it does in fact fact install the name "division" in your global 
namespace, but that alone has no effect on semantics.  Its 
greater value is that affects compilation, but that only 
applies to code blocks containing it at the top.

Live with it <0.9 wink>.

----------------------------------------------------------------------

Comment By: TEd Drain (teddrain)
Date: 2002-06-11 17:06

Message:
Logged In: YES 
user_id=561567

The problem with the statement is that the startup script is
NOT a separate module.  If it was, variables defined in it
and modules (other that future) would not be in the main
interpreter module when I startup.

It's very confusing to me that if I add 'import sys' to the
startup script, it will make the sys module available
automatically.  So this means import future has a different
behavior than any other import.  Why should import future
behave completely differently that import module or variable
declarations?  I think it would make a lot more sense if
import behaved the same regardless of the arguments in the
startup script.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-11 16:56

Message:
Logged In: YES 
user_id=31435

Not a bug.  All .py files are distinct modules, whether or not 
run at startup, and the effect of a future statement is 
limited to the module in which it appears.  There is no way 
to make a future statement (division or otherwise) apply 
globally.

For the specific case of future division, you can try the 
experimental -Qnew command-line argument.  As the PEP 
says, this isn't recommended yet, but I do it <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567568&group_id=5470



From noreply@sourceforge.net  Wed Jun 12 04:46:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 20:46:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-567538 ] Generator can crash the interpreter.
Message-ID: <E17Hz5k-0007kn-00@usw-sf-web1.sourceforge.net>

Bugs item #567538, was opened at 2002-06-11 14:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567538&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Finn Bock (bckfnn)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Generator can crash the interpreter.

Initial Comment:
Tested with:

Python 2.3a0 (#4, Jun 11 2002, 13:35:00)
[GCC 2.95.3-5 (cygwin special)] on cygwin

and with:

Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit
(Intel)] on win32

Running the example cause a hard crash (seg fault).


Python 2.3a0 (#4, Jun 11 2002, 13:35:00)
[GCC 2.95.3-5 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> from __future__ import generators
>>>
>>> def f():
...     for i in range(3):
...         try:
...             continue
...         finally:
...             yield 1
...
>>> g = f()
>>> print g.next()
1
>>> print g.next()
Segmentation fault (core dumped)

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-11 23:46

Message:
Logged In: YES 
user_id=6380

I was afraid that this would be a major undertaking, but
while running the sample through the debugger, I noticed
that it was comparing the 'why' variable to CONTINUE_LOOP,
which isn't a why enum but an opcode. Replacing this with
WHY_CONTINUE fixed the problem. Added a testcase. Will fix
in 2.2 too.

Thanks for reporting!

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-11 17:03

Message:
Logged In: YES 
user_id=6380

I'll have a look at this.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567538&group_id=5470



From noreply@sourceforge.net  Wed Jun 12 04:54:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 20:54:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-566970 ] __imul__ broken for 'object's
Message-ID: <E17HzCr-0007uX-00@usw-sf-web1.sourceforge.net>

Bugs item #566970, was opened at 2002-06-10 12:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566970&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Alexander Schmolck (aschmolck)
Assigned to: Nobody/Anonymous (nobody)
Summary: __imul__ broken for 'object's

Initial Comment:
class Breaky(object):
    def __imul__(self, other):
        print "imuling"
        return self
sq = Breaky()
sq *=1.

gives:

Traceback (most recent call last):[...] line 10, in ?
    sq *=1.
TypeError: can't multiply sequence to non-int


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-11 22:54

Message:
Logged In: YES 
user_id=80475

Yes, it's a valid bug.
Yes, GvR already fixed it.

Verified that above code fails in 2.2 but runs fine in for 
2.2.2 and 2.3.

Closing bug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566970&group_id=5470



From noreply@sourceforge.net  Wed Jun 12 05:10:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 21:10:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-566037 ] Popen exectuion blocking w/threads
Message-ID: <E17HzT3-0007Az-00@usw-sf-web3.sourceforge.net>

Bugs item #566037, was opened at 2002-06-07 17:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566037&group_id=5470

Category: Threads
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 3
Submitted By: Martin Stoufer (mstoufer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Popen exectuion blocking w/threads

Initial Comment:
The following unit test hangs after the first two lines
of output. This is wholly reproducible (for us) under
2.2.1 and totaly unreproducible under 2.1. We have both
interpreters installed on a RH7.2 PC with linkings
against the apparent same /lib/libthread.so.0

import os, threading,time, sys
def read_output(self, cmd, timeout):
        print "run: %s" % cmd
        (inf,outf) = os.popen4(cmd)
        print "started! out_fd=%d" % outf.fileno()
        while 1:
            line = outf.readline()
            if line == "": break
            print len(line),line
            sys.stdout.flush()
        return
if __name__ == '__main__': 
    thr =
threading.Thread(target=read_output,args=(1,"ping -c 5
www.mit.edu",0))
    thr.start()
    print "Started thread"
    while 1: time.sleep(1)

mstoufer@dpsslx05(3)>ldd /usr/local/bin/python2.{1,2}
/usr/local/bin/python2.1:
	libpthread.so.0 => /lib/libpthread.so.0 (0x40029000)
	libdl.so.2 => /lib/libdl.so.2 (0x40040000)
	libutil.so.1 => /lib/libutil.so.1 (0x40044000)
	libstdc++-libc6.1-2.so.3 =>
/usr/local/lib/libstdc++-libc6.1-2.so.3 (0x40047000)
	libm.so.6 => /lib/libm.so.6 (0x4008f000)
	libc.so.6 => /lib/libc.so.6 (0x400b1000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
/usr/local/bin/python2.2:
	libdl.so.2 => /lib/libdl.so.2 (0x40029000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x4002d000)
	libutil.so.1 => /lib/libutil.so.1 (0x40044000)
	libm.so.6 => /lib/libm.so.6 (0x40047000)
	libc.so.6 => /lib/libc.so.6 (0x4006a000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

----------------------------------------------------------------------

Comment By: Martin Stoufer (mcstoufer)
Date: 2002-06-11 21:10

Message:
Logged In: YES 
user_id=243169

This same issue arises when any subprocess is declared that makes 
more than 1 network read/write. From the system side, the Ping process 
is simply sleeping; we feel that the process is looking for the pipe to 
empty so it can finish it's write to stdout.

Replacing cmd with 'ping -c 1  www.mit.edu' works everytime. 
Replacing cmd with 'echo\'Hello. world\'' works as well.

We have beeen using a therading model similar to this under 2.1 and it 
has been quite robust in its execution. Is it possible that this is a 
compile-time issue with the thread linking?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 12:39

Message:
Logged In: YES 
user_id=6380

Mixing forks and threads is often asking for trouble...

Does this also hang with another command that produces more
than two lines of output, or is it limited to ping?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 01:32

Message:
Logged In: YES 
user_id=21627

I can't reproduce this on a SuSE system, either (which has
glibc 2.2.5), so I'm tempted to declare it a glibc 2.1 bug.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-06-07 22:42

Message:
Logged In: YES 
user_id=14198

Just noting that current CVS Python works fine on Windows,
but also hangs on RH7.  My Linux debuggings skills are such
that I can offer no further help ;)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566037&group_id=5470



From noreply@sourceforge.net  Wed Jun 12 05:14:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 21:14:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-567826 ] new opcodes undocumented
Message-ID: <E17HzWS-0007Aa-00@usw-sf-web4.sourceforge.net>

Bugs item #567826, was opened at 2002-06-12 00:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567826&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: new opcodes undocumented

Initial Comment:
Manu new opcodes aren't documented in the section on
the dis module. E.g. CONTINUE_LOOP, GET_ITER,
YIELD_VALUE, etc. (A careful comparison of the module
to the dis source and/or opcode.h would be necessary to
find out all undocumented opcodes.)

I'm willing to help.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567826&group_id=5470



From noreply@sourceforge.net  Wed Jun 12 05:16:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 11 Jun 2002 21:16:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-566037 ] Popen exectuion blocking w/threads
Message-ID: <E17HzYN-0008Kb-00@usw-sf-web1.sourceforge.net>

Bugs item #566037, was opened at 2002-06-07 20:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566037&group_id=5470

Category: Threads
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 3
Submitted By: Martin Stoufer (mstoufer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Popen exectuion blocking w/threads

Initial Comment:
The following unit test hangs after the first two lines
of output. This is wholly reproducible (for us) under
2.2.1 and totaly unreproducible under 2.1. We have both
interpreters installed on a RH7.2 PC with linkings
against the apparent same /lib/libthread.so.0

import os, threading,time, sys
def read_output(self, cmd, timeout):
        print "run: %s" % cmd
        (inf,outf) = os.popen4(cmd)
        print "started! out_fd=%d" % outf.fileno()
        while 1:
            line = outf.readline()
            if line == "": break
            print len(line),line
            sys.stdout.flush()
        return
if __name__ == '__main__': 
    thr =
threading.Thread(target=read_output,args=(1,"ping -c 5
www.mit.edu",0))
    thr.start()
    print "Started thread"
    while 1: time.sleep(1)

mstoufer@dpsslx05(3)>ldd /usr/local/bin/python2.{1,2}
/usr/local/bin/python2.1:
	libpthread.so.0 => /lib/libpthread.so.0 (0x40029000)
	libdl.so.2 => /lib/libdl.so.2 (0x40040000)
	libutil.so.1 => /lib/libutil.so.1 (0x40044000)
	libstdc++-libc6.1-2.so.3 =>
/usr/local/lib/libstdc++-libc6.1-2.so.3 (0x40047000)
	libm.so.6 => /lib/libm.so.6 (0x4008f000)
	libc.so.6 => /lib/libc.so.6 (0x400b1000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
/usr/local/bin/python2.2:
	libdl.so.2 => /lib/libdl.so.2 (0x40029000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x4002d000)
	libutil.so.1 => /lib/libutil.so.1 (0x40044000)
	libm.so.6 => /lib/libm.so.6 (0x40047000)
	libc.so.6 => /lib/libc.so.6 (0x4006a000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-12 00:16

Message:
Logged In: YES 
user_id=6380

Anything is possible. I suggest asking for help in a Linux
threading guru forum.

----------------------------------------------------------------------

Comment By: Martin Stoufer (mcstoufer)
Date: 2002-06-12 00:10

Message:
Logged In: YES 
user_id=243169

This same issue arises when any subprocess is declared that makes 
more than 1 network read/write. From the system side, the Ping process 
is simply sleeping; we feel that the process is looking for the pipe to 
empty so it can finish it's write to stdout.

Replacing cmd with 'ping -c 1  www.mit.edu' works everytime. 
Replacing cmd with 'echo\'Hello. world\'' works as well.

We have beeen using a therading model similar to this under 2.1 and it 
has been quite robust in its execution. Is it possible that this is a 
compile-time issue with the thread linking?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 15:39

Message:
Logged In: YES 
user_id=6380

Mixing forks and threads is often asking for trouble...

Does this also hang with another command that produces more
than two lines of output, or is it limited to ping?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-09 04:32

Message:
Logged In: YES 
user_id=21627

I can't reproduce this on a SuSE system, either (which has
glibc 2.2.5), so I'm tempted to declare it a glibc 2.1 bug.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-06-08 01:42

Message:
Logged In: YES 
user_id=14198

Just noting that current CVS Python works fine on Windows,
but also hangs on RH7.  My Linux debuggings skills are such
that I can offer no further help ;)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566037&group_id=5470



From noreply@sourceforge.net  Wed Jun 12 09:21:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jun 2002 01:21:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-567892 ] Various Playstation 2 Linux Test Errors
Message-ID: <E17I3Ns-0004UG-00@usw-sf-web1.sourceforge.net>

Bugs item #567892, was opened at 2002-06-12 02:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567892&group_id=5470

Category: Installation
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Keith Thomson (kazriko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Various Playstation 2 Linux Test Errors

Initial Comment:
I recently downloaded Python 2.2.1 onto my Playstation 
2 with a linux kit installed. It uses a mipsel architecture, 
(mips endian-little) with a Linux 2.2.1 kernel (retrofitted 
with many backported stuff from later versions) and a 
glibc 2.2.2 i believe, also custom modified by SCEI.

Python compiled perfectly the first time, and installed 
flawlessly. On a whim, I decided to run python's testing 
suite. (make test)

The first pass crashed with this error. 

test_re
make: *** [test] Segmentation fault

i moved this test out of the folder to see if there were 
any other errors, and got the same one for test_sre.

After moving these two tests, i got the following results, 
including the lines from the failing tests.

test test_descr failed -- x=2, y=1
test test_linuxaudiodev failed -- (16, 'Device or resource 
busy', '/dev/dsp')
test test_userdict failed -- test failed
3 tests failed:
    test_descr test_linuxaudiodev test_userdict
18 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl 
test_imgfile
    test_largefile test_minidom test_nis test_ntpath 
test_pyexpat
    test_sax test_socket_ssl test_socketserver 
test_sunaudiodev
    test_winreg test_winsound
3 skips unexpected on linux2:
    test_minidom test_pyexpat test_sax

The linuxaudiodev actually gave me two different errors, 
no other audio programs were running at the time, so i'm 
suspecting a ps2sd bug on that one. but the other four 
tests I have not tried to isolate yet.

I'll keep at it, Would welcome any recommendations on 
places to look to diagnose these problems. 

This is probably a very-low priority thing, as PS2Linux is 
still a bit of a beta test thing, it would be nice if i could 
isolate this down to some bugs in ps2linux's libraries, so 
that we could fix them without mucking up the python 
code with ps2 stuff.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567892&group_id=5470



From noreply@sourceforge.net  Wed Jun 12 09:22:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jun 2002 01:22:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-567892 ] Various Playstation 2 Linux Test Errors
Message-ID: <E17I3Of-0004V8-00@usw-sf-web1.sourceforge.net>

Bugs item #567892, was opened at 2002-06-12 02:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567892&group_id=5470

Category: Installation
Group: Platform-specific
Status: Open
Resolution: None
>Priority: 1
Submitted By: Keith Thomson (kazriko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Various Playstation 2 Linux Test Errors

Initial Comment:
I recently downloaded Python 2.2.1 onto my Playstation 
2 with a linux kit installed. It uses a mipsel architecture, 
(mips endian-little) with a Linux 2.2.1 kernel (retrofitted 
with many backported stuff from later versions) and a 
glibc 2.2.2 i believe, also custom modified by SCEI.

Python compiled perfectly the first time, and installed 
flawlessly. On a whim, I decided to run python's testing 
suite. (make test)

The first pass crashed with this error. 

test_re
make: *** [test] Segmentation fault

i moved this test out of the folder to see if there were 
any other errors, and got the same one for test_sre.

After moving these two tests, i got the following results, 
including the lines from the failing tests.

test test_descr failed -- x=2, y=1
test test_linuxaudiodev failed -- (16, 'Device or resource 
busy', '/dev/dsp')
test test_userdict failed -- test failed
3 tests failed:
    test_descr test_linuxaudiodev test_userdict
18 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl 
test_imgfile
    test_largefile test_minidom test_nis test_ntpath 
test_pyexpat
    test_sax test_socket_ssl test_socketserver 
test_sunaudiodev
    test_winreg test_winsound
3 skips unexpected on linux2:
    test_minidom test_pyexpat test_sax

The linuxaudiodev actually gave me two different errors, 
no other audio programs were running at the time, so i'm 
suspecting a ps2sd bug on that one. but the other four 
tests I have not tried to isolate yet.

I'll keep at it, Would welcome any recommendations on 
places to look to diagnose these problems. 

This is probably a very-low priority thing, as PS2Linux is 
still a bit of a beta test thing, it would be nice if i could 
isolate this down to some bugs in ps2linux's libraries, so 
that we could fix them without mucking up the python 
code with ps2 stuff.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567892&group_id=5470



From noreply@sourceforge.net  Wed Jun 12 10:31:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jun 2002 02:31:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-567892 ] Various Playstation 2 Linux Test Errors
Message-ID: <E17I4TT-0004hY-00@usw-sf-web3.sourceforge.net>

Bugs item #567892, was opened at 2002-06-12 08:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567892&group_id=5470

Category: Installation
Group: Platform-specific
Status: Open
Resolution: None
Priority: 1
Submitted By: Keith Thomson (kazriko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Various Playstation 2 Linux Test Errors

Initial Comment:
I recently downloaded Python 2.2.1 onto my Playstation 
2 with a linux kit installed. It uses a mipsel architecture, 
(mips endian-little) with a Linux 2.2.1 kernel (retrofitted 
with many backported stuff from later versions) and a 
glibc 2.2.2 i believe, also custom modified by SCEI.

Python compiled perfectly the first time, and installed 
flawlessly. On a whim, I decided to run python's testing 
suite. (make test)

The first pass crashed with this error. 

test_re
make: *** [test] Segmentation fault

i moved this test out of the folder to see if there were 
any other errors, and got the same one for test_sre.

After moving these two tests, i got the following results, 
including the lines from the failing tests.

test test_descr failed -- x=2, y=1
test test_linuxaudiodev failed -- (16, 'Device or resource 
busy', '/dev/dsp')
test test_userdict failed -- test failed
3 tests failed:
    test_descr test_linuxaudiodev test_userdict
18 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl 
test_imgfile
    test_largefile test_minidom test_nis test_ntpath 
test_pyexpat
    test_sax test_socket_ssl test_socketserver 
test_sunaudiodev
    test_winreg test_winsound
3 skips unexpected on linux2:
    test_minidom test_pyexpat test_sax

The linuxaudiodev actually gave me two different errors, 
no other audio programs were running at the time, so i'm 
suspecting a ps2sd bug on that one. but the other four 
tests I have not tried to isolate yet.

I'll keep at it, Would welcome any recommendations on 
places to look to diagnose these problems. 

This is probably a very-low priority thing, as PS2Linux is 
still a bit of a beta test thing, it would be nice if i could 
isolate this down to some bugs in ps2linux's libraries, so 
that we could fix them without mucking up the python 
code with ps2 stuff.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-06-12 09:31

Message:
Logged In: YES 
user_id=6656

Some tips:

(1) don't worry about test_linuxaudiodev. I'm not sure it's
a lost cause, but...

(2) the test_re stuff is probably the consequence of a small
stack size.  try running ulimit -s 8192 before running the
test suite.

(3) the other test failures are a bit odd.  do you feel like
digging some more? "test_userdict failed -- test failed"
isn't terribly informative...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567892&group_id=5470



From noreply@sourceforge.net  Wed Jun 12 11:28:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jun 2002 03:28:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-567826 ] new opcodes undocumented
Message-ID: <E17I5MF-0005fK-00@usw-sf-web3.sourceforge.net>

Bugs item #567826, was opened at 2002-06-12 06:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567826&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: new opcodes undocumented

Initial Comment:
Manu new opcodes aren't documented in the section on
the dis module. E.g. CONTINUE_LOOP, GET_ITER,
YIELD_VALUE, etc. (A careful comparison of the module
to the dis source and/or opcode.h would be necessary to
find out all undocumented opcodes.)

I'm willing to help.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-12 12:28

Message:
Logged In: YES 
user_id=21627

I believe the complete list of undocumented opcodes is

['BINARY_FLOOR_DIVIDE', 'BINARY_TRUE_DIVIDE',
'INPLACE_FLOOR_DIVIDE', 'INPLACE_TRUE_DIVIDE', 'GET_ITER',
'YIELD_VALUE', 'FOR_ITER', 'CONTINUE_LOOP']


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567826&group_id=5470



From noreply@sourceforge.net  Wed Jun 12 11:38:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jun 2002 03:38:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation.
Message-ID: <E17I5W0-000622-00@usw-sf-web3.sourceforge.net>

Bugs item #555817, was opened at 2002-05-14 10:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Flawed fcntl.ioctl implementation.

Initial Comment:
I'm doing some USB user-space driver programming 
in Python 2.1.3 under Linux 2.4.

When using a particular ioctl (HIDIOCGNAME), the 
return value as well as the (copy_to_user) binary data 
is significant.

Here is the code from line 547 of hiddev.c (kernel 
2.4.19-pre7):
  if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) {
    int len;
    if (!hid->name) return 0;
    len = strlen(hid->name) + 1;
    if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd);
    return copy_to_user((char *) arg, hid->name, len) ?
      -EFAULT : len;
  }

So here is the problem:  fcntl.ioctl() will only give me 
one or the other value, but not both.

I can work around this by initialising the input buffer to 
all chr(0), and then strip them off after.  But there will 
be a time when an ioctl call *requires* both values.

Until now I have appreciated the simple ioctl interface, 
but now it is shown to be an oversimplification.

It may be that POSIX, or some standard somewhere 
says that ioctl should not be used to do this, but 
maybe Python should support it anyway.

I suggest either:
1.  A new function ioctl2(fd, op, arg) that returns a 
2-tuple of (return_value, binary_buffer) and does not 
try to interpret the return value.
2.  An optional 4th parameter whose presence (but 
not value) requests the 2-tuple mentioned in (1).

Gotta love Python!

----------------------------------------------------------------------

>Comment By: Graham Horler (grahamh)
Date: 2002-06-12 11:38

Message:
Logged In: YES 
user_id=543663

Still here...
Thanks for the help people.
Things have been a bit crazy ATM, but should be back to 
working with this again soon, so I'll let you know how it goes.


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-16 13:15

Message:
Logged In: YES 
user_id=29957

There's a very simple test_ioctl.py in 
patch #555883 (the ioctl2() sample implementation).
It does a getpgrp(), then a TIOCGPGRP and checks 
it gets the same stuff. No, it won't work on Windows.

I'm going to close off #555883 as Invalid.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-16 12:41

Message:
Logged In: YES 
user_id=6656

Try the attached.

(a) should have docs.  This is getting hairy (if this then
that, but if this and not that then the other...).
(b) I've made no attempt to get this to hand out sane error
messages (see above).
(c) would be nice to have tests.  how on earth do you test
ioctl?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-16 12:03

Message:
Logged In: YES 
user_id=6656

OK, that would seem to be easy enough to implement (well,
the handling of writeable buffers, not all the optional
hair).  I like this:

>>> buf = array.array('h', [0]*4)
[19139 refs]
>>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf)
0
[19139 refs]
>>> buf
array('h', [47, 137, 841, 615])
[19139 refs]

I like this less:

>>> import array, fcntl
[19089 refs]
>>> buf = array.array('h', [0]*3)
[19093 refs]
>>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf)
0
[19095 refs]
>>> del buf
Debug memory block at address p=0x401c3cb8:
    6 bytes originally requested
    The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected.
    The 4 pad bytes at tail=0x401c3cbe are not all
FORBIDDENBYTE (0xfb):
        at tail+0: 0x67 *** OUCH
        at tail+1: 0x02 *** OUCH
        at tail+2: 0xfb
        at tail+3: 0xfb
    The block was made by call #16015 to debug malloc/realloc.
    Data at p: 2f 00 89 00 49 03
Fatal Python error: bad trailing pad byte
Aborted

I'm not sure what we can possibly do about this?  Copy into
a fixed buffer like we do today, then copy out again after
the ioctl?  Probably the best option.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-16 11:43

Message:
Logged In: YES 
user_id=21627

I'm in favour of a you-may-mutate-the-buffer flag. A
transition strategy would be:
- in 2.3, make the flag optional, with default 0
- in 2.4, warn if it is not specified
- in 2.5, change the default
All the time, if the buffer isn't mutable, specifying the
flag should not be required.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-16 11:34

Message:
Logged In: YES 
user_id=29957

Hm. The solaris /proc lib I did in python, I used 'struct'
to dismantle C structures, but I did consider using byte
arrays. So that's one data point. 
(ok, it's not ioctls, but it's similar sort of data).
I'm loathe to go down the 'argument is mutable' optional
flag, but I really would prefer to make this work rather
than the ioctl2() approach, which really ain't that nice.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-16 10:21

Message:
Logged In: YES 
user_id=6656

I'm not *trying* to be a party-pooper, but there's another
problem: the point of passing a mutable array is so that
fcntl.ioctl can return ioctl(2)'s return code rather than
the string it returns now.  So if someone does use arrays
(or I guess Numeric.arrays?) for ioctls this would very
likely cause breakage.  I don't know how likely that is. 
Probably not very.  But I know that if this change broke my
code, I'd be a bit miffed.

All this is a bit annoying, as mutating arrays is clearly
the right solution -- where's that time machine?

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-05-15 23:50

Message:
Logged In: YES 
user_id=543663

I just realised - using array objects and changing in-place 
oversomes the arbitrary limit of 1024 bytes.  We could then 
achieve the full 16384 byte nirvana - hurrah!


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-15 18:21

Message:
Logged In: YES 
user_id=21627

I would not be concerned about the backwards compatibility,
either: if anybody is passing arrays, there is a good chance
that the ioctl does not modify the buffer, or that the
caller would not worry about the (missing) modification - or
else we had seen reports before.

So documenting in Misc/NEWS and the documentation that
mutable  objects supporting the (write) buffer interface may
now mutate seems sufficient.

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-05-15 17:32

Message:
Logged In: YES 
user_id=543663

Thanks Michael, its all incredibly clear now (sorry Martin).

I think using arrays sounds a great idea.
IMVHO as to backward compatibility, AFAICT its not 
documented that arrays can be passed to ioctl() anyway (only 
says int and string no?), so it's only breaking undocumented 
behaviour.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-15 16:38

Message:
Logged In: YES 
user_id=6656

grahamh: I think Martin understood you fine.

Remember that arrays are mutable, whereas strings are not.

So the idea would be that you'd write

buf = array.array('c', '\000'*256)
ret = fcntl.ioctl(fd, IOCTL_NUMBER, buf)

then the first "ret" bytes of "buf" would be valid.

However this possibly breaks backwards compatibility, as you
can already pass arrays into the ioctl function and they are
not modified.

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-05-15 15:44

Message:
Logged In: YES 
user_id=543663

Re Loewis:
Not sure what you mean, perhaps an example of the 
problem from me would help:

In C:
    char buf[256], strbuf[256];
    int ret, fd;
    fd = open(...)
    ret = ioctl(fd, IOCTL_NUMBER, buf);
    strncpy(strbuf, buf, ret);

This is impossible with the current fcntl module:
    buf = "X" * struct.calcsize("256s")
    buf = fcntl.ioctl(fd, IOCTL_NUMBER, buf)
    # The positive ioctl() return value is lost, and
    # hence I dont know how much of buf is significant

Extract from asm/unistd.h:

#define __syscall_return(type, res) \
do { \
        if ((unsigned long)(res) >= (unsigned long)(-125)) { \
                errno = -(res); \
                res = -1; \
        } \
        return (type) (res); \
} while (0)

So positive values are valid, but are being lost.

Anthony's patch looks good (thanks, I have not had a 
chance to test it myself yet), and the above example would 
be:
    buf = "X" * struct.calcsize("256s")
    ret, buf = fcntl.ioctl2(fd, IOCTL_NUMBER, buf)
    strbuf = buf[:ret] # Result!

Now, to test my understanding of your last comment about 
array objects Loewis, do you mean:
- pass in a mutable list that gets changed in place to [ret, 
buf]
- return (ret, buf) if called like this: ioctl(fd, IOC, [buf])
- or something else - please give example.

Thanks people.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-15 13:04

Message:
Logged In: YES 
user_id=21627

Thinking about the problem again, I think the right solution
would be to support array objects as arguments to ioctl -
those would then be passed into the system call.

Am I correctly understanding the problem, that this would
not require a new function?

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 13:06

Message:
Logged In: YES 
user_id=29957

possible patch at
http://sourceforge.net/tracker/index.php?func=detail&aid=555883&group_id=5470&atid=305470
I've only lightly tested it, not with any calls that return
useful values in the return code (couldn't find any easily, 
didn't feel like figuring out userspace drivers right now :)
Give it a whirl...

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 11:10

Message:
Logged In: YES 
user_id=29957

Ouch. I think you're right - and I think that the
ioctl2() implementation is probably the only solution.
(I'm not so keen on the name, but I guess it kinda 
follows the 'standard' of other python functions, e.g.
popen)
I know changing the return of ioctl would be mega-ugly,
unless there was a new, optional "return a tuple"
argument. I doubt that's the appropriate fix. 

If the former approach is the appropriate one, it should
be simple enough to add an ioctl2() to the C source. I 
can probably whip it up now...


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470



From noreply@sourceforge.net  Wed Jun 12 12:46:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jun 2002 04:46:55 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-567969 ] Missing socketpair() function.
Message-ID: <E17I6aV-0000N5-00@usw-sf-web4.sourceforge.net>

Feature Requests item #567969, was opened at 2002-06-12 12:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=567969&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing socketpair() function.

Initial Comment:
Coming from a C++ background, I have noticed the 
absence of a socketpair() function in the socket module.

I have implemented a couple of workarounds (see 
attached sockpair2.py), which I use a lot.

But there are security and portability problems lurking.

How about a nice shiny new socketpair() call in 
socketmodule?

Thanks, Graham.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=567969&group_id=5470



From noreply@sourceforge.net  Wed Jun 12 12:56:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jun 2002 04:56:43 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-567972 ] Missing 4 socket object properties
Message-ID: <E17I6jz-0000tw-00@usw-sf-web2.sourceforge.net>

Feature Requests item #567972, was opened at 2002-06-12 12:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=567972&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing 4 socket object properties

Initial Comment:
The C socketmodule has a struct PySocketSockObject, 
with family, type and proto members.

These would be terribly helpful to have access to in 
Python, when implementing some generic socket helper 
functions.

The "blocking" flag could also be made available, but 
would require some extra coding.

(I'm using Python 2.1.3 under Linux 2.4.16, so I cannot 
extend the socket class itself ((as in py2.2)), and don't 
want to slow down sockets with a complete wrapper, as I 
use them heavily.)

Thanks, Graham.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=567972&group_id=5470



From noreply@sourceforge.net  Wed Jun 12 13:00:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jun 2002 05:00:26 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-567972 ] Missing 4 socket object properties
Message-ID: <E17I6na-000113-00@usw-sf-web2.sourceforge.net>

Feature Requests item #567972, was opened at 2002-06-12 12:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=567972&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing 4 socket object properties

Initial Comment:
The C socketmodule has a struct PySocketSockObject, 
with family, type and proto members.

These would be terribly helpful to have access to in 
Python, when implementing some generic socket helper 
functions.

The "blocking" flag could also be made available, but 
would require some extra coding.

(I'm using Python 2.1.3 under Linux 2.4.16, so I cannot 
extend the socket class itself ((as in py2.2)), and don't 
want to slow down sockets with a complete wrapper, as I 
use them heavily.)

Thanks, Graham.

----------------------------------------------------------------------

>Comment By: Graham Horler (grahamh)
Date: 2002-06-12 13:00

Message:
Logged In: YES 
user_id=543663

Oh yes, the repr of a socket object includes the missing info, 
so to get hold of the family, I go:
  int(repr(sock).split(' ')[3].split('=')[1][:-1])

Similar for type and protocol, not nice!


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=567972&group_id=5470



From noreply@sourceforge.net  Wed Jun 12 14:38:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jun 2002 06:38:39 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-568007 ] Missing 4 socket object properties
Message-ID: <E17I8Kd-0003Jb-00@usw-sf-web2.sourceforge.net>

Feature Requests item #568007, was opened at 2002-06-12 14:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=568007&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing 4 socket object properties

Initial Comment:
The C socketmodule has a struct PySocketSockObject, 
with family, type and proto members.

These would be terribly helpful to have access to in 
Python, when implementing some generic socket helper 
functions.

The "blocking" flag could also be made available, but 
would require some extra coding.

(I'm using Python 2.1.3 under Linux 2.4.16, so I cannot 
extend the socket class itself ((as in py2.2)), and don't 
want to slow down sockets with a complete wrapper, as I 
use them heavily.)

Thanks, Graham.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=568007&group_id=5470



From noreply@sourceforge.net  Wed Jun 12 14:40:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jun 2002 06:40:08 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-568007 ] Missing 4 socket object properties
Message-ID: <E17I8M4-0003M0-00@usw-sf-web2.sourceforge.net>

Feature Requests item #568007, was opened at 2002-06-12 14:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=568007&group_id=5470

Category: Python Library
Group: None
Status: Deleted
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing 4 socket object properties

Initial Comment:
The C socketmodule has a struct PySocketSockObject, 
with family, type and proto members.

These would be terribly helpful to have access to in 
Python, when implementing some generic socket helper 
functions.

The "blocking" flag could also be made available, but 
would require some extra coding.

(I'm using Python 2.1.3 under Linux 2.4.16, so I cannot 
extend the socket class itself ((as in py2.2)), and don't 
want to slow down sockets with a complete wrapper, as I 
use them heavily.)

Thanks, Graham.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=568007&group_id=5470



From noreply@sourceforge.net  Wed Jun 12 14:39:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jun 2002 06:39:41 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-568007 ] Missing 4 socket object properties
Message-ID: <E17I8Ld-0003LZ-00@usw-sf-web2.sourceforge.net>

Feature Requests item #568007, was opened at 2002-06-12 14:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=568007&group_id=5470

Category: Python Library
Group: None
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing 4 socket object properties

Initial Comment:
The C socketmodule has a struct PySocketSockObject, 
with family, type and proto members.

These would be terribly helpful to have access to in 
Python, when implementing some generic socket helper 
functions.

The "blocking" flag could also be made available, but 
would require some extra coding.

(I'm using Python 2.1.3 under Linux 2.4.16, so I cannot 
extend the socket class itself ((as in py2.2)), and don't 
want to slow down sockets with a complete wrapper, as I 
use them heavily.)

Thanks, Graham.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=568007&group_id=5470



From noreply@sourceforge.net  Wed Jun 12 16:34:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jun 2002 08:34:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-567826 ] new opcodes undocumented
Message-ID: <E17IA8S-00062I-00@usw-sf-web1.sourceforge.net>

Bugs item #567826, was opened at 2002-06-12 00:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567826&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: new opcodes undocumented

Initial Comment:
Manu new opcodes aren't documented in the section on
the dis module. E.g. CONTINUE_LOOP, GET_ITER,
YIELD_VALUE, etc. (A careful comparison of the module
to the dis source and/or opcode.h would be necessary to
find out all undocumented opcodes.)

I'm willing to help.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-12 11:34

Message:
Logged In: YES 
user_id=6380

Assumin Martin is right, I've added docs for these.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-12 06:28

Message:
Logged In: YES 
user_id=21627

I believe the complete list of undocumented opcodes is

['BINARY_FLOOR_DIVIDE', 'BINARY_TRUE_DIVIDE',
'INPLACE_FLOOR_DIVIDE', 'INPLACE_TRUE_DIVIDE', 'GET_ITER',
'YIELD_VALUE', 'FOR_ITER', 'CONTINUE_LOOP']


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567826&group_id=5470



From noreply@sourceforge.net  Wed Jun 12 16:36:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jun 2002 08:36:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-568068 ] urllib needs 303/307 handlers
Message-ID: <E17IAAb-00064z-00@usw-sf-web1.sourceforge.net>

Bugs item #568068, was opened at 2002-06-12 11:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568068&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib needs 303/307 handlers

Initial Comment:
See

http://mail.python.org/pipermail/python-dev/2002-June/025289.htm

and

http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html

There is also an issue with the 302 handler (also
discussed there).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568068&group_id=5470



From noreply@sourceforge.net  Wed Jun 12 18:31:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jun 2002 10:31:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-565993 ] string.replace() can corrupt heap
Message-ID: <E17IBxe-0000is-00@usw-sf-web2.sourceforge.net>

Bugs item #565993, was opened at 2002-06-07 15:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565993&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Mike Romberg (romberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: string.replace() can corrupt heap

Initial Comment:
  I've been using a tool called mpatrol
(http://www.cbmamiga.demon.co.uk/mpatrol/) to cleanup an
embeded python application we have and ran into this
bug.  It seems to affect a stock python as well.  Under
certain
conditions it appears that one can get python to acess
freed
memory by calling string.replace or the string replace
method.

  Here is an example python command which reproduces
the problem:

python -c "a = 'a\000'; a.replace('\000', '')"

  The mpatrol library dumps the following logfile:

(see attachment)




----------------------------------------------------------------------

>Comment By: Mike Romberg (romberg)
Date: 2002-06-12 11:31

Message:
Logged In: YES 
user_id=61373

  After looking at this some more, I now think you are
correct.  This is a false positive reported by the tool.
Sorry for wasting your time with this.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-07 19:57

Message:
Logged In: YES 
user_id=31435

When somebody gets a report from one of these tools, 
there are 3 possibilities:

1. It's a bug in Python.
2. It's a bug in the tool.
3. It's a bug in the platform C library, compiler, or OS.

Historical fact is that #2 is the most frequent outcome, and 
these usually burn lots of time to pin the blame, so you're 
going to have to do more work if you want this taken 
seriously.

I stepped through your test case under a debugger using 
2.2.1, and saw nothing wrong.  There's a memcpy with a 
length of 0 where your tool reports "a problem", but that's 
not an error, and the addresses passed at that point are to 
legitimate memory regardless.  It's possible that your 
platform C library optimizes memcpy under the covers by 
reading up more memory than was requested, but platform 
libraries are outside of Python's control, and platform 
library authors generally "cheat" in safe ways.

At the very least, can you get into a debugger and find 
some reason to believe there's a real problem here better 
than "some program said so"?  If not, I'm inclined to close 
this as a 3rd-party bug without burning more time on it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565993&group_id=5470



From noreply@sourceforge.net  Wed Jun 12 18:57:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jun 2002 10:57:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-568134 ] asynchat module undocumented
Message-ID: <E17ICN1-0001F5-00@usw-sf-web2.sourceforge.net>

Bugs item #568134, was opened at 2002-06-12 11:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568134&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason R. Mastaler (jasonrm)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: asynchat module undocumented

Initial Comment:
While asyncore is documented, asynchat 
is not.

Lack of documentation makes asynchat
more difficult to understand/use than it
should be.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568134&group_id=5470



From noreply@sourceforge.net  Wed Jun 12 19:46:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jun 2002 11:46:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-565993 ] string.replace() can corrupt heap
Message-ID: <E17ID8Q-0002Jb-00@usw-sf-web4.sourceforge.net>

Bugs item #565993, was opened at 2002-06-07 17:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565993&group_id=5470

Category: Python Interpreter Core
>Group: 3rd Party
Status: Closed
>Resolution: Wont Fix
Priority: 3
Submitted By: Mike Romberg (romberg)
>Assigned to: Tim Peters (tim_one)
Summary: string.replace() can corrupt heap

Initial Comment:
  I've been using a tool called mpatrol
(http://www.cbmamiga.demon.co.uk/mpatrol/) to cleanup an
embeded python application we have and ran into this
bug.  It seems to affect a stock python as well.  Under
certain
conditions it appears that one can get python to acess
freed
memory by calling string.replace or the string replace
method.

  Here is an example python command which reproduces
the problem:

python -c "a = 'a\000'; a.replace('\000', '')"

  The mpatrol library dumps the following logfile:

(see attachment)




----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-06-12 14:46

Message:
Logged In: YES 
user_id=31435

Thanks for the followup, Mike!  Closing as 3rd Party.

----------------------------------------------------------------------

Comment By: Mike Romberg (romberg)
Date: 2002-06-12 13:31

Message:
Logged In: YES 
user_id=61373

  After looking at this some more, I now think you are
correct.  This is a false positive reported by the tool.
Sorry for wasting your time with this.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-07 21:57

Message:
Logged In: YES 
user_id=31435

When somebody gets a report from one of these tools, 
there are 3 possibilities:

1. It's a bug in Python.
2. It's a bug in the tool.
3. It's a bug in the platform C library, compiler, or OS.

Historical fact is that #2 is the most frequent outcome, and 
these usually burn lots of time to pin the blame, so you're 
going to have to do more work if you want this taken 
seriously.

I stepped through your test case under a debugger using 
2.2.1, and saw nothing wrong.  There's a memcpy with a 
length of 0 where your tool reports "a problem", but that's 
not an error, and the addresses passed at that point are to 
legitimate memory regardless.  It's possible that your 
platform C library optimizes memcpy under the covers by 
reading up more memory than was requested, but platform 
libraries are outside of Python's control, and platform 
library authors generally "cheat" in safe ways.

At the very least, can you get into a debugger and find 
some reason to believe there's a real problem here better 
than "some program said so"?  If not, I'm inclined to close 
this as a 3rd-party bug without burning more time on it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=565993&group_id=5470



From noreply@sourceforge.net  Wed Jun 12 23:08:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jun 2002 15:08:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-493951 ] string.{starts,ends}with vs slices
Message-ID: <E17IGHz-0003ox-00@usw-sf-web3.sourceforge.net>

Bugs item #493951, was opened at 2001-12-16 14:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493951&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: Remind
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: string.{starts,ends}with vs slices

Initial Comment:
The attached test shows many cases where 
string.startswith() and string.endswith() fail to 
handle negative slice indices correctly.  The failures 
are in both the start and end indices.  I stumbled 
into this when tracking down why (what turned out to 
be) this didn't work:

>>> file = 'difflib.pyc'
>>> file.endswith('.py', 0, -1) # should be 1
0
>>> file[0:-1].endswith('.py')  # like this is
1
>>>

Can we risk changing this for 2.2?  Don't know.  If 
not, reduce the priority.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-12 18:08

Message:
Logged In: YES 
user_id=33168

Attached is a patch which implements this behaviour.
Still need a patch for tests and the doc.
This passes all regressions and Tim's test.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 10:31

Message:
Logged In: YES 
user_id=6380

We should fix this in 2.3 at the very least. Leave 2.2.x
alone.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-04-22 10:11

Message:
Logged In: YES 
user_id=12800

The comment in the code reminds me that we adopted the
semantics for Java's String.startsWith() and String.endsWith(): 

http://java.sun.com/products/jdk/1.2/docs/api/java/lang/String.html#startsWith(java.lang.String,%20int)

which treats negative indices as errors (at least for the
start parameter -- which we generalized to include the end
parameter).  Changing this is a semantic change to the
string methods, so I don't think it should be undertaken
lightly (i.e. as a bug in the current implementation).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-16 15:03

Message:
Logged In: YES 
user_id=31435

I can't guess what the docs intended to say (they're vague -
- I can read them several ways).

In all other cases where optional string-method args 
named "start" and "end" are accepted (find(), rfind(), count
(), index(), rindex()), the docs are clear that they're 
interpreted as slice notation.  It doesn't make sense for 
the two newest methods to behave differently in this 
respect.

The unit tests aren't evidence one way or the other to me --
 the behavior of negative indices should be covered by the 
tests no matter what the intended semantics.

Overall, I expect the behavior here is an accident (as 
opposed to intended).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-16 14:45

Message:
Logged In: YES 
user_id=6380

Hm, the docs don't exactly suggest that negative indices
would be supported. While that would be nice, it's
definitely a feature request, so no, please don't do this in
2.2. (The absent of unit tests for negative indices also
suggests this was not an oversight. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-16 14:24

Message:
Logged In: YES 
user_id=31435

Attached the test case.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493951&group_id=5470



From noreply@sourceforge.net  Wed Jun 12 23:38:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jun 2002 15:38:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-532646 ] Recursive class instance "error"
Message-ID: <E17IGl2-0007a9-00@usw-sf-web1.sourceforge.net>

Bugs item #532646, was opened at 2002-03-20 13:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Gregor Mirai (gregmi)
>Assigned to: Guido van Rossum (gvanrossum)
>Summary: Recursive class instance "error"

Initial Comment:
If one writes the following code (tested on Python  
2.1, 2.2 on platforms MacOS X Server, MacOS X, Windows 
98, NT, 2000) one can easily produce several "errors".

MacOS X, MacOS X Server (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name,
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
Segmentation fault

Win98, NT, 2000 (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
foo
__repr__ __call__ __call__ __call__ ... ad inf



----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-12 18:38

Message:
Logged In: YES 
user_id=33168

The problem is that there is mutual recursion
between instance_call() and PyObject_Call().
The recursion apparently goes through the eval_frame() loop.

This patch increases the recursion depth so the mutual recursion
will eventually end (otherwise, the stack grows without bounds).

ISTM the first check SHOULD be reached, but it is not.
I don't understand why.  The recursion error must be set
in eval_frame().

The first block in the patch could be just this line:
    ++tstate->recursion_depth;

I didn't do it that way, since I didn't expect returning to
eval_frame().  I'm not sure if it's guaranteed to return
to eval_frame() which is why I left the first condition
in with the comment.  I suppose the comment should say
something like:  /* this condition doesn't seem to be triggered,
the recursion depth limit is exceeded in eval_frame */

The test for recursion_depth is necessary to ensure
that the recursion error isn't overwritten.  If this check
is removed, the follow exception is raised:
    AttributeError: A instance has no __call__ method

Hopefully this makes sense.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 12:08

Message:
Logged In: YES 
user_id=6380

Can you explain how the fix works? Why does the first
comment say

/* this shouldn't be reached, but just in case */

and why is this test necesary

if (tstate->recursion_depth < Py_GetRecursionLimit()) {

???

And who *does* report the recursion error?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 18:52

Message:
Logged In: YES 
user_id=33168

The recursion fields are shared in the new patch.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 16:35

Message:
Logged In: YES 
user_id=33168

That sounds more reasonable.
I'll take a look and see if they can be integrated.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-07 16:27

Message:
Logged In: YES 
user_id=6380

Fair enough.  Ideally this should share the recursion_limit
variable from ceval.c and the recursion_depth field of the
stack frame.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 16:23

Message:
Logged In: YES 
user_id=33168

I don't know.  I tried to come up with other test cases and
failed.
Tried __str__ and __getitem__.  Also tried new-style classes.

The problem was that the code bounced back and forth
between PyObject_Call() & instance_call() (mutual recursion).


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-07 16:08

Message:
Logged In: YES 
user_id=6380

Is this fix enough?  Aren't there lots of other ways to
generate the same error?  E.g. new-style classes (where this
particular example doesn't apply, but others might).

Or is this specific to instance_call?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 15:21

Message:
Logged In: YES 
user_id=33168

The attached patch stops the segfault and raises an exception:
TypeError: 'A' max recursion limit (100000) exceeded

I'm not sure if this is genarally applicable, or what a
reasonable # is.
100,000 was a guess and should probably be made a #def
w/comment.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-21 04:47

Message:
Logged In: NO 

>>> a=A() 
>>> a.foo 
foo 
__repr__ __call__ __call__ __call__ ... ad inf

This is normal behavior. The code at the top is buggy. The 
correct one is:

class A:
  def __getattr__(self, name):
    if name == '__repr__':
      return self.__repr__()
    print name
    return A()

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-20 17:10

Message:
Logged In: YES 
user_id=6380

This is buggy user code.

But the segfault should be fixed if possible.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470



From noreply@sourceforge.net  Wed Jun 12 23:59:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jun 2002 15:59:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-568269 ] Misleading string constant.
Message-ID: <E17IH5B-0007h9-00@usw-sf-web2.sourceforge.net>

Bugs item #568269, was opened at 2002-06-12 15:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568269&group_id=5470

Category: Documentation
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Bjorn Pettersen (bpettersen)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Misleading string constant.

Initial Comment:
In _winreg.ConnectRegistry() it says:

computer_name is the name of the remote computer, of 
the form "\computername". If None, the local computer 
is used. 

Could it be changed to use r"\computername"? (it just 
took me half an hour to figure out why it couldn't find the 
computer on the network, and I really should know 
better :-)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568269&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 02:56:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jun 2002 18:56:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-568322 ] socket module htonl/ntohl bug
Message-ID: <E17IJr1-0002PU-00@usw-sf-web4.sourceforge.net>

Bugs item #568322, was opened at 2002-06-13 01:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568322&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: David Margrave (davidma)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket module htonl/ntohl bug

Initial Comment:

Hello,

The following statement should work, but does not, on
python 1.5.2 and python 2.2:

>>> socket.htonl(pow(2L,32)-1)
Traceback (innermost last):
  File "<stdin>", line 1, in ?
OverflowError: long int too long to convert

2^32-1 is a valid 32-bit value, equal to 32 1s in
binary, and htonl
should be able to handle it.  

By way of comparison, the following simple C program
works properly:

#include <stdio.h>
#include <sys/socket.h>

int main(void)
{
        printf ("%u\n", htonl(4294967295));
}

When run, it prints out '4294967295' as expected.


Dave


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568322&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 06:11:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jun 2002 22:11:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-567892 ] Various Playstation 2 Linux Test Errors
Message-ID: <E17IMtK-0002rl-00@usw-sf-web3.sourceforge.net>

Bugs item #567892, was opened at 2002-06-12 02:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567892&group_id=5470

Category: Installation
Group: Platform-specific
Status: Open
Resolution: None
Priority: 1
Submitted By: Keith Thomson (kazriko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Various Playstation 2 Linux Test Errors

Initial Comment:
I recently downloaded Python 2.2.1 onto my Playstation 
2 with a linux kit installed. It uses a mipsel architecture, 
(mips endian-little) with a Linux 2.2.1 kernel (retrofitted 
with many backported stuff from later versions) and a 
glibc 2.2.2 i believe, also custom modified by SCEI.

Python compiled perfectly the first time, and installed 
flawlessly. On a whim, I decided to run python's testing 
suite. (make test)

The first pass crashed with this error. 

test_re
make: *** [test] Segmentation fault

i moved this test out of the folder to see if there were 
any other errors, and got the same one for test_sre.

After moving these two tests, i got the following results, 
including the lines from the failing tests.

test test_descr failed -- x=2, y=1
test test_linuxaudiodev failed -- (16, 'Device or resource 
busy', '/dev/dsp')
test test_userdict failed -- test failed
3 tests failed:
    test_descr test_linuxaudiodev test_userdict
18 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl 
test_imgfile
    test_largefile test_minidom test_nis test_ntpath 
test_pyexpat
    test_sax test_socket_ssl test_socketserver 
test_sunaudiodev
    test_winreg test_winsound
3 skips unexpected on linux2:
    test_minidom test_pyexpat test_sax

The linuxaudiodev actually gave me two different errors, 
no other audio programs were running at the time, so i'm 
suspecting a ps2sd bug on that one. but the other four 
tests I have not tried to isolate yet.

I'll keep at it, Would welcome any recommendations on 
places to look to diagnose these problems. 

This is probably a very-low priority thing, as PS2Linux is 
still a bit of a beta test thing, it would be nice if i could 
isolate this down to some bugs in ps2linux's libraries, so 
that we could fix them without mucking up the python 
code with ps2 stuff.

----------------------------------------------------------------------

>Comment By: Keith Thomson (kazriko)
Date: 2002-06-12 23:11

Message:
Logged In: YES 
user_id=346680

I attempted to use the ulimit command and change the stack 
size maximum, but it still failed when doing the full test suite. 
(even tried several different stack sizes) however, running the 
test individually with this line 
./python Lib/test/regrtest.py -g test_re.py
worked perfectly, as did the sre version.

I ran test_descr outside of the testing framework, and it 
crashed on the following test..
Testing classic comparisons...
        (base = __main__.classic)
Traceback (most recent call last):
  File "./Lib/test/test_descr.py", line 2906, in ?
    test_main()
  File "./Lib/test/test_descr.py", line 2884, in test_main
    classic_comparisons()
  File "./Lib/test/test_descr.py", line 2193, in 
classic_comparisons
    verify(cmp(x, c[y]) == cmp(x, y), "x=%d, y=%d" % (x, y))
  File "./Lib/test/test_support.py", line 118, in verify
    raise TestFailed(reason)
test_support.TestFailed: x=2, y=1

similarly, test_userdict gave this traceback when it crashed.
./python ./Lib/test/test_userdict.py
Traceback (most recent call last):
  File "./Lib/test/test_userdict.py", line 33, in ?
    verify(cmp(a, b) == cmp(len(a), len(b)))
  File "./Lib/test/test_support.py", line 118, in verify
    raise TestFailed(reason)

These might be failing for the same reason?

For information's sake, here's the linuxaudio traceback.

[kazrikna@rikku Python-2.2.1]
$ ./python ./Lib/test/test_linuxaudiodev.py
Traceback (most recent call last):
  File "./Lib/test/test_linuxaudiodev.py", line 89, in ?
    test()
  File "./Lib/test/test_linuxaudiodev.py", line 86, in test
    play_sound_file(findfile('audiotest.au'))
  File "./Lib/test/test_linuxaudiodev.py", line 42, in 
play_sound_file
    a.bufsize()
linuxaudiodev.error: (22, 'Invalid argument')

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-06-12 03:31

Message:
Logged In: YES 
user_id=6656

Some tips:

(1) don't worry about test_linuxaudiodev. I'm not sure it's
a lost cause, but...

(2) the test_re stuff is probably the consequence of a small
stack size.  try running ulimit -s 8192 before running the
test suite.

(3) the other test failures are a bit odd.  do you feel like
digging some more? "test_userdict failed -- test failed"
isn't terribly informative...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567892&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 06:22:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 12 Jun 2002 22:22:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-568366 ] Module searchpath init: no tilde expansi
Message-ID: <E17IN4F-0006FN-00@usw-sf-web4.sourceforge.net>

Bugs item #568366, was opened at 2002-06-13 05:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568366&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Philip Ganchev (phil_ganchev)
Assigned to: Nobody/Anonymous (nobody)
Summary: Module searchpath init: no tilde expansi

Initial Comment:
Python initializes the module search path (sys.path) to
the contents of the system variable $PYTHONPATH (on
unix) at python startup.  But it does not expand '~' to
the user's home directory.  

It should, since tilde expansion is a convention which
many users and administrators rely on; not having it is
confusing.

Tilde expansion would also simplify use in other ways.
 For example, if the administrator puts '~/bin' on the
PYTHONPATH, this  would save many users from adding to
the path.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568366&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 09:15:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 01:15:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-568412 ] minor improvement to Grammar file
Message-ID: <E17IPlf-0005wi-00@usw-sf-web3.sourceforge.net>

Bugs item #568412, was opened at 2002-06-13 01:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568412&group_id=5470

Category: Parser/Compiler
Group: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Y. Kim (emacsman)
Assigned to: Nobody/Anonymous (nobody)
Summary: minor improvement to Grammar file

Initial Comment:
The 'print_stmt' non-terminal duplicates the rule for
'testlist'
non-terminal. The diff shown below replaces the
duplicate rule with
'testlist'.

$ diff -c Grammar-orig Grammar
*** Grammar-orig	Thu Jun 13 00:53:53 2002
--- Grammar	Thu Jun 13 00:54:16 2002
***************
*** 40,46 ****
  expr_stmt: testlist (augassign testlist | ('='
testlist)*)
  augassign: '+=' | '-=' | '*=' | '/=' | '%=' | '&=' |
'|=' | '^=' | '<<=' | '>>=' | '**=' | '//='
  # For normal assignments, additional restrictions
enforced by the interpreter
! print_stmt: 'print' ( [ test (',' test)* [','] ] |
'>>' test [ (',' test)+ [','] ] )
  del_stmt: 'del' exprlist
  pass_stmt: 'pass'
  flow_stmt: break_stmt | continue_stmt | return_stmt |
raise_stmt | yield_stmt
--- 40,46 ----
  expr_stmt: testlist (augassign testlist | ('='
testlist)*)
  augassign: '+=' | '-=' | '*=' | '/=' | '%=' | '&=' |
'|=' | '^=' | '<<=' | '>>=' | '**=' | '//='
  # For normal assignments, additional restrictions
enforced by the interpreter
! print_stmt: 'print' ( [testlist] | '>>' test [ (','
test)+ [','] ] )
  del_stmt: 'del' exprlist
  pass_stmt: 'pass'
  flow_stmt: break_stmt | continue_stmt | return_stmt |
raise_stmt | yield_stmt


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568412&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 12:22:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 04:22:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-558072 ] faqwiz.py could do email obfuscation
Message-ID: <E17ISgg-0003oh-00@usw-sf-web1.sourceforge.net>

Bugs item #558072, was opened at 2002-05-19 17:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558072&group_id=5470

Category: Demos and Tools
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Reis (kiko_async)
Assigned to: Guido van Rossum (gvanrossum)
Summary: faqwiz.py could do email obfuscation

Initial Comment:
Faqwiz.py could obfuscate emails very easily, simply by
replacing @ by some other symbol in it's output. I've
homecooked a solution that basically involves:

adding to faqconf.py:

 # Obfuscate @ symbol as

 OBFUSCATE="-at-"

and changing interpolate() in faqwiz.py:

 def _interpolate(format, args, kw):
    try:
        quote = kw['_quote']
    except KeyError:
        quote = 1 
    d = (kw,) + args + (faqconf.__dict__,)
    m = MagicDict(d, quote)
    return string.replace(format % m, '@', OBFUSCATE)

This isn't my favourite solution, though, but since I
find the code a bit hard to follow, it suffices for
now. I'm willing to work a bit more on this if it
interests people.

----------------------------------------------------------------------

>Comment By: Christian Reis (kiko_async)
Date: 2002-06-13 08:22

Message:
Logged In: YES 
user_id=222305

You're right, I did. The patch attached does it in a less
broken way, though I don't like the way I have to
permanently change last_changed_email - I just wanted to
obfuscate on the printing.

Anyway, since the link can't be a mailto anymore (which may
be considered a regression) I've removed the relevant link
from faqconf.py.

I've kept the faqconf.py OBFUSCATE symbol but am unsure as
to where it should go.

I've also rolled in two changes I did locally to my faqwiz.
The first one is a simple CSS mod that avoids the need for
an external image and makes the PRE sections highlight.

The second one is adding LABEL to the radiobuttons on the
front page and removing the "/"s and <BR> between the first
"query argument" options. It was confusing users at the
office. The LABEL tag allows you to click on the label and
have the radiobutton select, and is supported on superior
browsers (cough mozilla cough).

I'd appreciate comments, thanks.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 17:45

Message:
Logged In: YES 
user_id=6380

Clearly this does too much -- interpolate is used in a
number of contexts where a @ shouldn't be obfuscated, e.g.
commands to be executed by the shell.

I'm unclear on *where* you'd like to obfuscate email
addresses. Do you only want to obfuscate the email address
of the person who modified the entry, or do you want to
obfuscate all @ signs anywhere in the text? The latter seems
overkill, and can cause breakage in code samples that happen
to use @ signs.

BTW, you're right that this code is hard to follow! It could
benefit from a few comments here or there... :-(

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 15:46

Message:
Logged In: YES 
user_id=6380

Good idea.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558072&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 12:34:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 04:34:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-459235 ] tuple __getitem__ limited
Message-ID: <E17ISrr-00022E-00@usw-sf-web3.sourceforge.net>

Bugs item #459235, was opened at 2001-09-06 13:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=459235&group_id=5470

Category: Type/class unification
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Guido van Rossum (gvanrossum)
Summary: tuple __getitem__ limited

Initial Comment:
The __getitem__ of a tuple does not support the
extended slicing. That makes it difficult to delegate
from an object's __getitem__ to a builtin container,
which ought to work through delegating __getitem__

<pre>
class GI:
    def __getitem__(self,a):
        print a

a = GI()
a[1:2]
(1,2,3,4).__getitem__(slice(1,2,None))
</pre>

gives

slice(1, 2, None)
Traceback (most recent call last):
  File "bar.py", line 7, in ?
    (1,2,3,4).__getitem__(slice(1,2,None))


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 07:34

Message:
Logged In: YES 
user_id=6380

MWH's patch has fixed this now.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-03 17:01

Message:
Logged In: YES 
user_id=6380

See (revived) patch 400998?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-06 14:08

Message:
Logged In: YES 
user_id=6380

This is not just the __getitem__ -- t[...] also has this
problem.
As a workaround, you can define __getslice__ or parse the
slice() object yourself.

I'll eventually get around to fixing this, but it's a bit
messy.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=459235&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 12:38:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 04:38:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-473985 ] str, __getitem__ and slices
Message-ID: <E17ISvS-0002So-00@usw-sf-web4.sourceforge.net>

Bugs item #473985, was opened at 2001-10-23 06:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=473985&group_id=5470

Category: Type/class unification
Group: Python 2.3
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Guido van Rossum (gvanrossum)
Summary: str, __getitem__ and slices

Initial Comment:
Using slices with __getitem__ doesn't work with 
classes derived from str:
---
class S(str):
   def __getitem__(self, index):
      print "getitem", index
      return str.__getitem__(self, index)
   def __setitem__(self, index, value):
      print "setitem", index, value

s = S("foo")
print s[0]
print s[0:2]
s[0] = "b"
s[0:2] = "bar"
---
This prints:
---
getitem 0
f
fo
setitem 0 b
setitem slice(0, 2, None) bar
---
instead of
---
getitem 0
f
getitem slice(0, 2, None)
fo
setitem 0 b
setitem slice(0, 2, None) bar
---
i.e. when no __getslice__ is defined s[0:2] will not 
be forwarded to __getitem__, but it seems to work for 
__setitem__.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 07:38

Message:
Logged In: YES 
user_id=6380

I'm closing this despite the fact that it's not 100% fixed.

Because the base class defines __getslice__, the derived
class will inherit this, so you'll have to override it. But
the base class __getitem__ accepts arbitrary slice objects
now.

(Perhaps it should be possible to explicitly set a method to
None to say "I'm not implementing this"? But that has all
sorts of other unforeseen consequences -- ptobably better
not. In the future, strings may lose their __getslice__
method, but for now I think that would slow things down too
much.)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-11 13:00

Message:
Logged In: YES 
user_id=6380

Um, that patch doesn't change the fact that strings have a 
__getslice__ method. Maybe that can be thrown out now 
though? str.__getitem__ now supports slice objects, so 
there's no need to have __getslice__ as well.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-03 17:01

Message:
Logged In: YES 
user_id=6380

See (revived) patch 400998?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:45

Message:
Logged In: YES 
user_id=6380

Raising the priority slightly and marking as a 2.3 issue.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-10-23 10:50

Message:
Logged In: YES 
user_id=6380

I've thought about this some more.

It should be fixed, but the fix is complex, and think I'd
rather not make this change in 2.2 -- (1) I have little
time, and (2) we've already issued a beta release and a
declared a feature freeze. So I'd like to put this on hold
until I can start working on 2.3. This is what would have to
be done:

- Change all built-in sequence types to get rid of the
sq_slice and sq_ass_slice dispatch functions; instead, add a
mapping extension to these types and add mp_subscript and
mp_ass_subscript dispatch functions that recognize slice
objects.

- We'd probably also have to get rid of the sq_item and
sq_ass_item dispatch functions, to roll them into
mp_subscript and mp_ass_subscript.

- Possibly, the whole "PySequenceMethods" structure should
be deprecated; all the operations there are overloading
either numerical or mapping operations.

Extension types that define a sequence methods structure
should continue to work, but the recommendation would be to
migrate these out.

I wish I could do this in 2.2, but it's really too much work
to start now, *and* it would be a serious incompatibility
between 2.2b1 and 2.2b2.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-10-23 10:05

Message:
Logged In: YES 
user_id=89016

Oops, this wasn't meant to be a patch. Should have gone 
into the bugs category.

The problems is that http://python.sourceforge.net/devel-
docs/ref/sequence-methods.html says, that __getslice__ 
is "Deprecated since release 2.0", so the user will want to 
implement __getslice__ via __getitem__.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-10-23 09:48

Message:
Logged In: YES 
user_id=6380

I don't think this is a bug. S inherits __getslice__ from
the str base class, but since str is immutable, it doesn't
define a __setslice__ to inherit for S.

BTW I'm reclassifying this as a bug, not a patch. This will
unfortunately invalidate the old URL you had for this entry
(SF doesn't really like reclassification that much.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=473985&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 12:49:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 04:49:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-473985 ] str, __getitem__ and slices
Message-ID: <E17IT6Q-0002Jc-00@usw-sf-web3.sourceforge.net>

Bugs item #473985, was opened at 2001-10-23 06:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=473985&group_id=5470

Category: Type/class unification
Group: Python 2.3
>Status: Open
Resolution: Wont Fix
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Guido van Rossum (gvanrossum)
Summary: str, __getitem__ and slices

Initial Comment:
Using slices with __getitem__ doesn't work with 
classes derived from str:
---
class S(str):
   def __getitem__(self, index):
      print "getitem", index
      return str.__getitem__(self, index)
   def __setitem__(self, index, value):
      print "setitem", index, value

s = S("foo")
print s[0]
print s[0:2]
s[0] = "b"
s[0:2] = "bar"
---
This prints:
---
getitem 0
f
fo
setitem 0 b
setitem slice(0, 2, None) bar
---
instead of
---
getitem 0
f
getitem slice(0, 2, None)
fo
setitem 0 b
setitem slice(0, 2, None) bar
---
i.e. when no __getslice__ is defined s[0:2] will not 
be forwarded to __getitem__, but it seems to work for 
__setitem__.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 07:49

Message:
Logged In: YES 
user_id=6380

Um, I have to reopen this, because I lied.

While "abc"[::] works, str.__getitem__("abc", slice(None))
doesn't. And ditto for tuples and lists. I think the
dispatcher tries the sequence getitem before the mapping
getitem.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 07:38

Message:
Logged In: YES 
user_id=6380

I'm closing this despite the fact that it's not 100% fixed.

Because the base class defines __getslice__, the derived
class will inherit this, so you'll have to override it. But
the base class __getitem__ accepts arbitrary slice objects
now.

(Perhaps it should be possible to explicitly set a method to
None to say "I'm not implementing this"? But that has all
sorts of other unforeseen consequences -- ptobably better
not. In the future, strings may lose their __getslice__
method, but for now I think that would slow things down too
much.)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-11 13:00

Message:
Logged In: YES 
user_id=6380

Um, that patch doesn't change the fact that strings have a 
__getslice__ method. Maybe that can be thrown out now 
though? str.__getitem__ now supports slice objects, so 
there's no need to have __getslice__ as well.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-03 17:01

Message:
Logged In: YES 
user_id=6380

See (revived) patch 400998?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:45

Message:
Logged In: YES 
user_id=6380

Raising the priority slightly and marking as a 2.3 issue.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-10-23 10:50

Message:
Logged In: YES 
user_id=6380

I've thought about this some more.

It should be fixed, but the fix is complex, and think I'd
rather not make this change in 2.2 -- (1) I have little
time, and (2) we've already issued a beta release and a
declared a feature freeze. So I'd like to put this on hold
until I can start working on 2.3. This is what would have to
be done:

- Change all built-in sequence types to get rid of the
sq_slice and sq_ass_slice dispatch functions; instead, add a
mapping extension to these types and add mp_subscript and
mp_ass_subscript dispatch functions that recognize slice
objects.

- We'd probably also have to get rid of the sq_item and
sq_ass_item dispatch functions, to roll them into
mp_subscript and mp_ass_subscript.

- Possibly, the whole "PySequenceMethods" structure should
be deprecated; all the operations there are overloading
either numerical or mapping operations.

Extension types that define a sequence methods structure
should continue to work, but the recommendation would be to
migrate these out.

I wish I could do this in 2.2, but it's really too much work
to start now, *and* it would be a serious incompatibility
between 2.2b1 and 2.2b2.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-10-23 10:05

Message:
Logged In: YES 
user_id=89016

Oops, this wasn't meant to be a patch. Should have gone 
into the bugs category.

The problems is that http://python.sourceforge.net/devel-
docs/ref/sequence-methods.html says, that __getslice__ 
is "Deprecated since release 2.0", so the user will want to 
implement __getslice__ via __getitem__.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-10-23 09:48

Message:
Logged In: YES 
user_id=6380

I don't think this is a bug. S inherits __getslice__ from
the str base class, but since str is immutable, it doesn't
define a __setslice__ to inherit for S.

BTW I'm reclassifying this as a bug, not a patch. This will
unfortunately invalidate the old URL you had for this entry
(SF doesn't really like reclassification that much.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=473985&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 12:51:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 04:51:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-567605 ] setup.py ignores env and uses wrong libs
Message-ID: <E17IT8T-000304-00@usw-sf-web2.sourceforge.net>

Bugs item #567605, was opened at 2002-06-11 22:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567605&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Marc Lehmann (pcg)
Assigned to: Nobody/Anonymous (nobody)
Summary: setup.py ignores env and uses wrong libs

Initial Comment:
tcl/tk and lot's of other libs reside in /opt/lib and
/opt/include on my system. CPPFLAGS and LDFLAGS reflect
this. python doesn't find anything in /opt, though, as
setup.py completely ignores this.

To debug this, I added a print libdirs after the line:

        lib_dirs = self.compiler.library_dirs +
['/lib', '/usr/lib']

and found that "lib_dirs" contains "/usr/local/lib",
which is completely bogus (but not wrong) (prefix is
/opt/python, my compiler doesn't search for /usr/local
etc.), "/lib" and "/usr/lib".

My system:

linux (2.4), glibc-2.2.5, every package is in
/opt/packagename, symlinked to common subdirs in
/opt/lib etc,,

LDFLAGS=-L/usr/app/lib -L/opt/lib
CPPFLAGS=-I/usr/app/include -I/opt/include
CFLAGS=-O3 -g -pipe -march=pentium -mcpu=pentiumpro
-momit-leaf-frame-pointer



----------------------------------------------------------------------

>Comment By: Marc Lehmann (pcg)
Date: 2002-06-13 13:51

Message:
Logged In: YES 
user_id=8851

If this is expected behaviour, then why does python come
with a configure script at all? I find it confusing when a
software package imitates a common standard (autoconf) and
then doesn't really implement it.

In any case, if it isn't a sofwtare bug then it's a
documentation bug, as the README claims:

   Start by running the script "./configure", which
determines your
   system configuration and creates the Makefile

which is clearly not the case, as it would be with any other
software package.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-11 22:28

Message:
Logged In: YES 
user_id=21627

I don't think this is a bug. If you use a certain
configuration not supported by setup.py, you need to edit
Modules/Setup manually.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567605&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 12:51:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 04:51:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-210637 ] ihooks on windows and pythoncom (PR#294)
Message-ID: <E17IT8Y-0002jA-00@usw-sf-web4.sourceforge.net>

Bugs item #210637, was opened at 2000-07-31 14:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210637&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Mark Hammond (mhammond)
Summary: ihooks on windows and pythoncom (PR#294)

Initial Comment:
Jitterbug-Id: 294
Submitted-By: mak@mikroplan.com.pl
Date: Thu, 13 Apr 2000 04:09:35 -0400 (EDT)
Version: cvs
OS: windows


Hi,

Python module ihooks is not so compatible with builtin imp while importing
modules whose name is stored in registry eg. pythoncom/pywintypes.

import ihooks
ihooks.install()
import pythoncom

This code will fail inside pythonwin ide too !




====================================================================
Audit trail:
Tue Jul 11 08:29:17 2000	guido	moved from incoming to open

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-13 04:51

Message:
Logged In: NO 

yes i found that your new modele is the shit


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 14:29

Message:
Logged In: YES 
user_id=31392

Mark,

Any interest in looking at this bug?  It holds the record 
for the oldest Python bug at SF.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-02-12 07:13

Message:
Logged In: NO 

i try it first,ok


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-11-15 15:19

Message:
Logged In: NO 

¾È³çÇϼ¼¿ä

ÀÌÁ¦ºÎÅÍ Á¦ ¼Ò°³¸¦ ÇÏ°Ú½À´Ï´Ù

ÀúÀÇ À̸§Àº ¹ÚÇýÁØ ÀÌ°í¿ä

³ªÀÌ´Â 13»ìÀÌ¿¡¿ä

±×¸®°í °¡Á·Àº ¸ðµÎ 4¸í

¾ö¸¶ ¾Æºü ´©³ª ³ª

Á¦°¡ »ç´Â °÷Àº ºÐ´ç±¸ ¾ßžµ¿ ¸ÅÈ­¸¶À» 105-1006

Á¦ ÀüÈ­¹øÈ£´Â¿© 031-704-9838

Àú´Â Çѱ¹ÀÎ ÀÔ´Ï´Ù.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-09-19 10:23

Message:
Logged In: NO 

ruoy retupmoc si daed

----------------------------------------------------------------------

Comment By: Grzegorz Makarewicz (mpmak)
Date: 2001-03-02 04:27

Message:
Logged In: YES 
user_id=141704

BasicModuleLoader.find_module_in_dir is searching for main 
modules only in frozen and builtin. The imp searches the 
registry, too.

ModuleLoader.find_module_in_dir should call the functions 
from the inherited object.

so this patch should help:
--- V:\py21\Lib\ihooks.py	Mon Feb 12 08:55:46 2001
+++ ihooks.py	Sun Feb 18 04:39:39 2001
@@ -122,8 +122,13 @@
 
     def find_module_in_dir(self, name, dir):
         if dir is None:
-            return self.find_builtin_module(name)
-        else:
+            result = self.find_builtin_module(name)
+            if result is not None:
+                return result
+            try:
+                return imp.find_module(name, None)
+            except:
+                return None
             try:
                 return imp.find_module(name, [dir])
             except ImportError:
@@ -237,7 +242,7 @@
 
     def find_module_in_dir(self, name, dir, 
allow_packages=1):
         if dir is None:
-            return self.find_builtin_module(name)
+            return BasicModuleLoader.find_module_in_dir
(self,name,dir)
         if allow_packages:
             fullname = self.hooks.path_join(dir, name)
             if self.hooks.path_isdir(fullname):


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2000-08-30 23:23

Message:
Leaving open, but moving down the priority and resolution lists.  A patch would help bump it back up :-)

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2000-08-13 23:42

Message:
This needs a resolution.  The "registered module" code in the code also needs to support HKEY_CURRENT_USER along with the HKEY_LOCAL_MACHINE it does now.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210637&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 13:25:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 05:25:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-459235 ] tuple __getitem__ limited
Message-ID: <E17ITfi-00050E-00@usw-sf-web1.sourceforge.net>

Bugs item #459235, was opened at 2001-09-06 17:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=459235&group_id=5470

Category: Type/class unification
Group: Python 2.2
>Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Guido van Rossum (gvanrossum)
Summary: tuple __getitem__ limited

Initial Comment:
The __getitem__ of a tuple does not support the
extended slicing. That makes it difficult to delegate
from an object's __getitem__ to a builtin container,
which ought to work through delegating __getitem__

<pre>
class GI:
    def __getitem__(self,a):
        print a

a = GI()
a[1:2]
(1,2,3,4).__getitem__(slice(1,2,None))
</pre>

gives

slice(1, 2, None)
Traceback (most recent call last):
  File "bar.py", line 7, in ?
    (1,2,3,4).__getitem__(slice(1,2,None))


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-06-13 12:25

Message:
Logged In: YES 
user_id=6656

Um, are you sure?

I still get

>>> (1,2,3).__getitem__(slice(1,2,3))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: an integer is required
[19426 refs]

Though:

>>> (1,2,3)[slice(1,2,3)]
(2,)
[19429 refs]

which is an improvement.

I guess this is for the same reason as #473985 is still open.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 11:34

Message:
Logged In: YES 
user_id=6380

MWH's patch has fixed this now.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-03 21:01

Message:
Logged In: YES 
user_id=6380

See (revived) patch 400998?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-06 18:08

Message:
Logged In: YES 
user_id=6380

This is not just the __getitem__ -- t[...] also has this
problem.
As a workaround, you can define __getslice__ or parse the
slice() object yourself.

I'll eventually get around to fixing this, but it's a bit
messy.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=459235&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 13:27:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 05:27:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-562188 ] test_signal.py fails on FreeBSD-4-stable
Message-ID: <E17IThJ-00032b-00@usw-sf-web3.sourceforge.net>

Bugs item #562188, was opened at 2002-05-30 05:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562188&group_id=5470

Category: Build
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Till Plewe (llit)
Assigned to: Michael Hudson (mwh)
Summary: test_signal.py fails on FreeBSD-4-stable

Initial Comment:
./python ./Lib/test/test_signal.py
starting pause() loop...
call pause()...
+ sleep 2
+ kill -5 80290
handlerA (5, <frame object at 0x8157e0c>)
pause() returned
call pause()...
+ sleep 2
+ kill -2 80290
handlerB (2, <frame object at 0x8157e0c>)
HandlerBCalled exception caught
call pause()...
+ sleep 2
+ kill -3 80290
KeyboardInterrupt (assume the alarm() went off)
blocking SIGHUP
sending SIGHUP
Traceback (most recent call last):
  File "./Lib/test/test_signal.py", line 92, in ?
    raise TestFailed, "HUP not pending"
test_support.TestFailed: HUP not pending


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-06-13 12:27

Message:
Logged In: YES 
user_id=6656

This is sorta fixed.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-30 09:15

Message:
Logged In: YES 
user_id=6656

My fault.  I'll dig.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562188&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 13:31:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 05:31:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-568134 ] asynchat module undocumented
Message-ID: <E17ITlP-00057N-00@usw-sf-web1.sourceforge.net>

Bugs item #568134, was opened at 2002-06-12 13:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568134&group_id=5470

Category: Documentation
>Group: Feature Request
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Jason R. Mastaler (jasonrm)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: asynchat module undocumented

Initial Comment:
While asyncore is documented, asynchat 
is not.

Lack of documentation makes asynchat
more difficult to understand/use than it
should be.



----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-13 08:31

Message:
Logged In: YES 
user_id=3066

Agreed.  Can you contribute a section for this module?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568134&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 13:36:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 05:36:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-568269 ] Misleading string constant.
Message-ID: <E17ITpw-0005AF-00@usw-sf-web1.sourceforge.net>

Bugs item #568269, was opened at 2002-06-12 18:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568269&group_id=5470

Category: Documentation
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Bjorn Pettersen (bpettersen)
>Assigned to: Tim Peters (tim_one)
Summary: Misleading string constant.

Initial Comment:
In _winreg.ConnectRegistry() it says:

computer_name is the name of the remote computer, of 
the form "\computername". If None, the local computer 
is used. 

Could it be changed to use r"\computername"? (it just 
took me half an hour to figure out why it couldn't find the 
computer on the network, and I really should know 
better :-)

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-13 08:36

Message:
Logged In: YES 
user_id=3066

Tim, can you tell me what the right thing is?  I don't have
enough Windows Registry Zen to know.  Feel free to assign
back to me for action.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568269&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 13:43:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 05:43:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-563273 ] Clarify documentation for inspect
Message-ID: <E17ITwZ-0003PZ-00@usw-sf-web3.sourceforge.net>

Bugs item #563273, was opened at 2002-06-01 08:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563273&group_id=5470

Category: Documentation
Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Franc,ois Pinard (pinard)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Clarify documentation for inspect

Initial Comment:
See attached message text.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-13 08:43

Message:
Logged In: YES 
user_id=3066

No message was attached, please try again.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563273&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 13:45:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 05:45:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-567605 ] setup.py ignores env and uses wrong libs
Message-ID: <E17ITym-0003SI-00@usw-sf-web3.sourceforge.net>

Bugs item #567605, was opened at 2002-06-11 22:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567605&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Marc Lehmann (pcg)
Assigned to: Nobody/Anonymous (nobody)
Summary: setup.py ignores env and uses wrong libs

Initial Comment:
tcl/tk and lot's of other libs reside in /opt/lib and
/opt/include on my system. CPPFLAGS and LDFLAGS reflect
this. python doesn't find anything in /opt, though, as
setup.py completely ignores this.

To debug this, I added a print libdirs after the line:

        lib_dirs = self.compiler.library_dirs +
['/lib', '/usr/lib']

and found that "lib_dirs" contains "/usr/local/lib",
which is completely bogus (but not wrong) (prefix is
/opt/python, my compiler doesn't search for /usr/local
etc.), "/lib" and "/usr/lib".

My system:

linux (2.4), glibc-2.2.5, every package is in
/opt/packagename, symlinked to common subdirs in
/opt/lib etc,,

LDFLAGS=-L/usr/app/lib -L/opt/lib
CPPFLAGS=-I/usr/app/include -I/opt/include
CFLAGS=-O3 -g -pipe -march=pentium -mcpu=pentiumpro
-momit-leaf-frame-pointer



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-13 14:45

Message:
Logged In: YES 
user_id=21627

autoconf is used to aid portability of the interpreter
proper, and certain core modules; not for general
integration of all extension modules (like _tkinter).

The documentation you quote is correct: configure does
determine your system configuration and creates the Makefile.

----------------------------------------------------------------------

Comment By: Marc Lehmann (pcg)
Date: 2002-06-13 13:51

Message:
Logged In: YES 
user_id=8851

If this is expected behaviour, then why does python come
with a configure script at all? I find it confusing when a
software package imitates a common standard (autoconf) and
then doesn't really implement it.

In any case, if it isn't a sofwtare bug then it's a
documentation bug, as the README claims:

   Start by running the script "./configure", which
determines your
   system configuration and creates the Makefile

which is clearly not the case, as it would be with any other
software package.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-11 22:28

Message:
Logged In: YES 
user_id=21627

I don't think this is a bug. If you use a certain
configuration not supported by setup.py, you need to edit
Modules/Setup manually.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567605&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 13:51:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 05:51:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-567605 ] setup.py ignores env and uses wrong libs
Message-ID: <E17IU4Z-0003Yp-00@usw-sf-web3.sourceforge.net>

Bugs item #567605, was opened at 2002-06-11 22:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567605&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Marc Lehmann (pcg)
Assigned to: Nobody/Anonymous (nobody)
Summary: setup.py ignores env and uses wrong libs

Initial Comment:
tcl/tk and lot's of other libs reside in /opt/lib and
/opt/include on my system. CPPFLAGS and LDFLAGS reflect
this. python doesn't find anything in /opt, though, as
setup.py completely ignores this.

To debug this, I added a print libdirs after the line:

        lib_dirs = self.compiler.library_dirs +
['/lib', '/usr/lib']

and found that "lib_dirs" contains "/usr/local/lib",
which is completely bogus (but not wrong) (prefix is
/opt/python, my compiler doesn't search for /usr/local
etc.), "/lib" and "/usr/lib".

My system:

linux (2.4), glibc-2.2.5, every package is in
/opt/packagename, symlinked to common subdirs in
/opt/lib etc,,

LDFLAGS=-L/usr/app/lib -L/opt/lib
CPPFLAGS=-I/usr/app/include -I/opt/include
CFLAGS=-O3 -g -pipe -march=pentium -mcpu=pentiumpro
-momit-leaf-frame-pointer



----------------------------------------------------------------------

>Comment By: Marc Lehmann (pcg)
Date: 2002-06-13 14:51

Message:
Logged In: YES 
user_id=8851

On my system it obviously doesn't detect the configuration
(see env-variables, which are ignored etc.). But it's your
bug, not my bug. If you don't care to fix then I feel fine
;->

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-13 14:45

Message:
Logged In: YES 
user_id=21627

autoconf is used to aid portability of the interpreter
proper, and certain core modules; not for general
integration of all extension modules (like _tkinter).

The documentation you quote is correct: configure does
determine your system configuration and creates the Makefile.

----------------------------------------------------------------------

Comment By: Marc Lehmann (pcg)
Date: 2002-06-13 13:51

Message:
Logged In: YES 
user_id=8851

If this is expected behaviour, then why does python come
with a configure script at all? I find it confusing when a
software package imitates a common standard (autoconf) and
then doesn't really implement it.

In any case, if it isn't a sofwtare bug then it's a
documentation bug, as the README claims:

   Start by running the script "./configure", which
determines your
   system configuration and creates the Makefile

which is clearly not the case, as it would be with any other
software package.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-11 22:28

Message:
Logged In: YES 
user_id=21627

I don't think this is a bug. If you use a certain
configuration not supported by setup.py, you need to edit
Modules/Setup manually.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567605&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 13:57:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 05:57:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-568134 ] asynchat module undocumented
Message-ID: <E17IUAR-0005Vu-00@usw-sf-web1.sourceforge.net>

Bugs item #568134, was opened at 2002-06-13 03:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568134&group_id=5470

Category: Documentation
Group: Feature Request
>Status: Open
Resolution: None
Priority: 5
Submitted By: Jason R. Mastaler (jasonrm)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: asynchat module undocumented

Initial Comment:
While asyncore is documented, asynchat 
is not.

Lack of documentation makes asynchat
more difficult to understand/use than it
should be.



----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-06-13 22:57

Message:
Logged In: YES 
user_id=29957

... if not, I can probably try to get something in a week or
two. I've got a current project that uses it. 

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-13 22:31

Message:
Logged In: YES 
user_id=3066

Agreed.  Can you contribute a section for this module?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568134&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 14:35:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 06:35:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-568412 ] minor improvement to Grammar file
Message-ID: <E17IUl2-0004jr-00@usw-sf-web4.sourceforge.net>

Bugs item #568412, was opened at 2002-06-13 04:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568412&group_id=5470

Category: Parser/Compiler
Group: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Y. Kim (emacsman)
Assigned to: Nobody/Anonymous (nobody)
Summary: minor improvement to Grammar file

Initial Comment:
The 'print_stmt' non-terminal duplicates the rule for
'testlist'
non-terminal. The diff shown below replaces the
duplicate rule with
'testlist'.

$ diff -c Grammar-orig Grammar
*** Grammar-orig	Thu Jun 13 00:53:53 2002
--- Grammar	Thu Jun 13 00:54:16 2002
***************
*** 40,46 ****
  expr_stmt: testlist (augassign testlist | ('='
testlist)*)
  augassign: '+=' | '-=' | '*=' | '/=' | '%=' | '&=' |
'|=' | '^=' | '<<=' | '>>=' | '**=' | '//='
  # For normal assignments, additional restrictions
enforced by the interpreter
! print_stmt: 'print' ( [ test (',' test)* [','] ] |
'>>' test [ (',' test)+ [','] ] )
  del_stmt: 'del' exprlist
  pass_stmt: 'pass'
  flow_stmt: break_stmt | continue_stmt | return_stmt |
raise_stmt | yield_stmt
--- 40,46 ----
  expr_stmt: testlist (augassign testlist | ('='
testlist)*)
  augassign: '+=' | '-=' | '*=' | '/=' | '%=' | '&=' |
'|=' | '^=' | '<<=' | '>>=' | '**=' | '//='
  # For normal assignments, additional restrictions
enforced by the interpreter
! print_stmt: 'print' ( [testlist] | '>>' test [ (','
test)+ [','] ] )
  del_stmt: 'del' exprlist
  pass_stmt: 'pass'
  flow_stmt: break_stmt | continue_stmt | return_stmt |
raise_stmt | yield_stmt


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-06-13 09:35

Message:
Logged In: YES 
user_id=31435

Note that Python's parser tables are automatically generated 
from this file, so any change to the Grammar file generally 
requires altering Python compilers too.  Also changes to the 
Reference Manual and test suite.  That's a lot of work for 
something that doesn't matter <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568412&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 14:41:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 06:41:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-567605 ] setup.py ignores env and uses wrong libs
Message-ID: <E17IUqc-0005Bb-00@usw-sf-web2.sourceforge.net>

Bugs item #567605, was opened at 2002-06-11 22:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567605&group_id=5470

Category: Build
Group: Python 2.2.1
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Marc Lehmann (pcg)
Assigned to: Nobody/Anonymous (nobody)
Summary: setup.py ignores env and uses wrong libs

Initial Comment:
tcl/tk and lot's of other libs reside in /opt/lib and
/opt/include on my system. CPPFLAGS and LDFLAGS reflect
this. python doesn't find anything in /opt, though, as
setup.py completely ignores this.

To debug this, I added a print libdirs after the line:

        lib_dirs = self.compiler.library_dirs +
['/lib', '/usr/lib']

and found that "lib_dirs" contains "/usr/local/lib",
which is completely bogus (but not wrong) (prefix is
/opt/python, my compiler doesn't search for /usr/local
etc.), "/lib" and "/usr/lib".

My system:

linux (2.4), glibc-2.2.5, every package is in
/opt/packagename, symlinked to common subdirs in
/opt/lib etc,,

LDFLAGS=-L/usr/app/lib -L/opt/lib
CPPFLAGS=-I/usr/app/include -I/opt/include
CFLAGS=-O3 -g -pipe -march=pentium -mcpu=pentiumpro
-momit-leaf-frame-pointer



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-13 15:41

Message:
Logged In: YES 
user_id=21627

Ok, closing the report.

----------------------------------------------------------------------

Comment By: Marc Lehmann (pcg)
Date: 2002-06-13 14:51

Message:
Logged In: YES 
user_id=8851

On my system it obviously doesn't detect the configuration
(see env-variables, which are ignored etc.). But it's your
bug, not my bug. If you don't care to fix then I feel fine
;->

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-13 14:45

Message:
Logged In: YES 
user_id=21627

autoconf is used to aid portability of the interpreter
proper, and certain core modules; not for general
integration of all extension modules (like _tkinter).

The documentation you quote is correct: configure does
determine your system configuration and creates the Makefile.

----------------------------------------------------------------------

Comment By: Marc Lehmann (pcg)
Date: 2002-06-13 13:51

Message:
Logged In: YES 
user_id=8851

If this is expected behaviour, then why does python come
with a configure script at all? I find it confusing when a
software package imitates a common standard (autoconf) and
then doesn't really implement it.

In any case, if it isn't a sofwtare bug then it's a
documentation bug, as the README claims:

   Start by running the script "./configure", which
determines your
   system configuration and creates the Makefile

which is clearly not the case, as it would be with any other
software package.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-11 22:28

Message:
Logged In: YES 
user_id=21627

I don't think this is a bug. If you use a certain
configuration not supported by setup.py, you need to edit
Modules/Setup manually.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567605&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 16:48:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 08:48:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-216388 ] cStringIO rejects Unicode strings
Message-ID: <E17IWpu-0005sO-00@usw-sf-web3.sourceforge.net>

Bugs item #216388, was opened at 2000-10-08 20:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216388&group_id=5470

Category: Unicode
Group: Feature Request
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Paul Prescod (prescod)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: cStringIO rejects Unicode strings

Initial Comment:
>>> 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


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-13 11:48

Message:
Logged In: YES 
user_id=3066

SF tracker item 547537 gives me an "invalid artifact ID"
message, at least when using:

    http://www.python.org/sf/547537

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-23 08:55

Message:
Logged In: YES 
user_id=6380

Let's please move this discussion to a new bug report on the
new problem. I've opened one, 547537, and summarized the
issue there. I've assigned ot to MAL.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-04-23 03:10

Message:
Logged In: YES 
user_id=29957

well, StringIO does the correct thing (returns back
a unicode string), fwiw. 

the offending checkin for cStringIO was 2.30. The commit
log is:

  date: 2001/09/24 17:34:52;  author: lemburg;  state: Exp;
 lines: +5 -9
  StringIO patch #462596: let's [c]StringIO accept read
buffers on
  input to .write() too.

The referenced patch is actually doing a bit more than
'write':
  This patch allows using arbitrary read-buffer
  compatible objects as basis for StringIO and cStringIO
  objects.

I'm not sure what on the appropriate way to fix this

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-18 08:53

Message:
Logged In: YES 
user_id=6380

Hm, that's bad. An error on write(u"...") is much preferred
over wreiting garbage. :-(

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-04-18 02:38

Message:
Logged In: YES 
user_id=29957

Hm. This no longer produces the above error. However, it
now produces:
>>> import cStringIO 
>>> s=cStringIO.StringIO(u"abcdefgh") 
>>> s.getvalue()
'a\x00b\x00c\x00d\x00e\x00f\x00g\x00h\x00'

Should it produce a unicode string back? 
(thought I'd go through some of the older sf bugs)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-04-04 06:18

Message:
Logged In: NO 

9;lo;;99999999999999999999999

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 17:31

Message:
Logged In: YES 
user_id=31392

Setting back to normal priority for 2.2


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-16 21:29

Message:
Lowered priority to reflect my previous comments; I don't think I'll have time to do this for Python 2.1.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-10 11:07

Message:
Status:  Jim said I can work on it, but the priority isn't very high for him.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-07 22:56

Message:
Ok, ok, ok... I've sent a prod to appropriate people.  This *should* be interesting to have done.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-12-12 16:00

Message:
Assigned to Fred -- maybe you can prod Jim into looking into this.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2000-10-09 04:34

Message:
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).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216388&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 17:11:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 09:11:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-568577 ] locale.getlocale() returns a list
Message-ID: <E17IXCZ-0001FK-00@usw-sf-web1.sourceforge.net>

Bugs item #568577, was opened at 2002-06-13 12:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568577&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: locale.getlocale() returns a list

Initial Comment:
The docs for locale.getlocale() say it returns a tuple,
but:

>>> locale.getlocale()
['en_US', 'ISO8859-15']

it's really a list. ;)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568577&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 17:02:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 09:02:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-216388 ] cStringIO rejects Unicode strings
Message-ID: <E17IX3Q-00012T-00@usw-sf-web1.sourceforge.net>

Bugs item #216388, was opened at 2000-10-08 20:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216388&group_id=5470

Category: Unicode
Group: Feature Request
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Paul Prescod (prescod)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: cStringIO rejects Unicode strings

Initial Comment:
>>> 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


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 12:02

Message:
Logged In: YES 
user_id=6380

It's a feature request. Here's the full URL:

http://sourceforge.net/tracker/?func=detail&aid=547537&group_id=5470&atid=355470

I dunno why the redirector doesn't know about it.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-13 11:48

Message:
Logged In: YES 
user_id=3066

SF tracker item 547537 gives me an "invalid artifact ID"
message, at least when using:

    http://www.python.org/sf/547537

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-23 08:55

Message:
Logged In: YES 
user_id=6380

Let's please move this discussion to a new bug report on the
new problem. I've opened one, 547537, and summarized the
issue there. I've assigned ot to MAL.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-04-23 03:10

Message:
Logged In: YES 
user_id=29957

well, StringIO does the correct thing (returns back
a unicode string), fwiw. 

the offending checkin for cStringIO was 2.30. The commit
log is:

  date: 2001/09/24 17:34:52;  author: lemburg;  state: Exp;
 lines: +5 -9
  StringIO patch #462596: let's [c]StringIO accept read
buffers on
  input to .write() too.

The referenced patch is actually doing a bit more than
'write':
  This patch allows using arbitrary read-buffer
  compatible objects as basis for StringIO and cStringIO
  objects.

I'm not sure what on the appropriate way to fix this

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-18 08:53

Message:
Logged In: YES 
user_id=6380

Hm, that's bad. An error on write(u"...") is much preferred
over wreiting garbage. :-(

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-04-18 02:38

Message:
Logged In: YES 
user_id=29957

Hm. This no longer produces the above error. However, it
now produces:
>>> import cStringIO 
>>> s=cStringIO.StringIO(u"abcdefgh") 
>>> s.getvalue()
'a\x00b\x00c\x00d\x00e\x00f\x00g\x00h\x00'

Should it produce a unicode string back? 
(thought I'd go through some of the older sf bugs)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-04-04 06:18

Message:
Logged In: NO 

9;lo;;99999999999999999999999

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 17:31

Message:
Logged In: YES 
user_id=31392

Setting back to normal priority for 2.2


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-16 21:29

Message:
Lowered priority to reflect my previous comments; I don't think I'll have time to do this for Python 2.1.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-10 11:07

Message:
Status:  Jim said I can work on it, but the priority isn't very high for him.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-07 22:56

Message:
Ok, ok, ok... I've sent a prod to appropriate people.  This *should* be interesting to have done.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-12-12 16:00

Message:
Assigned to Fred -- maybe you can prod Jim into looking into this.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2000-10-09 04:34

Message:
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).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216388&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 17:23:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 09:23:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-493951 ] string.{starts,ends}with vs slices
Message-ID: <E17IXNZ-0008DJ-00@usw-sf-web4.sourceforge.net>

Bugs item #493951, was opened at 2001-12-16 14:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493951&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: string.{starts,ends}with vs slices

Initial Comment:
The attached test shows many cases where 
string.startswith() and string.endswith() fail to 
handle negative slice indices correctly.  The failures 
are in both the start and end indices.  I stumbled 
into this when tracking down why (what turned out to 
be) this didn't work:

>>> file = 'difflib.pyc'
>>> file.endswith('.py', 0, -1) # should be 1
0
>>> file[0:-1].endswith('.py')  # like this is
1
>>>

Can we risk changing this for 2.2?  Don't know.  If 
not, reduce the priority.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 12:23

Message:
Logged In: YES 
user_id=6380

Check in in, Neal. (Barry is too busy to watch SF.)

Would you mind adding unit tests?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-12 18:08

Message:
Logged In: YES 
user_id=33168

Attached is a patch which implements this behaviour.
Still need a patch for tests and the doc.
This passes all regressions and Tim's test.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 10:31

Message:
Logged In: YES 
user_id=6380

We should fix this in 2.3 at the very least. Leave 2.2.x
alone.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-04-22 10:11

Message:
Logged In: YES 
user_id=12800

The comment in the code reminds me that we adopted the
semantics for Java's String.startsWith() and String.endsWith(): 

http://java.sun.com/products/jdk/1.2/docs/api/java/lang/String.html#startsWith(java.lang.String,%20int)

which treats negative indices as errors (at least for the
start parameter -- which we generalized to include the end
parameter).  Changing this is a semantic change to the
string methods, so I don't think it should be undertaken
lightly (i.e. as a bug in the current implementation).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-16 15:03

Message:
Logged In: YES 
user_id=31435

I can't guess what the docs intended to say (they're vague -
- I can read them several ways).

In all other cases where optional string-method args 
named "start" and "end" are accepted (find(), rfind(), count
(), index(), rindex()), the docs are clear that they're 
interpreted as slice notation.  It doesn't make sense for 
the two newest methods to behave differently in this 
respect.

The unit tests aren't evidence one way or the other to me --
 the behavior of negative indices should be covered by the 
tests no matter what the intended semantics.

Overall, I expect the behavior here is an accident (as 
opposed to intended).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-16 14:45

Message:
Logged In: YES 
user_id=6380

Hm, the docs don't exactly suggest that negative indices
would be supported. While that would be nice, it's
definitely a feature request, so no, please don't do this in
2.2. (The absent of unit tests for negative indices also
suggests this was not an oversight. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-16 14:24

Message:
Logged In: YES 
user_id=31435

Attached the test case.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493951&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 17:33:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 09:33:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-567605 ] setup.py ignores env and uses wrong libs
Message-ID: <E17IXX7-0008Nx-00@usw-sf-web4.sourceforge.net>

Bugs item #567605, was opened at 2002-06-11 15:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567605&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Marc Lehmann (pcg)
Assigned to: Nobody/Anonymous (nobody)
Summary: setup.py ignores env and uses wrong libs

Initial Comment:
tcl/tk and lot's of other libs reside in /opt/lib and
/opt/include on my system. CPPFLAGS and LDFLAGS reflect
this. python doesn't find anything in /opt, though, as
setup.py completely ignores this.

To debug this, I added a print libdirs after the line:

        lib_dirs = self.compiler.library_dirs +
['/lib', '/usr/lib']

and found that "lib_dirs" contains "/usr/local/lib",
which is completely bogus (but not wrong) (prefix is
/opt/python, my compiler doesn't search for /usr/local
etc.), "/lib" and "/usr/lib".

My system:

linux (2.4), glibc-2.2.5, every package is in
/opt/packagename, symlinked to common subdirs in
/opt/lib etc,,

LDFLAGS=-L/usr/app/lib -L/opt/lib
CPPFLAGS=-I/usr/app/include -I/opt/include
CFLAGS=-O3 -g -pipe -march=pentium -mcpu=pentiumpro
-momit-leaf-frame-pointer



----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2002-06-13 11:33

Message:
Logged In: YES 
user_id=44345

I believe if you set LIBDIR and INCLUDEDIR environment 
variables you can coax setup.py into looking in alternate 
directories for libraries and include files, respectively.

Distutils should probably be modified to allow either to be a 
colon-separated list of directories.  I think you are restricted 
to a single directory for each at the moment.  Also, the 
names are a bit generic.  Perhaps something more 
Python-specific would be better.

Skip


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-13 08:41

Message:
Logged In: YES 
user_id=21627

Ok, closing the report.

----------------------------------------------------------------------

Comment By: Marc Lehmann (pcg)
Date: 2002-06-13 07:51

Message:
Logged In: YES 
user_id=8851

On my system it obviously doesn't detect the configuration
(see env-variables, which are ignored etc.). But it's your
bug, not my bug. If you don't care to fix then I feel fine
;->

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-13 07:45

Message:
Logged In: YES 
user_id=21627

autoconf is used to aid portability of the interpreter
proper, and certain core modules; not for general
integration of all extension modules (like _tkinter).

The documentation you quote is correct: configure does
determine your system configuration and creates the Makefile.

----------------------------------------------------------------------

Comment By: Marc Lehmann (pcg)
Date: 2002-06-13 06:51

Message:
Logged In: YES 
user_id=8851

If this is expected behaviour, then why does python come
with a configure script at all? I find it confusing when a
software package imitates a common standard (autoconf) and
then doesn't really implement it.

In any case, if it isn't a sofwtare bug then it's a
documentation bug, as the README claims:

   Start by running the script "./configure", which
determines your
   system configuration and creates the Makefile

which is clearly not the case, as it would be with any other
software package.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-11 15:28

Message:
Logged In: YES 
user_id=21627

I don't think this is a bug. If you use a certain
configuration not supported by setup.py, you need to edit
Modules/Setup manually.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=567605&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 18:52:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 10:52:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-568134 ] asynchat module undocumented
Message-ID: <E17IYlY-0003IT-00@usw-sf-web1.sourceforge.net>

Bugs item #568134, was opened at 2002-06-12 11:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568134&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason R. Mastaler (jasonrm)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: asynchat module undocumented

Initial Comment:
While asyncore is documented, asynchat 
is not.

Lack of documentation makes asynchat
more difficult to understand/use than it
should be.



----------------------------------------------------------------------

>Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-06-13 11:52

Message:
Logged In: YES 
user_id=85984

I think it would be better for Anthony
to write the documentation.  I don't 
understand it very well myself (which is
why I was looking for docs in the first
place <wink>).



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-06-13 06:57

Message:
Logged In: YES 
user_id=29957

... if not, I can probably try to get something in a week or
two. I've got a current project that uses it. 

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-13 06:31

Message:
Logged In: YES 
user_id=3066

Agreed.  Can you contribute a section for this module?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568134&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 18:56:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 10:56:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-568577 ] locale.getlocale() returns a list
Message-ID: <E17IYph-0007el-00@usw-sf-web3.sourceforge.net>

Bugs item #568577, was opened at 2002-06-13 12:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568577&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: locale.getlocale() returns a list

Initial Comment:
The docs for locale.getlocale() say it returns a tuple,
but:

>>> locale.getlocale()
['en_US', 'ISO8859-15']

it's really a list. ;)


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-13 13:56

Message:
Logged In: YES 
user_id=3066

It's worse than this: getlocale() returns either a list or a
tuple, so I'm documenting this as a sequence.  Ugh.

Fixed in Doc/lib/liblocale.tex revisions 1.30, 1.27.8.1, and
1.22.4.2.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568577&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 20:07:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 12:07:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-493951 ] string.{starts,ends}with vs slices
Message-ID: <E17IZwP-00049U-00@usw-sf-web2.sourceforge.net>

Bugs item #493951, was opened at 2001-12-16 14:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493951&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: string.{starts,ends}with vs slices

Initial Comment:
The attached test shows many cases where 
string.startswith() and string.endswith() fail to 
handle negative slice indices correctly.  The failures 
are in both the start and end indices.  I stumbled 
into this when tracking down why (what turned out to 
be) this didn't work:

>>> file = 'difflib.pyc'
>>> file.endswith('.py', 0, -1) # should be 1
0
>>> file[0:-1].endswith('.py')  # like this is
1
>>>

Can we risk changing this for 2.2?  Don't know.  If 
not, reduce the priority.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-13 15:07

Message:
Logged In: YES 
user_id=33168

I'll update the tests & doc before checking in.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 12:23

Message:
Logged In: YES 
user_id=6380

Check in in, Neal. (Barry is too busy to watch SF.)

Would you mind adding unit tests?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-12 18:08

Message:
Logged In: YES 
user_id=33168

Attached is a patch which implements this behaviour.
Still need a patch for tests and the doc.
This passes all regressions and Tim's test.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 10:31

Message:
Logged In: YES 
user_id=6380

We should fix this in 2.3 at the very least. Leave 2.2.x
alone.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-04-22 10:11

Message:
Logged In: YES 
user_id=12800

The comment in the code reminds me that we adopted the
semantics for Java's String.startsWith() and String.endsWith(): 

http://java.sun.com/products/jdk/1.2/docs/api/java/lang/String.html#startsWith(java.lang.String,%20int)

which treats negative indices as errors (at least for the
start parameter -- which we generalized to include the end
parameter).  Changing this is a semantic change to the
string methods, so I don't think it should be undertaken
lightly (i.e. as a bug in the current implementation).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-16 15:03

Message:
Logged In: YES 
user_id=31435

I can't guess what the docs intended to say (they're vague -
- I can read them several ways).

In all other cases where optional string-method args 
named "start" and "end" are accepted (find(), rfind(), count
(), index(), rindex()), the docs are clear that they're 
interpreted as slice notation.  It doesn't make sense for 
the two newest methods to behave differently in this 
respect.

The unit tests aren't evidence one way or the other to me --
 the behavior of negative indices should be covered by the 
tests no matter what the intended semantics.

Overall, I expect the behavior here is an accident (as 
opposed to intended).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-16 14:45

Message:
Logged In: YES 
user_id=6380

Hm, the docs don't exactly suggest that negative indices
would be supported. While that would be nice, it's
definitely a feature request, so no, please don't do this in
2.2. (The absent of unit tests for negative indices also
suggests this was not an oversight. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-16 14:24

Message:
Logged In: YES 
user_id=31435

Attached the test case.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493951&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 20:24:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 12:24:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-459235 ] tuple __getitem__ limited
Message-ID: <E17IaDL-0003MP-00@usw-sf-web4.sourceforge.net>

Bugs item #459235, was opened at 2001-09-06 13:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=459235&group_id=5470

Category: Type/class unification
Group: Python 2.2
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Guido van Rossum (gvanrossum)
Summary: tuple __getitem__ limited

Initial Comment:
The __getitem__ of a tuple does not support the
extended slicing. That makes it difficult to delegate
from an object's __getitem__ to a builtin container,
which ought to work through delegating __getitem__

<pre>
class GI:
    def __getitem__(self,a):
        print a

a = GI()
a[1:2]
(1,2,3,4).__getitem__(slice(1,2,None))
</pre>

gives

slice(1, 2, None)
Traceback (most recent call last):
  File "bar.py", line 7, in ?
    (1,2,3,4).__getitem__(slice(1,2,None))


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 15:24

Message:
Logged In: YES 
user_id=6380

OK, this is now *really* fixed.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-06-13 08:25

Message:
Logged In: YES 
user_id=6656

Um, are you sure?

I still get

>>> (1,2,3).__getitem__(slice(1,2,3))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: an integer is required
[19426 refs]

Though:

>>> (1,2,3)[slice(1,2,3)]
(2,)
[19429 refs]

which is an improvement.

I guess this is for the same reason as #473985 is still open.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 07:34

Message:
Logged In: YES 
user_id=6380

MWH's patch has fixed this now.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-03 17:01

Message:
Logged In: YES 
user_id=6380

See (revived) patch 400998?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-06 14:08

Message:
Logged In: YES 
user_id=6380

This is not just the __getitem__ -- t[...] also has this
problem.
As a workaround, you can define __getslice__ or parse the
slice() object yourself.

I'll eventually get around to fixing this, but it's a bit
messy.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=459235&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 20:25:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 12:25:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-473985 ] str, __getitem__ and slices
Message-ID: <E17IaDt-0004fw-00@usw-sf-web1.sourceforge.net>

Bugs item #473985, was opened at 2001-10-23 06:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=473985&group_id=5470

Category: Type/class unification
Group: Python 2.3
>Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Guido van Rossum (gvanrossum)
Summary: str, __getitem__ and slices

Initial Comment:
Using slices with __getitem__ doesn't work with 
classes derived from str:
---
class S(str):
   def __getitem__(self, index):
      print "getitem", index
      return str.__getitem__(self, index)
   def __setitem__(self, index, value):
      print "setitem", index, value

s = S("foo")
print s[0]
print s[0:2]
s[0] = "b"
s[0:2] = "bar"
---
This prints:
---
getitem 0
f
fo
setitem 0 b
setitem slice(0, 2, None) bar
---
instead of
---
getitem 0
f
getitem slice(0, 2, None)
fo
setitem 0 b
setitem slice(0, 2, None) bar
---
i.e. when no __getslice__ is defined s[0:2] will not 
be forwarded to __getitem__, but it seems to work for 
__setitem__.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 15:25

Message:
Logged In: YES 
user_id=6380

OK, that part is now *really* fixed.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 07:49

Message:
Logged In: YES 
user_id=6380

Um, I have to reopen this, because I lied.

While "abc"[::] works, str.__getitem__("abc", slice(None))
doesn't. And ditto for tuples and lists. I think the
dispatcher tries the sequence getitem before the mapping
getitem.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 07:38

Message:
Logged In: YES 
user_id=6380

I'm closing this despite the fact that it's not 100% fixed.

Because the base class defines __getslice__, the derived
class will inherit this, so you'll have to override it. But
the base class __getitem__ accepts arbitrary slice objects
now.

(Perhaps it should be possible to explicitly set a method to
None to say "I'm not implementing this"? But that has all
sorts of other unforeseen consequences -- ptobably better
not. In the future, strings may lose their __getslice__
method, but for now I think that would slow things down too
much.)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-11 13:00

Message:
Logged In: YES 
user_id=6380

Um, that patch doesn't change the fact that strings have a 
__getslice__ method. Maybe that can be thrown out now 
though? str.__getitem__ now supports slice objects, so 
there's no need to have __getslice__ as well.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-03 17:01

Message:
Logged In: YES 
user_id=6380

See (revived) patch 400998?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:45

Message:
Logged In: YES 
user_id=6380

Raising the priority slightly and marking as a 2.3 issue.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-10-23 10:50

Message:
Logged In: YES 
user_id=6380

I've thought about this some more.

It should be fixed, but the fix is complex, and think I'd
rather not make this change in 2.2 -- (1) I have little
time, and (2) we've already issued a beta release and a
declared a feature freeze. So I'd like to put this on hold
until I can start working on 2.3. This is what would have to
be done:

- Change all built-in sequence types to get rid of the
sq_slice and sq_ass_slice dispatch functions; instead, add a
mapping extension to these types and add mp_subscript and
mp_ass_subscript dispatch functions that recognize slice
objects.

- We'd probably also have to get rid of the sq_item and
sq_ass_item dispatch functions, to roll them into
mp_subscript and mp_ass_subscript.

- Possibly, the whole "PySequenceMethods" structure should
be deprecated; all the operations there are overloading
either numerical or mapping operations.

Extension types that define a sequence methods structure
should continue to work, but the recommendation would be to
migrate these out.

I wish I could do this in 2.2, but it's really too much work
to start now, *and* it would be a serious incompatibility
between 2.2b1 and 2.2b2.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-10-23 10:05

Message:
Logged In: YES 
user_id=89016

Oops, this wasn't meant to be a patch. Should have gone 
into the bugs category.

The problems is that http://python.sourceforge.net/devel-
docs/ref/sequence-methods.html says, that __getslice__ 
is "Deprecated since release 2.0", so the user will want to 
implement __getslice__ via __getitem__.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-10-23 09:48

Message:
Logged In: YES 
user_id=6380

I don't think this is a bug. S inherits __getslice__ from
the str base class, but since str is immutable, it doesn't
define a __setslice__ to inherit for S.

BTW I'm reclassifying this as a bug, not a patch. This will
unfortunately invalidate the old URL you had for this entry
(SF doesn't really like reclassification that much.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=473985&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 21:03:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 13:03:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-563915 ] getttext defaults with unicode
Message-ID: <E17Iaoe-0005Uw-00@usw-sf-web2.sourceforge.net>

Bugs item #563915, was opened at 2002-06-03 11:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563915&group_id=5470

Category: Unicode
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Rikard Anglerud (anglerud)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: getttext defaults with unicode

Initial Comment:
When using gettext, and a token is not translated, for
example:
print _('Foo')
the output will be 'Foo', as expected. 
However, if that entry is:
print _(u'Foo')
we get:
Traceback (most recent call last):
  File "./translation.py", line 12, in ?
    print _(u'Foo')
  File "/usr/lib/python2.2/gettext.py", line 195, in
ugettext
    return unicode(tmsg, self._charset)
TypeError: decoding Unicode is not supported

----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-06-13 16:03

Message:
Logged In: YES 
user_id=12800

I will shortly post a patch that clarifies the documentation
to describe the GNU gettext recommendation that the source
message string should be us-ascii.  As that fixes things in
my mind, I'm closing this bug report.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-06-04 11:54

Message:
Logged In: YES 
user_id=12800

I agree with Martin, you shouldn't be passing unicode
strings to ugettext().  I don't think it's worth doing a
type test in ugettext(); maybe we simply need to improve the
documentation?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-04 05:35

Message:
Logged In: YES 
user_id=38388

Barry will know what to do...

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-04 05:28

Message:
Logged In: YES 
user_id=21627

I'm not sure this is a bug: they keys in a message catalog
are really byte strings. So it is an error to use Unicode
strings as arguments to _.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563915&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 21:41:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 13:41:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-532646 ] Recursive class instance "error"
Message-ID: <E17IbP7-00061Y-00@usw-sf-web2.sourceforge.net>

Bugs item #532646, was opened at 2002-03-20 13:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Gregor Mirai (gregmi)
Assigned to: Guido van Rossum (gvanrossum)
>Summary: Recursive class instance "error"

Initial Comment:
If one writes the following code (tested on Python  
2.1, 2.2 on platforms MacOS X Server, MacOS X, Windows 
98, NT, 2000) one can easily produce several "errors".

MacOS X, MacOS X Server (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name,
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
Segmentation fault

Win98, NT, 2000 (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
foo
__repr__ __call__ __call__ __call__ ... ad inf



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 16:41

Message:
Logged In: YES 
user_id=6380

Hm. I'm tracing this in the debugger now, and it appears
that the problem is when trying to *print* an A instance.
The statement a.foo causes the problem simply because it
returns an A instance. (Proof: "a=A().foo; print a" fails in
the print.)

I think that instance_call may not be the real cause of the
problem...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-12 18:38

Message:
Logged In: YES 
user_id=33168

The problem is that there is mutual recursion
between instance_call() and PyObject_Call().
The recursion apparently goes through the eval_frame() loop.

This patch increases the recursion depth so the mutual recursion
will eventually end (otherwise, the stack grows without bounds).

ISTM the first check SHOULD be reached, but it is not.
I don't understand why.  The recursion error must be set
in eval_frame().

The first block in the patch could be just this line:
    ++tstate->recursion_depth;

I didn't do it that way, since I didn't expect returning to
eval_frame().  I'm not sure if it's guaranteed to return
to eval_frame() which is why I left the first condition
in with the comment.  I suppose the comment should say
something like:  /* this condition doesn't seem to be triggered,
the recursion depth limit is exceeded in eval_frame */

The test for recursion_depth is necessary to ensure
that the recursion error isn't overwritten.  If this check
is removed, the follow exception is raised:
    AttributeError: A instance has no __call__ method

Hopefully this makes sense.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 12:08

Message:
Logged In: YES 
user_id=6380

Can you explain how the fix works? Why does the first
comment say

/* this shouldn't be reached, but just in case */

and why is this test necesary

if (tstate->recursion_depth < Py_GetRecursionLimit()) {

???

And who *does* report the recursion error?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 18:52

Message:
Logged In: YES 
user_id=33168

The recursion fields are shared in the new patch.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 16:35

Message:
Logged In: YES 
user_id=33168

That sounds more reasonable.
I'll take a look and see if they can be integrated.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-07 16:27

Message:
Logged In: YES 
user_id=6380

Fair enough.  Ideally this should share the recursion_limit
variable from ceval.c and the recursion_depth field of the
stack frame.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 16:23

Message:
Logged In: YES 
user_id=33168

I don't know.  I tried to come up with other test cases and
failed.
Tried __str__ and __getitem__.  Also tried new-style classes.

The problem was that the code bounced back and forth
between PyObject_Call() & instance_call() (mutual recursion).


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-07 16:08

Message:
Logged In: YES 
user_id=6380

Is this fix enough?  Aren't there lots of other ways to
generate the same error?  E.g. new-style classes (where this
particular example doesn't apply, but others might).

Or is this specific to instance_call?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 15:21

Message:
Logged In: YES 
user_id=33168

The attached patch stops the segfault and raises an exception:
TypeError: 'A' max recursion limit (100000) exceeded

I'm not sure if this is genarally applicable, or what a
reasonable # is.
100,000 was a guess and should probably be made a #def
w/comment.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-21 04:47

Message:
Logged In: NO 

>>> a=A() 
>>> a.foo 
foo 
__repr__ __call__ __call__ __call__ ... ad inf

This is normal behavior. The code at the top is buggy. The 
correct one is:

class A:
  def __getattr__(self, name):
    if name == '__repr__':
      return self.__repr__()
    print name
    return A()

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-20 17:10

Message:
Logged In: YES 
user_id=6380

This is buggy user code.

But the segfault should be fixed if possible.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 22:50:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 14:50:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-532646 ] Recursive class instance "error"
Message-ID: <E17IcUQ-0007Vl-00@usw-sf-web1.sourceforge.net>

Bugs item #532646, was opened at 2002-03-20 13:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
>Priority: 5
Submitted By: Gregor Mirai (gregmi)
Assigned to: Guido van Rossum (gvanrossum)
>Summary: Recursive class instance "error"

Initial Comment:
If one writes the following code (tested on Python  
2.1, 2.2 on platforms MacOS X Server, MacOS X, Windows 
98, NT, 2000) one can easily produce several "errors".

MacOS X, MacOS X Server (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name,
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
Segmentation fault

Win98, NT, 2000 (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
foo
__repr__ __call__ __call__ __call__ ... ad inf



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 17:50

Message:
Logged In: YES 
user_id=6380

It was very specific to __call__ after all, and I found an
example that didn't involve __getattr__. See the comments I
checked in as part of the fix in classobject.c.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 16:41

Message:
Logged In: YES 
user_id=6380

Hm. I'm tracing this in the debugger now, and it appears
that the problem is when trying to *print* an A instance.
The statement a.foo causes the problem simply because it
returns an A instance. (Proof: "a=A().foo; print a" fails in
the print.)

I think that instance_call may not be the real cause of the
problem...

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-12 18:38

Message:
Logged In: YES 
user_id=33168

The problem is that there is mutual recursion
between instance_call() and PyObject_Call().
The recursion apparently goes through the eval_frame() loop.

This patch increases the recursion depth so the mutual recursion
will eventually end (otherwise, the stack grows without bounds).

ISTM the first check SHOULD be reached, but it is not.
I don't understand why.  The recursion error must be set
in eval_frame().

The first block in the patch could be just this line:
    ++tstate->recursion_depth;

I didn't do it that way, since I didn't expect returning to
eval_frame().  I'm not sure if it's guaranteed to return
to eval_frame() which is why I left the first condition
in with the comment.  I suppose the comment should say
something like:  /* this condition doesn't seem to be triggered,
the recursion depth limit is exceeded in eval_frame */

The test for recursion_depth is necessary to ensure
that the recursion error isn't overwritten.  If this check
is removed, the follow exception is raised:
    AttributeError: A instance has no __call__ method

Hopefully this makes sense.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 12:08

Message:
Logged In: YES 
user_id=6380

Can you explain how the fix works? Why does the first
comment say

/* this shouldn't be reached, but just in case */

and why is this test necesary

if (tstate->recursion_depth < Py_GetRecursionLimit()) {

???

And who *does* report the recursion error?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 18:52

Message:
Logged In: YES 
user_id=33168

The recursion fields are shared in the new patch.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 16:35

Message:
Logged In: YES 
user_id=33168

That sounds more reasonable.
I'll take a look and see if they can be integrated.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-07 16:27

Message:
Logged In: YES 
user_id=6380

Fair enough.  Ideally this should share the recursion_limit
variable from ceval.c and the recursion_depth field of the
stack frame.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 16:23

Message:
Logged In: YES 
user_id=33168

I don't know.  I tried to come up with other test cases and
failed.
Tried __str__ and __getitem__.  Also tried new-style classes.

The problem was that the code bounced back and forth
between PyObject_Call() & instance_call() (mutual recursion).


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-07 16:08

Message:
Logged In: YES 
user_id=6380

Is this fix enough?  Aren't there lots of other ways to
generate the same error?  E.g. new-style classes (where this
particular example doesn't apply, but others might).

Or is this specific to instance_call?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 15:21

Message:
Logged In: YES 
user_id=33168

The attached patch stops the segfault and raises an exception:
TypeError: 'A' max recursion limit (100000) exceeded

I'm not sure if this is genarally applicable, or what a
reasonable # is.
100,000 was a guess and should probably be made a #def
w/comment.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-21 04:47

Message:
Logged In: NO 

>>> a=A() 
>>> a.foo 
foo 
__repr__ __call__ __call__ __call__ ... ad inf

This is normal behavior. The code at the top is buggy. The 
correct one is:

class A:
  def __getattr__(self, name):
    if name == '__repr__':
      return self.__repr__()
    print name
    return A()

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-20 17:10

Message:
Logged In: YES 
user_id=6380

This is buggy user code.

But the segfault should be fixed if possible.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470



From noreply@sourceforge.net  Thu Jun 13 23:08:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 15:08:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-561858 ] Assertion with very long lists
Message-ID: <E17IclB-0002oi-00@usw-sf-web3.sourceforge.net>

Bugs item #561858, was opened at 2002-05-29 06:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Jerome Alet (jalet)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Assertion with very long lists

Initial Comment:
I've tried to import a module which only define a list
of 170000 elements (a word list) which defines an
element per line, so the module also has 170000 lines
in it. Here's the error :

--- CUT ---
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import dictionnaire
python: ../Python/ceval.c:695: eval_code2: Assertion
`(stack_pointer - f->f_valuestack) <= f->f_stacksize'
failed.
Abandon
--- CUT ---

this seems to be the same problem as bug id 210647 but
there's no segfault.

the module is attached to this bug report.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-13 18:08

Message:
Logged In: YES 
user_id=33168

Guido, could you review this patch before checking in?
Thanks.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-04 13:20

Message:
Logged In: YES 
user_id=33168

Tim, could you also review long-list.diff.  This is the
patch against CVS version.
It changes what is marshalled to disk.  Thanks.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-01 14:28

Message:
Logged In: YES 
user_id=33168

Thanks Tim.
Checked in for 2.1/2.2 as 2.175.2.3 and 2.192.6.2. 

Could you or someone also review the other patch for current
CVS?
That patch has a test and is different ([rw]_short ->
[rw]_long).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-01 14:14

Message:
Logged In: YES 
user_id=31435

Assuming the patch you're talking about is the one named 
long-list-2.2.diff, looks good to me, so Accepted and 
assigned back to you.  Thanks!

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-01 10:56

Message:
Logged In: YES 
user_id=33168

Added a patch for 2.2 (2.1) is basically the same.
No test for 2.2/2.1 though.
Could someone please review before checkin?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 22:04

Message:
Logged In: YES 
user_id=33168

Final patch attached.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 20:17

Message:
Logged In: YES 
user_id=33168

Got a fix.  Patch attached.  
It will probably have to be changed,
since I don't remember what else needs to be
done when the MAGIC is changed.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 20:06

Message:
Logged In: YES 
user_id=33168

I found at least part of the problem, perhaps everything.
The co_stacksize > 32767 and only a short value is marshalled
to the .pyc.

See Python/marshal.c line 246.

Not sure how to fix yet.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 18:32

Message:
Logged In: YES 
user_id=33168

I think there are several problems here.
I was able to narrow down at least one problem to a long list.
It doesn't seem to have anything to do w/backslashes.

There seems to be an interaction with importing the module.
If the long list is in __main__, the problem does not occur.
The problem only occurs when the list is in an imported module
and only after importing it the second time (after the .pyc
is created).

If a list has 32768+ items there seems to be a memory problem.
There is an exception, then a crash.  Here's the exception:

TypeError: unsupported operand type(s) for &: 'str' and 'str'

Here's a stack trace against CVS version:

#0  chunk_free (ar_ptr=0x401b1620, p=0x8156a10) at malloc.c:3180
#1  0x400fdbf4 in __libc_free (mem=0x8156a18) at malloc.c:3154
#2  0x0805c0db in list_dealloc (op=0x401c4eac) at
Objects/listobject.c:214
#3  0x080c7618 in PyDict_SetItem (op=0x401bd79c,
key=0x401c4ec0, 
    value=0x80e185c) at Objects/dictobject.c:373
#4  0x080c93f9 in PyDict_SetItemString (v=0x401bd79c,
key=0x80d9070 "path", 
    item=0x80e185c) at Objects/dictobject.c:1895
#5  0x08099ad8 in PyImport_Cleanup () at Python/import.c:286
#6  0x080a266d in Py_Finalize () at Python/pythonrun.c:228
#7  0x08053766 in Py_Main (argc=2, argv=0xbffff904) at
Modules/main.c:379


----------------------------------------------------------------------

Comment By: Jerome Alet (jalet)
Date: 2002-05-29 08:42

Message:
Logged In: YES 
user_id=97214

I've done more tests, the bug only occurs if every line has
a backslash at its end :

liste = [ \
            "item0", \
            "item1", \
            # ... many many lines
            "itemN" ]

and it works if I remove the \ from each end of line.

hth.

----------------------------------------------------------------------

Comment By: Jerome Alet (jalet)
Date: 2002-05-29 06:14

Message:
Logged In: YES 
user_id=97214

module too long to be attached. ask it by email at
alet@librelogiciel.com if needed.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470



From noreply@sourceforge.net  Fri Jun 14 00:54:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 16:54:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-568134 ] asynchat module undocumented
Message-ID: <E17IeQc-0001Ck-00@usw-sf-web1.sourceforge.net>

Bugs item #568134, was opened at 2002-06-12 13:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568134&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason R. Mastaler (jasonrm)
>Assigned to: Anthony Baxter (anthonybaxter)
Summary: asynchat module undocumented

Initial Comment:
While asyncore is documented, asynchat 
is not.

Lack of documentation makes asynchat
more difficult to understand/use than it
should be.



----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-13 19:54

Message:
Logged In: YES 
user_id=3066

Ok, I'm fine with Anthony contributing the asynchat
documentation.

----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-06-13 13:52

Message:
Logged In: YES 
user_id=85984

I think it would be better for Anthony
to write the documentation.  I don't 
understand it very well myself (which is
why I was looking for docs in the first
place <wink>).



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-06-13 08:57

Message:
Logged In: YES 
user_id=29957

... if not, I can probably try to get something in a week or
two. I've got a current project that uses it. 

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-13 08:31

Message:
Logged In: YES 
user_id=3066

Agreed.  Can you contribute a section for this module?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568134&group_id=5470



From noreply@sourceforge.net  Fri Jun 14 01:14:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 17:14:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-561858 ] Assertion with very long lists
Message-ID: <E17IejE-0004Cd-00@usw-sf-web3.sourceforge.net>

Bugs item #561858, was opened at 2002-05-29 06:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Jerome Alet (jalet)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Assertion with very long lists

Initial Comment:
I've tried to import a module which only define a list
of 170000 elements (a word list) which defines an
element per line, so the module also has 170000 lines
in it. Here's the error :

--- CUT ---
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import dictionnaire
python: ../Python/ceval.c:695: eval_code2: Assertion
`(stack_pointer - f->f_valuestack) <= f->f_stacksize'
failed.
Abandon
--- CUT ---

this seems to be the same problem as bug id 210647 but
there's no segfault.

the module is attached to this bug report.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 20:14

Message:
Logged In: YES 
user_id=6380

This looks good to me. You might want to increase the size
of the list in the testcase so that it actually crashes for
non-debug Python without the fix; I could only get it to
fail an assertion in debug mode.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-13 18:08

Message:
Logged In: YES 
user_id=33168

Guido, could you review this patch before checking in?
Thanks.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-04 13:20

Message:
Logged In: YES 
user_id=33168

Tim, could you also review long-list.diff.  This is the
patch against CVS version.
It changes what is marshalled to disk.  Thanks.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-01 14:28

Message:
Logged In: YES 
user_id=33168

Thanks Tim.
Checked in for 2.1/2.2 as 2.175.2.3 and 2.192.6.2. 

Could you or someone also review the other patch for current
CVS?
That patch has a test and is different ([rw]_short ->
[rw]_long).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-01 14:14

Message:
Logged In: YES 
user_id=31435

Assuming the patch you're talking about is the one named 
long-list-2.2.diff, looks good to me, so Accepted and 
assigned back to you.  Thanks!

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-01 10:56

Message:
Logged In: YES 
user_id=33168

Added a patch for 2.2 (2.1) is basically the same.
No test for 2.2/2.1 though.
Could someone please review before checkin?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 22:04

Message:
Logged In: YES 
user_id=33168

Final patch attached.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 20:17

Message:
Logged In: YES 
user_id=33168

Got a fix.  Patch attached.  
It will probably have to be changed,
since I don't remember what else needs to be
done when the MAGIC is changed.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 20:06

Message:
Logged In: YES 
user_id=33168

I found at least part of the problem, perhaps everything.
The co_stacksize > 32767 and only a short value is marshalled
to the .pyc.

See Python/marshal.c line 246.

Not sure how to fix yet.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 18:32

Message:
Logged In: YES 
user_id=33168

I think there are several problems here.
I was able to narrow down at least one problem to a long list.
It doesn't seem to have anything to do w/backslashes.

There seems to be an interaction with importing the module.
If the long list is in __main__, the problem does not occur.
The problem only occurs when the list is in an imported module
and only after importing it the second time (after the .pyc
is created).

If a list has 32768+ items there seems to be a memory problem.
There is an exception, then a crash.  Here's the exception:

TypeError: unsupported operand type(s) for &: 'str' and 'str'

Here's a stack trace against CVS version:

#0  chunk_free (ar_ptr=0x401b1620, p=0x8156a10) at malloc.c:3180
#1  0x400fdbf4 in __libc_free (mem=0x8156a18) at malloc.c:3154
#2  0x0805c0db in list_dealloc (op=0x401c4eac) at
Objects/listobject.c:214
#3  0x080c7618 in PyDict_SetItem (op=0x401bd79c,
key=0x401c4ec0, 
    value=0x80e185c) at Objects/dictobject.c:373
#4  0x080c93f9 in PyDict_SetItemString (v=0x401bd79c,
key=0x80d9070 "path", 
    item=0x80e185c) at Objects/dictobject.c:1895
#5  0x08099ad8 in PyImport_Cleanup () at Python/import.c:286
#6  0x080a266d in Py_Finalize () at Python/pythonrun.c:228
#7  0x08053766 in Py_Main (argc=2, argv=0xbffff904) at
Modules/main.c:379


----------------------------------------------------------------------

Comment By: Jerome Alet (jalet)
Date: 2002-05-29 08:42

Message:
Logged In: YES 
user_id=97214

I've done more tests, the bug only occurs if every line has
a backslash at its end :

liste = [ \
            "item0", \
            "item1", \
            # ... many many lines
            "itemN" ]

and it works if I remove the \ from each end of line.

hth.

----------------------------------------------------------------------

Comment By: Jerome Alet (jalet)
Date: 2002-05-29 06:14

Message:
Logged In: YES 
user_id=97214

module too long to be attached. ask it by email at
alet@librelogiciel.com if needed.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470



From noreply@sourceforge.net  Fri Jun 14 01:33:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 17:33:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-562878 ] xmlrpclib.Binary.data undocumented
Message-ID: <E17If2N-0001j3-00@usw-sf-web1.sourceforge.net>

Bugs item #562878, was opened at 2002-05-31 07:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562878&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: xmlrpclib.Binary.data undocumented

Initial Comment:
There is no documentation on how to get at the data in 
a Binary objects. Likewise for DateTime.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-13 20:33

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/lib/libxmlrpclib.tex revision 1.9 and 1.5.10.3.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562878&group_id=5470



From noreply@sourceforge.net  Fri Jun 14 01:51:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 17:51:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-493951 ] string.{starts,ends}with vs slices
Message-ID: <E17IfJM-0001zb-00@usw-sf-web1.sourceforge.net>

Bugs item #493951, was opened at 2001-12-16 14:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493951&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Neal Norwitz (nnorwitz)
Summary: string.{starts,ends}with vs slices

Initial Comment:
The attached test shows many cases where 
string.startswith() and string.endswith() fail to 
handle negative slice indices correctly.  The failures 
are in both the start and end indices.  I stumbled 
into this when tracking down why (what turned out to 
be) this didn't work:

>>> file = 'difflib.pyc'
>>> file.endswith('.py', 0, -1) # should be 1
0
>>> file[0:-1].endswith('.py')  # like this is
1
>>>

Can we risk changing this for 2.2?  Don't know.  If 
not, reduce the priority.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-13 20:51

Message:
Logged In: YES 
user_id=33168

Checked in as:
  Doc/whatsnew/whatsnew23.tex 1.25
  Lib/test/string_tests.py 1.18
  Objects/stringobject.c 2.168
  Misc/NEWS 1.427


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-13 15:07

Message:
Logged In: YES 
user_id=33168

I'll update the tests & doc before checking in.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 12:23

Message:
Logged In: YES 
user_id=6380

Check in in, Neal. (Barry is too busy to watch SF.)

Would you mind adding unit tests?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-12 18:08

Message:
Logged In: YES 
user_id=33168

Attached is a patch which implements this behaviour.
Still need a patch for tests and the doc.
This passes all regressions and Tim's test.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 10:31

Message:
Logged In: YES 
user_id=6380

We should fix this in 2.3 at the very least. Leave 2.2.x
alone.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-04-22 10:11

Message:
Logged In: YES 
user_id=12800

The comment in the code reminds me that we adopted the
semantics for Java's String.startsWith() and String.endsWith(): 

http://java.sun.com/products/jdk/1.2/docs/api/java/lang/String.html#startsWith(java.lang.String,%20int)

which treats negative indices as errors (at least for the
start parameter -- which we generalized to include the end
parameter).  Changing this is a semantic change to the
string methods, so I don't think it should be undertaken
lightly (i.e. as a bug in the current implementation).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-16 15:03

Message:
Logged In: YES 
user_id=31435

I can't guess what the docs intended to say (they're vague -
- I can read them several ways).

In all other cases where optional string-method args 
named "start" and "end" are accepted (find(), rfind(), count
(), index(), rindex()), the docs are clear that they're 
interpreted as slice notation.  It doesn't make sense for 
the two newest methods to behave differently in this 
respect.

The unit tests aren't evidence one way or the other to me --
 the behavior of negative indices should be covered by the 
tests no matter what the intended semantics.

Overall, I expect the behavior here is an accident (as 
opposed to intended).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-16 14:45

Message:
Logged In: YES 
user_id=6380

Hm, the docs don't exactly suggest that negative indices
would be supported. While that would be nice, it's
definitely a feature request, so no, please don't do this in
2.2. (The absent of unit tests for negative indices also
suggests this was not an oversight. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-16 14:24

Message:
Logged In: YES 
user_id=31435

Attached the test case.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493951&group_id=5470



From noreply@sourceforge.net  Fri Jun 14 02:08:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 18:08:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-561858 ] Assertion with very long lists
Message-ID: <E17IfZh-0005HM-00@usw-sf-web3.sourceforge.net>

Bugs item #561858, was opened at 2002-05-29 06:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Jerome Alet (jalet)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Assertion with very long lists

Initial Comment:
I've tried to import a module which only define a list
of 170000 elements (a word list) which defines an
element per line, so the module also has 170000 lines
in it. Here's the error :

--- CUT ---
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import dictionnaire
python: ../Python/ceval.c:695: eval_code2: Assertion
`(stack_pointer - f->f_valuestack) <= f->f_stacksize'
failed.
Abandon
--- CUT ---

this seems to be the same problem as bug id 210647 but
there's no segfault.

the module is attached to this bug report.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-13 21:08

Message:
Logged In: YES 
user_id=33168

I increased the list size in the test to 65000 which crashed
on my box.

Checked in as:
  Python/import.c  2.206
  Python/marshal.c  1.72  Lib/test/test_import.py  1.12
 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-13 20:14

Message:
Logged In: YES 
user_id=6380

This looks good to me. You might want to increase the size
of the list in the testcase so that it actually crashes for
non-debug Python without the fix; I could only get it to
fail an assertion in debug mode.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-13 18:08

Message:
Logged In: YES 
user_id=33168

Guido, could you review this patch before checking in?
Thanks.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-04 13:20

Message:
Logged In: YES 
user_id=33168

Tim, could you also review long-list.diff.  This is the
patch against CVS version.
It changes what is marshalled to disk.  Thanks.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-01 14:28

Message:
Logged In: YES 
user_id=33168

Thanks Tim.
Checked in for 2.1/2.2 as 2.175.2.3 and 2.192.6.2. 

Could you or someone also review the other patch for current
CVS?
That patch has a test and is different ([rw]_short ->
[rw]_long).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-01 14:14

Message:
Logged In: YES 
user_id=31435

Assuming the patch you're talking about is the one named 
long-list-2.2.diff, looks good to me, so Accepted and 
assigned back to you.  Thanks!

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-01 10:56

Message:
Logged In: YES 
user_id=33168

Added a patch for 2.2 (2.1) is basically the same.
No test for 2.2/2.1 though.
Could someone please review before checkin?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 22:04

Message:
Logged In: YES 
user_id=33168

Final patch attached.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 20:17

Message:
Logged In: YES 
user_id=33168

Got a fix.  Patch attached.  
It will probably have to be changed,
since I don't remember what else needs to be
done when the MAGIC is changed.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 20:06

Message:
Logged In: YES 
user_id=33168

I found at least part of the problem, perhaps everything.
The co_stacksize > 32767 and only a short value is marshalled
to the .pyc.

See Python/marshal.c line 246.

Not sure how to fix yet.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 18:32

Message:
Logged In: YES 
user_id=33168

I think there are several problems here.
I was able to narrow down at least one problem to a long list.
It doesn't seem to have anything to do w/backslashes.

There seems to be an interaction with importing the module.
If the long list is in __main__, the problem does not occur.
The problem only occurs when the list is in an imported module
and only after importing it the second time (after the .pyc
is created).

If a list has 32768+ items there seems to be a memory problem.
There is an exception, then a crash.  Here's the exception:

TypeError: unsupported operand type(s) for &: 'str' and 'str'

Here's a stack trace against CVS version:

#0  chunk_free (ar_ptr=0x401b1620, p=0x8156a10) at malloc.c:3180
#1  0x400fdbf4 in __libc_free (mem=0x8156a18) at malloc.c:3154
#2  0x0805c0db in list_dealloc (op=0x401c4eac) at
Objects/listobject.c:214
#3  0x080c7618 in PyDict_SetItem (op=0x401bd79c,
key=0x401c4ec0, 
    value=0x80e185c) at Objects/dictobject.c:373
#4  0x080c93f9 in PyDict_SetItemString (v=0x401bd79c,
key=0x80d9070 "path", 
    item=0x80e185c) at Objects/dictobject.c:1895
#5  0x08099ad8 in PyImport_Cleanup () at Python/import.c:286
#6  0x080a266d in Py_Finalize () at Python/pythonrun.c:228
#7  0x08053766 in Py_Main (argc=2, argv=0xbffff904) at
Modules/main.c:379


----------------------------------------------------------------------

Comment By: Jerome Alet (jalet)
Date: 2002-05-29 08:42

Message:
Logged In: YES 
user_id=97214

I've done more tests, the bug only occurs if every line has
a backslash at its end :

liste = [ \
            "item0", \
            "item1", \
            # ... many many lines
            "itemN" ]

and it works if I remove the \ from each end of line.

hth.

----------------------------------------------------------------------

Comment By: Jerome Alet (jalet)
Date: 2002-05-29 06:14

Message:
Logged In: YES 
user_id=97214

module too long to be attached. ask it by email at
alet@librelogiciel.com if needed.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470



From noreply@sourceforge.net  Fri Jun 14 02:35:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 18:35:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-500073 ] HTMLParser fail to handle '&foobar'
Message-ID: <E17Ig0C-0001wu-00@usw-sf-web2.sourceforge.net>

Bugs item #500073, was opened at 2002-01-06 03:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Rejected
Priority: 7
Submitted By: Bernard YUE (berniey)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: HTMLParser fail to handle '&foobar'

Initial Comment:
HTMLParser did not distingish between &foobar; and 
&foobar.  The later is still considered as a 
charref/entityref.  Below is my posposed fix:

File:  sgmllib.py

# SGMLParser.goahead()
# line 162-176
# from
            elif rawdata[i] == '&':
                match = charref.match(rawdata, i)
                if match:
                    name = match.group(1)
                    self.handle_charref(name)
                    i = match.end(0)
                    if rawdata[i-1] != ';': i = i-1
                    continue
                match = entityref.match(rawdata, i)
                if match:
                    name = match.group(1)
                    self.handle_entityref(name)
                    i = match.end(0)
                    if rawdata[i-1] != ';': i = i-1
                    continue

# to
            elif rawdata[i] == '&'
                match = charref.match(rawdata, i)
                if match:
                    if rawdata[match.end(0)-1] != ';':
                        # not really an charref
                        self.handle_data(rawdata[i])
                        i = i+1
                    else:
                        name = match.group(1)
                        self.handle_charref(name)
                        i = match.end(0)
                    continue
                match = entityref.match(rawdata, i)
                if match:
                    if rawdata[match.end(0)-1] != ';':
                        # not really an entitiyref
                        self.handle_data(rawdata[i])
                        i = i+1
                    else: 
                        name = match.group(1)
                        self.handle_entityref(name)
                        i = match.end(0)
                    continue



----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-13 21:35

Message:
Logged In: YES 
user_id=3066

I agree that this should be rejected; this is not a
recurring complaint about the module, and there's no reason
to further exacerbate the HTML-as-deployed problem.  Let's
stick with the (relatively) strict interpretation.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-18 16:00

Message:
Logged In: YES 
user_id=6380

http://www.python.org/doc/NonEnglish.html#spanish

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-18 15:55

Message:
Logged In: NO 

no entiendo el proyecto pyton ni el funcionamiento del 
server no he encontrado ningun archivo pdf que te pueda 
explicar el desarrollo en español atte sebastia

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-13 01:02

Message:
Logged In: YES 
user_id=3066

Bump the priority so I'll have to look at this when I'm not
too tired to think straight.

----------------------------------------------------------------------

Comment By: Bernard YUE (berniey)
Date: 2002-01-09 01:35

Message:
Logged In: YES 
user_id=419276

Hi Guys,

I felt embarrass as I confuss everybody here.  Martin is nearly 
100% right.  Except that all &foo, &foo;, &#bar, &#bar; are all 
valid entity in HTML 4.01 as well if it was defined (I did not put 
enough test case in the old test.html to spot my mistake, when I 
ran it with the W3C Html validator, the new one should include 
all cases).  Hence the existing sgmllib.py was correct<Oops!>.

However, all the major browsers (IE, Natscape, Konqueror, Opera) 
choose to print the invalid HTML as plain text.  Hence I think 
htmllib.py might as well follow the crowd as well.

My suggestion is to added functions 
HTMLParser.unknown_charref() and and 
HTMLParser.unknown_entityref() as follows (files attached):

    # --- treat unknown entity as plain text

    def unknown_charref(self, ref):
        self.handle_data( '&#' + ref)

    def unknown_entityref(self, ref): 
        self.handle_data( '&'+ ref)

Sorry again for my previous incorrect patches.

Bernie


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-09 00:30

Message:
Logged In: YES 
user_id=21627

I still recommend to reject this patch, it is plain wrong.
Do we all agree that an HTML Document containing &you is
ill-formed (all HTML versions)? If so, it is a matter of
best-effort what to do with it.

In SGML, it is well-formed to omit the semicolon from the
entity name in a entity reference in certain cases, see

http://bip.cnrs-mrs.fr/bip10/scowl.htm#semi

Therefore, omission of the semicolon does *not* mean that
you don't have an entity reference, and sgmllib's processing
of entity references is completely correct - it would be an
error to treat &you as data. 

Therefore, your document is correct SGML. It just fails to
be correct HTML, since the entity 'you' is not defined.

If you want to process such a document in a specific way, I
recommend to subclass HTMLParser, overriding unknown_entityref.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-08 23:42

Message:
Logged In: YES 
user_id=6380

I'm reassigning this to Fred.

In 2.2, the new HTMLParser may or may not still have this
problem.

In 2.1.2, I think that "fixing" it would be too big a risk
of breaking existing code, so I think it should not be
fixed.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-01-08 23:33

Message:
Logged In: YES 
user_id=44345

Bernie,

I tried your patch.  It looks good to me.  I was a tad
confused 
when I first read your bug report.  I thought
you were suggesting that 
"&foo" be interpreted as a
charref/entityref.  Instead you are 
tightening up the
parser.

That seems reasonable to me.  Martin, what 
do you think?

Skip


----------------------------------------------------------------------

Comment By: Bernard YUE (berniey)
Date: 2002-01-08 20:04

Message:
Logged In: YES 
user_id=419276

Hi again,

I just run the test.html with w3c's HTML validator.  &you does 
indeed treated as an invalid entityref in HTML 4.01.  I've displays 
test.html under IE, Netscape and Konqueror and it all gave the 
result I've expected.  I am not sure if sgmllib.py should stick with 
the standard or go with the general defacto interpretation.

But I think it is more sensable to treat &you as text.


Bernie


----------------------------------------------------------------------

Comment By: Bernard YUE (berniey)
Date: 2002-01-08 19:43

Message:
Logged In: YES 
user_id=419276

Hi Martin and Skip,

Sorry for not explain myself clearly.  What I mean is that &foobar 
should have been treated as '&foobar' literally (i.e. text), and 
&forbat; should be an entityref and &#forbar; as charref.

Currently, sgmllib treated &foobar as entityref and &#foobar as 
charref and match it against entityref table and charref table.  
Ignores the entity when a match is not found.

My suggested change should fix this problem.  Run test.py 
(test.py and test.html attached)

>./test.py

Me! Me & You! Copyright@copy;abc Copyright©abc © ©

But we are expecting:
Me&you! Me & You! Copyright@copy;abc Copyright©abc © ©

My suggested change will print the expected output.

# test.html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
        "http://www.w3c.org/TR/html4/strict.dtd">

<html>
<head dir="ltr" lang="en">
  <TITLE>Testing Page</TITLE>
  <META name="AUTHOR" content="Bernard Yue">
  <META name="DESCRIPTION" content="Testing Page">
</head>
<body>
  <p>Me&you!  Me & You! Copyright@copy;abc 
Copyright&#169;abc &copy; &#169;
  </p>
</body>
</html>

# test.py
#!/usr/bin/env python

from htmllib import HTMLParser
from formatter import AbstractFormatter, DumbWriter


def test():
    _formatter = AbstractFormatter( DumbWriter())
    _parser = HTMLParser( _formatter)
    _f = open( './test.html')

    _parser.feed( _f.read())
    _f.close()
    _parser.close()
    print ''

if __name__ == '__main__':
    test()




----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-08 17:02

Message:
Logged In: YES 
user_id=21627

I fail to see the problem as well. Please attach an example
document to this report. Without a detailed analysis of the
problem in question, there is zero chance that any change
like this is accepted.

Here is my analysis from your report: It seems that you
complain that sgmllib, when it sees an ill-formed document,
behaves in a particular way, whereas you expect to behave it
in a different way. Since the document is ill-formed
anyways, any behaviour is as good as any other.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-01-08 16:03

Message:
Logged In: YES 
user_id=44345

Bernie,

I see nothing wrong in principal with recognizing 
"&nbsp"
when the user should have typed "&nbsp;", but I wonder
about 
the validity of "&nbsp".  You mentioned it's still
a charref or 
entityref.  Is that documented somewhere or
is it simply a practical 
approach to a common problem?

Thanks,

Skip


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470



From noreply@sourceforge.net  Fri Jun 14 02:39:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 18:39:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-505747 ] markupbase handling of HTML declarations
Message-ID: <E17Ig3f-00020l-00@usw-sf-web2.sourceforge.net>

Bugs item #505747, was opened at 2002-01-19 09:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505747&group_id=5470

Category: Python Library
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 6
Submitted By: Greg Chapman (glchapman)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: markupbase handling of HTML declarations

Initial Comment:
Using Python 2.2., I tried to use websucker.py on this 
page:

http://magix.fri.uni-lj.si/orange/start/

This resulted in an exception in ParserBase._scan_name 
because _declname_match failed.  Examining the source 
for the page above, I see there are several tags that 
look like: "<![endif]>" where the first character 
after "<!" is a '[', not an alpha as mandated by 
_delcname_match.  Perhaps this is badly formed HTML (I 
see it was produced by FrontPage), but if not, it 
appears that _scan_name may have to be modified.  FYI, 
here's the traceback from the exception:

Traceback (most recent call last):
  File "C:\Python22\Tools\webchecker\websucker.py", 
line 126, in ?
    sys.exit(main() or 0)
  File "C:\Python22\Tools\webchecker\websucker.py", 
line 43, in main
    c.run()
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 349, in run
    self.dopage(url)
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 403, in dopage
    page = self.getpage(url_pair)
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 507, in getpage
    return Page(text, url, maxpage=self.maxpage, 
checker=self)
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 671, in __init__
    self.parser.feed(self.text)
  File "c:\Python22\lib\sgmllib.py", line 95, in feed
    self.goahead(0)
  File "c:\Python22\lib\sgmllib.py", line 161, in 
goahead
    k = self.parse_declaration(i)
  File "c:\Python22\lib\markupbase.py", line 66, in 
parse_declaration
    decltype, j = self._scan_name(j, i)
  File "c:\Python22\lib\markupbase.py", line 313, in 
_scan_name
    self.error("expected name token")
  File "c:\Python22\lib\sgmllib.py", line 102, in error
    raise SGMLParseError(message)
sgmllib.SGMLParseError: expected name token



----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-13 21:39

Message:
Logged In: YES 
user_id=3066

Ok, here's what I think.

This is not an actual bug in the interpretation of HTML, and
there has not been a recurring pattern of complaints about
this.  Given that we do not want to encourage the creation
of broken HTML, this edge case will not be allowed to
further complicate the code.


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-02-15 01:13

Message:
Logged In: YES 
user_id=3066

Ugh!  I don't think that's legal HTML at all.  I'll have to
think about the right way to deal with it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505747&group_id=5470



From noreply@sourceforge.net  Fri Jun 14 02:59:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 13 Jun 2002 18:59:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-550777 ] fcntl module with wrong module for ioctl
Message-ID: <E17IgMy-0002G1-00@usw-sf-web2.sourceforge.net>

Bugs item #550777, was opened at 2002-04-30 16:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=550777&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Noah Spurrier (noah)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: fcntl module with wrong module for ioctl

Initial Comment:
The documentation for fcntl.ioctl() gives the wrong 
module for definitions of ioctl operations.

    http://www.python.org/doc/lib/module-fcntl.html

    ioctl(fd, op, arg) 
    This function is identical to the fcntl()
    function, except that the operations are typically
    defined in the library module IOCTL. 

As far as I can tell, there is no IOCTL module.
I think what the documentation should say is the
termios module. The termios module defines various 
ioctl operation constants.

The following example demonstrates an ioctl operation
to get the current terminal window size.
#!/usr/bin/env python

import termios, fcntl, struct, sys

s = struct.pack("HHHH", 0, 0, 0, 0)
fd_stdout = sys.stdout.fileno()
x = fcntl.ioctl(fd_stdout, termios.TIOCGWINSZ, s)
print '(rows, cols, x pixels, y pixels) =',
print struct.unpack("HHHH", x)

Yours,
Noah


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-13 21:59

Message:
Logged In: YES 
user_id=3066

These constants used to be defined in an IOCTL module, but
moved to the termios module.  This portion of the
documentation did not get updated appearantly.

Fixed in Doc/lib/libfcntl.tex revisions 1.29 and 1.28.6.1.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=550777&group_id=5470



From noreply@sourceforge.net  Fri Jun 14 15:09:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 14 Jun 2002 07:09:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-493243 ] ext call doco warts
Message-ID: <E17Irlf-0007qs-00@usw-sf-web4.sourceforge.net>

Bugs item #493243, was opened at 2001-12-14 10:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493243&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: ext call doco warts

Initial Comment:
Now they've been compiled <wink>, I notice that there
are some warts in my docs for the *- and **-style call
syntax.

1) the "argument_list" production is really, really
confusing.  there must be a better BNF-style way of
saying that.  I don't think vertically centering the
production name against the production helps.

2) For some reason, where I say

It is unusual for both keyword arguments and the
"*expression"syntax to be used in the same call, so in
practice this confusion does not arise.

there's no space between `"*expression"' and `syntax'.
 I'd guess that this is because in the source, the
\samp{} macro is the last thing on the line, but why
that should lead to a missing space is beyond me --
more latex2html bugs?

(just noticed the same thing a bit higher up too -- 

the "**expression"argument, if any 

No hurry with these.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-06-14 14:09

Message:
Logged In: YES 
user_id=6656

I'm going to check my fix in unless someone complains *real*
soon.

At least I know it compiles now, and I think it's an
improvement.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-12-20 14:25

Message:
Logged In: YES 
user_id=6656

Another problem with the pseudo-EBNF: it's wrong.  Oops.

It suggests that f(a, **b) isn't legal, for example.

I've attached an attempt I think it right, but I'm not sure 
and haven't compiled it (& so don't know if it looks any less 
confusing than last time).


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-12-14 17:01

Message:
Logged In: YES 
user_id=3066

Fixed table cell alignment in Doc/perl/python.perl revision
1.115.

Fixed item 2:  Worked around spaces problem in
Doc/ref/ref5.tex 1.53

This bug remains open; I still need to address the basic
problem in item 1 (confusing pseudo-EBNF).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493243&group_id=5470



From noreply@sourceforge.net  Fri Jun 14 15:24:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 14 Jun 2002 07:24:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-493243 ] ext call doco warts
Message-ID: <E17Is0P-0000Uy-00@usw-sf-web1.sourceforge.net>

Bugs item #493243, was opened at 2001-12-14 05:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493243&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: Michael Hudson (mwh)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: ext call doco warts

Initial Comment:
Now they've been compiled <wink>, I notice that there
are some warts in my docs for the *- and **-style call
syntax.

1) the "argument_list" production is really, really
confusing.  there must be a better BNF-style way of
saying that.  I don't think vertically centering the
production name against the production helps.

2) For some reason, where I say

It is unusual for both keyword arguments and the
"*expression"syntax to be used in the same call, so in
practice this confusion does not arise.

there's no space between `"*expression"' and `syntax'.
 I'd guess that this is because in the source, the
\samp{} macro is the last thing on the line, but why
that should lead to a missing space is beyond me --
more latex2html bugs?

(just noticed the same thing a bit higher up too -- 

the "**expression"argument, if any 

No hurry with these.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-14 10:24

Message:
Logged In: YES 
user_id=3066

Bumped priority; needs review.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-06-14 10:09

Message:
Logged In: YES 
user_id=6656

I'm going to check my fix in unless someone complains *real*
soon.

At least I know it compiles now, and I think it's an
improvement.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-12-20 09:25

Message:
Logged In: YES 
user_id=6656

Another problem with the pseudo-EBNF: it's wrong.  Oops.

It suggests that f(a, **b) isn't legal, for example.

I've attached an attempt I think it right, but I'm not sure 
and haven't compiled it (& so don't know if it looks any less 
confusing than last time).


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-12-14 12:01

Message:
Logged In: YES 
user_id=3066

Fixed table cell alignment in Doc/perl/python.perl revision
1.115.

Fixed item 2:  Worked around spaces problem in
Doc/ref/ref5.tex 1.53

This bug remains open; I still need to address the basic
problem in item 1 (confusing pseudo-EBNF).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493243&group_id=5470



From noreply@sourceforge.net  Sat Jun 15 01:54:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 14 Jun 2002 17:54:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-569257 ] __slots__ attribute and private variable
Message-ID: <E17J1px-0004RL-00@usw-sf-web1.sourceforge.net>

Bugs item #569257, was opened at 2002-06-14 20:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470

Category: Type/class unification
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Keyton Weissinger (keytonw)
Assigned to: Nobody/Anonymous (nobody)
Summary: __slots__ attribute and private variable

Initial Comment:
If you use a __slots__ class variable and include a 
variable with a double underscore as the first two 
characters, that variable is NOT private as would be the 
case for any other variable whose name begins with a 
double underscore.

If this is by design, then it should be in the docs. If it is 
not and represents a bug, it needs to be investigated.

Thank you!!!

Keyton Weissinger

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470



From noreply@sourceforge.net  Sat Jun 15 04:31:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 14 Jun 2002 20:31:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-569257 ] __slots__ attribute and private variable
Message-ID: <E17J4HL-0005du-00@usw-sf-web4.sourceforge.net>

Bugs item #569257, was opened at 2002-06-14 20:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470

Category: Type/class unification
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Keyton Weissinger (keytonw)
Assigned to: Nobody/Anonymous (nobody)
Summary: __slots__ attribute and private variable

Initial Comment:
If you use a __slots__ class variable and include a 
variable with a double underscore as the first two 
characters, that variable is NOT private as would be the 
case for any other variable whose name begins with a 
double underscore.

If this is by design, then it should be in the docs. If it is 
not and represents a bug, it needs to be investigated.

Thank you!!!

Keyton Weissinger

----------------------------------------------------------------------

>Comment By: Keyton Weissinger (keytonw)
Date: 2002-06-14 23:31

Message:
Logged In: YES 
user_id=396481

Also, this issue prevents you from using the combination of 
property() and __slots__ which would be powerful, as 
attempting to use them would make __property_name__ a 
legal public variable, no?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470



From noreply@sourceforge.net  Sat Jun 15 09:53:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 15 Jun 2002 01:53:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-569316 ] cgi.py broken with xmlrpclib on Python 2
Message-ID: <E17J9JZ-0002Un-00@usw-sf-web1.sourceforge.net>

Bugs item #569316, was opened at 2002-06-15 10:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569316&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Pike (oztourer)
Assigned to: Nobody/Anonymous (nobody)
Summary: cgi.py broken with xmlrpclib on Python 2

Initial Comment:
Given a web application which accepts both normal 
HTTP requests and XML-RPC requests, it is 
reasonable for that program to assume it can create a 
cgi.FieldStorage instance in either case. This works 
fine in Python 1.5.2 but causes exceptions in Python 
2.x.x when using the created FieldStorage. This is due 
to the content-type header generated by xmlrpclib.py 
('text/xml') being unrecognised in cgi.py, as a result of 
which no FieldStorage.list is created.

One solution is to reinstate some code in cgi.py from 
the 1.5.2 release, at the end of method __init__, after 
removing the current final two lines:

        #else:
        #    self.read_single()
        # SP 2002/6/15: The following code is taken 
from the Python 1.5.2 version
        # of cgi.py, as incoming xmlrpclib requests 
otherwise do not cause 'list'
        # to be set up correctly.
        elif self.outerboundary:
            # we're in an inner part, but the content-type 
wasn't something we
            # understood.  default to read_single() 
because the resulting
            # FieldStorage won't be a mapping (and 
doesn't need to be).
            self.read_single()
        else:
            # we're in an outer part, but the content-type 
wasn't something we
            # understood.  we still want the resulting 
FieldStorage to be a
            # mapping, so parse it as if it were urlencoded
            self.read_urlencoded()


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569316&group_id=5470



From noreply@sourceforge.net  Sat Jun 15 11:18:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 15 Jun 2002 03:18:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-568366 ] Module searchpath init: no tilde expansi
Message-ID: <E17JAdO-0004BM-00@usw-sf-web1.sourceforge.net>

Bugs item #568366, was opened at 2002-06-13 07:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568366&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Philip Ganchev (phil_ganchev)
Assigned to: Nobody/Anonymous (nobody)
Summary: Module searchpath init: no tilde expansi

Initial Comment:
Python initializes the module search path (sys.path) to
the contents of the system variable $PYTHONPATH (on
unix) at python startup.  But it does not expand '~' to
the user's home directory.  

It should, since tilde expansion is a convention which
many users and administrators rely on; not having it is
confusing.

Tilde expansion would also simplify use in other ways.
 For example, if the administrator puts '~/bin' on the
PYTHONPATH, this  would save many users from adding to
the path.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-15 12:18

Message:
Logged In: YES 
user_id=21627

This is not a bug. ~ expansion is not supported in PATH,
LD_LIBRARY_PATH, or CLASSPATH - I cannot see why it should
be supported in PYTHONPATH.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568366&group_id=5470



From noreply@sourceforge.net  Sat Jun 15 14:21:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 15 Jun 2002 06:21:46 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-567972 ] Missing 4 socket object properties
Message-ID: <E17JDUw-0006m8-00@usw-sf-web1.sourceforge.net>

Feature Requests item #567972, was opened at 2002-06-12 13:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=567972&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing 4 socket object properties

Initial Comment:
The C socketmodule has a struct PySocketSockObject, 
with family, type and proto members.

These would be terribly helpful to have access to in 
Python, when implementing some generic socket helper 
functions.

The "blocking" flag could also be made available, but 
would require some extra coding.

(I'm using Python 2.1.3 under Linux 2.4.16, so I cannot 
extend the socket class itself ((as in py2.2)), and don't 
want to slow down sockets with a complete wrapper, as I 
use them heavily.)

Thanks, Graham.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-15 15:21

Message:
Logged In: YES 
user_id=21627

Sounds good. Would you like to produce a patch implementing
this feature?

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-06-12 14:00

Message:
Logged In: YES 
user_id=543663

Oh yes, the repr of a socket object includes the missing info, 
so to get hold of the family, I go:
  int(repr(sock).split(' ')[3].split('=')[1][:-1])

Similar for type and protocol, not nice!


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=567972&group_id=5470



From noreply@sourceforge.net  Sat Jun 15 14:23:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 15 Jun 2002 06:23:32 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-567969 ] Missing socketpair() function.
Message-ID: <E17JDWe-0006ti-00@usw-sf-web2.sourceforge.net>

Feature Requests item #567969, was opened at 2002-06-12 13:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=567969&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing socketpair() function.

Initial Comment:
Coming from a C++ background, I have noticed the 
absence of a socketpair() function in the socket module.

I have implemented a couple of workarounds (see 
attached sockpair2.py), which I use a lot.

But there are security and portability problems lurking.

How about a nice shiny new socketpair() call in 
socketmodule?

Thanks, Graham.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-15 15:23

Message:
Logged In: YES 
user_id=21627

Good idea. Would you like to work on a patch? Notice that
this would involve autoconf machinery, since I doubt that
socketpair is universally available.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=567969&group_id=5470



From noreply@sourceforge.net  Sun Jun 16 16:12:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 16 Jun 2002 08:12:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-569668 ] LINKCC incorrectly set
Message-ID: <E17Jbhg-0005ny-00@usw-sf-web4.sourceforge.net>

Bugs item #569668, was opened at 2002-06-16 16:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569668&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Dr Leonid A Timochouk (cardou)
Assigned to: Nobody/Anonymous (nobody)
Summary: LINKCC incorrectly set

Initial Comment:
I was building Python 2.2.1 on Debian/GNU Linux 3.0
(testing pre-release) with gcc and g++ of version 3.0.4,
using  --with-cxx=g++ configure option. Then linking of the
"python" executable fails due to an unresolved symbol
(__gxx_personality_v0) in Modules/ccpython.o, because
linking is still done with gcc: LINKCC is set to gcc ($CC)
by configure, rather than to g++ ($CXX).

The configure script attempts to determine the value of
LINKCC and sets it to $CC if the latter can
successfully link
the simplest program "int main(){return 0;}" which was
compiled with $CXX. In this case, linking apparently
succeeds, setting LINKCC to $CC. Yet linking of
Modules/ccpython.o with $CC fails,  probably because
Modules/ccpython.c is slightly more complex than the
above configuration test, hence an extra unresolved
symbol generated by g++.

I am not sure how the correct value of LINKCC can be
determined at config time without unnecessarily using
$CXX all the time when it is available. Maybe the
makefile should be modified so it always starts from
$CC and falls through to $CXX if the former fails?

Sincerely,
Dr. Leonid Timochouk
Computing Laboratory
University of Kent at Canterbury
England


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569668&group_id=5470



From noreply@sourceforge.net  Mon Jun 17 14:56:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 17 Jun 2002 06:56:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-570044 ] "python -u" not binary on cygwin
Message-ID: <E17Jx00-0001lP-00@usw-sf-web3.sourceforge.net>

Bugs item #570044, was opened at 2002-06-17 15:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=570044&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sjoerd Mullender (sjoerd)
Assigned to: Nobody/Anonymous (nobody)
Summary: "python -u" not binary on cygwin

Initial Comment:
python -u is supposed to put sys.stdin and sys.stdout
in binary mode on systems where such things matter.
This does not happen on Window under Cygwin.

Try
python -u -c 'import sys;
open("x","wb").write(sys.stdin.read())' < some-text-file

and notice that the newly created file "x" has just \n
line endings instead of \r\n.

A patch is included.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=570044&group_id=5470



From noreply@sourceforge.net  Mon Jun 17 13:45:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 17 Jun 2002 05:45:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-570003 ] odd index entries
Message-ID: <E17Jvt1-0002M5-00@usw-sf-web4.sourceforge.net>

Bugs item #570003, was opened at 2002-06-17 12:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=570003&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: odd index entries

Initial Comment:
This is thoroughly wierd, and probably a latex2html bug, but I 
thought I'd submit it just in case.

Some on the entries in most of the generated indices for the 
documentation don't come out right.  For example, go to

http://www.python.org/dev/doc/devel/ref/genindex.html

and search for "1[".

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=570003&group_id=5470



From noreply@sourceforge.net  Mon Jun 17 15:27:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 17 Jun 2002 07:27:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-570057 ] Broken pre.subn() (and pre.sub())
Message-ID: <E17JxTh-0004O4-00@usw-sf-web4.sourceforge.net>

Bugs item #570057, was opened at 2002-06-17 16:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=570057&group_id=5470

Category: Regular Expressions
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Johan Tufvesson (tuben)
Assigned to: Fredrik Lundh (effbot)
Summary: Broken pre.subn() (and pre.sub())

Initial Comment:
The functions pre.subn() and pre.sub() are broken in
Python2.2 and 2.2.1. The following test was done on
SunOS 5.6:

Python 2.2.1 (#1, Jun 13 2002, 12:57:34) 
[GCC 2.95.2 19991024 (release)] on sunos5
Type "help", "copyright", "credits" or "license" for
more information.
>>> import re
>>> re.sub('(a)', '\g<1>', 'bab')
'bab'
>>> import pre as re
>>> re.sub('(a)', '\g<1>', 'bab')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/tools/lib/python2.2/pre.py", line
179, in sub
    return pattern.sub(repl, string, count)
  File "/usr/local/tools/lib/python2.2/pre.py", line
344, in sub
    return self.subn(repl, string, count)[0]
  File "/usr/local/tools/lib/python2.2/pre.py", line
366, in subn
    repl = pcre_expand(_Dummy, repl)
TypeError: 'NoneType' object is not callable

The error has also been reproduced on SunOS5.7 with the
following interpreter:
Python 2.2 (#1, Dec 28 2001, 22:25:04) 
[GCC 2.95.2 19991024 (release)] on sunos5

The error could not be reproduced on SunOS5.6 using
Python2.1.1:
Python 2.1.1 (#5, Sep 10 2001, 13:44:17) 
[GCC 2.95.2 19991024 (release)] on sunos5

NOTE: The example for re.sub() in the Python Library
manual triggers this bug when used with module pre!


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=570057&group_id=5470



From noreply@sourceforge.net  Mon Jun 17 15:56:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 17 Jun 2002 07:56:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-457114 ] Incorporate timeoutsocket.py into core
Message-ID: <E17JxwA-0004x7-00@usw-sf-web4.sourceforge.net>

Bugs item #457114, was opened at 2001-08-31 01:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457114&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Incorporate timeoutsocket.py into core

Initial Comment:
I was responding to a question on c.l.py earlier about
urllib hanging and was reminded of Tim O'Malley's
timeoutsocket.py.  It's a shim above socket that allows
you to set timeouts on any TCP connections.  Back in
January, Jeff Bauer suggested in c.l.py that it be
included in the core.  I agree that it provides useful
extra functionality beyond the current socket
implementation and would like it to be considered for
addition to the standard distribution.  Here's a
pointer:

    http://www.timo-tasi.org/python/timeoutsocket.py

Here's how you use it:

    import timeoutsocket
    import httplib
    timeoutsocket.setDefaultSocketTimeout(20)
    # at this point any sockets created
    # will have a 20-second timeout
    h = httplib.HTTP("www.python.org")

Pretty simple, huh?

Skip


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-17 10:56

Message:
Logged In: YES 
user_id=3066

I think this is done and can be closed now, but Guido's been
working on this and knows the current status.

----------------------------------------------------------------------

Comment By: Michael Gilfix (mgilfix)
Date: 2002-05-12 08:12

Message:
Logged In: YES 
user_id=116038

A patch for this now exists in the SF tracker: #555085.

----------------------------------------------------------------------

Comment By: Michael Gilfix (mgilfix)
Date: 2002-04-22 23:56

Message:
Logged In: YES 
user_id=116038

For the record, I have a patch. I'm coordinating with
Bernard Yue for some preliminary testing and it'll added
into the patch tracker shortly.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-04-17 11:32

Message:
Logged In: YES 
user_id=44345

Check the python-dev mailing list archive for the past few
days.  There is an active thread about this topic.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-17 08:14

Message:
Logged In: YES 
user_id=6380

Bernard Yue is considering to tackle this. See the thread in
python-dev starting at
http://mail.python.org/pipermail/python-dev/2002-April/023278.html
Maybe you two can work on this together?


----------------------------------------------------------------------

Comment By: Michael Gilfix (mgilfix)
Date: 2002-04-17 01:22

Message:
Logged In: YES 
user_id=116038

I'd be interested in integrating the two modules if no one
has tackled this yet. Seems like it would make a cool
feature.

I'm a little unclear on where you think the best integration
(and I'm a little new to the interpreter source :) ) point
would be - in the python module interface socket.py or the
lower level c interface socketmodule.c.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-09-05 16:46

Message:
Logged In: YES 
user_id=44345

While the offer is tempting, I almost certainly don't
understand the various bits associated with sockets and
don't have the time to learn them, so I'm unassigning.
Hopefully someone else will pick it up for 2.3...

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-05 14:26

Message:
Logged In: YES 
user_id=6380

Skip, want to work on this? If not, please unassign it.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-31 09:10

Message:
Logged In: YES 
user_id=6380

I like this idea, but don't think this exact implementation
belongs in the standard library. The hacks deployed to
"install" the special effect are a bit fragile, e.g.
consider "import socket as foo"; and they shouldn't be
necessary.

When integrated into the standard library, it should
probably become a standard feature of the socket object.
Note that on Windows, socket.socket is already a shim on top
of _socket.socket, so that would be a convenient starting
point.

Patch anyone?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457114&group_id=5470



From noreply@sourceforge.net  Mon Jun 17 15:59:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 17 Jun 2002 07:59:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-457114 ] Incorporate timeoutsocket.py into core
Message-ID: <E17JxyY-000311-00@usw-sf-web3.sourceforge.net>

Bugs item #457114, was opened at 2001-08-31 01:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457114&group_id=5470

Category: Python Library
Group: Feature Request
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Incorporate timeoutsocket.py into core

Initial Comment:
I was responding to a question on c.l.py earlier about
urllib hanging and was reminded of Tim O'Malley's
timeoutsocket.py.  It's a shim above socket that allows
you to set timeouts on any TCP connections.  Back in
January, Jeff Bauer suggested in c.l.py that it be
included in the core.  I agree that it provides useful
extra functionality beyond the current socket
implementation and would like it to be considered for
addition to the standard distribution.  Here's a
pointer:

    http://www.timo-tasi.org/python/timeoutsocket.py

Here's how you use it:

    import timeoutsocket
    import httplib
    timeoutsocket.setDefaultSocketTimeout(20)
    # at this point any sockets created
    # will have a 20-second timeout
    h = httplib.HTTP("www.python.org")

Pretty simple, huh?

Skip


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-17 10:59

Message:
Logged In: YES 
user_id=6380

Closing. Further discussion at the corresponding patch.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-17 10:56

Message:
Logged In: YES 
user_id=3066

I think this is done and can be closed now, but Guido's been
working on this and knows the current status.

----------------------------------------------------------------------

Comment By: Michael Gilfix (mgilfix)
Date: 2002-05-12 08:12

Message:
Logged In: YES 
user_id=116038

A patch for this now exists in the SF tracker: #555085.

----------------------------------------------------------------------

Comment By: Michael Gilfix (mgilfix)
Date: 2002-04-22 23:56

Message:
Logged In: YES 
user_id=116038

For the record, I have a patch. I'm coordinating with
Bernard Yue for some preliminary testing and it'll added
into the patch tracker shortly.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-04-17 11:32

Message:
Logged In: YES 
user_id=44345

Check the python-dev mailing list archive for the past few
days.  There is an active thread about this topic.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-17 08:14

Message:
Logged In: YES 
user_id=6380

Bernard Yue is considering to tackle this. See the thread in
python-dev starting at
http://mail.python.org/pipermail/python-dev/2002-April/023278.html
Maybe you two can work on this together?


----------------------------------------------------------------------

Comment By: Michael Gilfix (mgilfix)
Date: 2002-04-17 01:22

Message:
Logged In: YES 
user_id=116038

I'd be interested in integrating the two modules if no one
has tackled this yet. Seems like it would make a cool
feature.

I'm a little unclear on where you think the best integration
(and I'm a little new to the interpreter source :) ) point
would be - in the python module interface socket.py or the
lower level c interface socketmodule.c.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-09-05 16:46

Message:
Logged In: YES 
user_id=44345

While the offer is tempting, I almost certainly don't
understand the various bits associated with sockets and
don't have the time to learn them, so I'm unassigning.
Hopefully someone else will pick it up for 2.3...

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-05 14:26

Message:
Logged In: YES 
user_id=6380

Skip, want to work on this? If not, please unassign it.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-31 09:10

Message:
Logged In: YES 
user_id=6380

I like this idea, but don't think this exact implementation
belongs in the standard library. The hacks deployed to
"install" the special effect are a bit fragile, e.g.
consider "import socket as foo"; and they shouldn't be
necessary.

When integrated into the standard library, it should
probably become a standard feature of the socket object.
Note that on Windows, socket.socket is already a shim on top
of _socket.socket, so that would be a convenient starting
point.

Patch anyone?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457114&group_id=5470



From noreply@sourceforge.net  Mon Jun 17 16:02:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 17 Jun 2002 08:02:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-558279 ] \verbatiminput and name duplication
Message-ID: <E17Jy1C-00034o-00@usw-sf-web3.sourceforge.net>

Bugs item #558279, was opened at 2002-05-20 09:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558279&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: \verbatiminput and name duplication

Initial Comment:
The \verbatiminput support which generates file names
for the "Download as text" feature does not check that
the source file names are unique without the extension.
 If a document uses \verbatiminput with two files,
sample.py and sample.html, both get written to the
output as sample.txt; last one processed wins.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-17 11:02

Message:
Logged In: YES 
user_id=3066

Checked in the second patch as Doc/perl/python.perl revision
1.126 since there have been no complaints.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-20 11:53

Message:
Logged In: YES 
user_id=3066

I've added an improved patch that only creates one output
file for each input file, no matter how many times it's
input.  The "Download as text" message in the footer is also
modified to include the original filename if the actual
filename has been modified from the original (which it
always has been unless the original extension was .txt).

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-20 11:15

Message:
Logged In: YES 
user_id=3066

I'm attaching a patch that will at least make sure things
work when presented with source filenames that share the
same base name, or are the same file included more than once.

The patch is not ideal:  repeated inclusions are not
detected, so the content will be duplicated for each
inclusion (minor).  The filename generation does not ensure
that a source file's basename will ever be used for a file
with that basename.  For example, including sample.py,
sample.c, and sample-c.c, in that order, will generate the
file names sample.txt, sample-c.txt, and sample-c-c.txt.

Note that filename re-writing is needed to ensure that Web
servers produce the text/plain Content-Type for these files;
there is no reliable way to configure Web servers to produce
 the appropriate headers from the content space.  (We also
need to avoid allowing the output text files to have
extensions of .html since LaTeX2HTML or node2label.pl might
overwrite them.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558279&group_id=5470



From noreply@sourceforge.net  Mon Jun 17 16:10:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 17 Jun 2002 08:10:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-472568 ] PyBuffer_New() memory not aligned
Message-ID: <E17Jy94-0008Np-00@usw-sf-web2.sourceforge.net>

Bugs item #472568, was opened at 2001-10-18 17:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472568&group_id=5470

>Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Tim Peters (tim_one)
Summary: PyBuffer_New() memory not aligned

Initial Comment:
Memory buffer areas created by PyBuffer_New are
missaligned on 32 bit machines, for doubles (64 bit).

This typically generates a bus error crash on most RISC
machines when a library function tries to write a
double in a memory buffer allocated by PyBuffer_New().

When looking at the bufferobject.c code, this seems to
come from the fact that  the memory buffer points at
'malloc() + sizeof  struct PyBufferObject'; 	[line:
b->b_ptr = (void *)(b + 1); ]

To the extent that struct PyBufferObject is not a
multiple of sizeof (double), the largest value type;
thus the misalignment, and the crashes on most RISC
processors.

A quick and temporary solution would consist in adding
a dummy double field as the last field of the
PyBufferObject structure:

struct PyBufferObject {
...
double dummy; 
} ;

and setting
b->b_ptr = (void*)&b->dummy;  /*was (void*(b+1)*/

In doing so, b->b_ptr will always by aligned on sizeof
(double), on either 32 and 64 bit architectures.


Since I'm on the buffer type problem: It would be nice
(and probably easy to do) to augment the buffer
protocol interface with the ability to specify the
basic value type stored in the buffer.

A possible list of values (enum ...) would be:

- undefined (backward compatibility)
- char, unsigned char, short, ....int, ... long, long
long, float, double, and void* (memory address).

This would enable to check at runtime the type of
values stored in a buffer (and prevent missalignement
buserrors, as well as catching garbage situations when
improper array types are passed by means of the buffer
interface [e.g.: int/float/double/short...).

Frederic Giacometti


Frederic Giacometti






----------------------------------------------------------------------

Comment By: Frederic Giacometti (giacometti)
Date: 2001-11-01 12:21

Message:
Logged In: YES 
user_id=93657

The solution Tim proposes (2d malloc) will be very fine with
what we do.

Here are some more details on what we're doing (and this is
a standard operation):

- We want to create an array of double that we pass to a C
function, and then return this array to Python as buffer
object (the buffer is passed latter on as arg to other
functions using the buffer interface); and do it so that
Python takes ownership of the buffer memory management.

- We don't want to require Numerical to operate the package;
just for memory allocation.

- We should actually be using the Python array module
interface.
Unfortunately:
  * the Python array object C definitions are not exported
in a .h file
  * the Array python interface does not provide the ability
to create a new array of an arbitrary size (and certainly
initialized to 0). One has to provide a list or a string to
create an array of a given size.  IThis is not workable if
we work we large arrays (e.g.: an array of 1.000.000 doubles
is only 8 MB RAM ...).

Another  solution, then, would consist in extending the
array Python interface, so as to enable the creation of
arrays of arbitrary sizes (prefereably initialized to 0 or
to something alse with a calloc or a memset).

The extension of the array.array() function could be the
better solution, taking into account our needs as well as
Tim's concerns.

FG

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-31 20:31

Message:
Logged In: YES 
user_id=31435

The only portable way to fix this (assuming it's broken -- 
I don't see any alignment promises in the docs, and since 
we never use it we can't mine the source code for clues 
either) is to have PyBuffer_New do a second separate malloc
(size) and set b_ptr to that.  The C std guarantees memory 
returned by malloc is suitably aligned for all purposes; it 
doesn't promise that any standard type captures the 
strictest alignment requirement (indeed, at KSR we returned 
128-byte aligned memory from malloc, to cater to 
our "subpage" type extension).

----------------------------------------------------------------------

Comment By: Frederic Giacometti (giacometti)
Date: 2001-10-31 19:31

Message:
Logged In: YES 
user_id=93657

A portable solution (im[provement over what I proposed)
would consitst in declaring 'dummy' with a union type,
'unionizing' all C-ANSI value types (and including 'long
long' optionally by mean of an #ifdef).

 { .... union { int Int; long Long; double Double; void*
Pvoid ...} dummy; }

All (void*)obj->dummy can be replaced with obj->dummy.Pvoid

FG


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-10-22 16:19

Message:
Logged In: YES 
user_id=31392

Note to whomever take this bug: PyBuffer_New() is not called
anywhere in the Python source tree; nor are there any tests
for buffer objects that I'm aware of.  A few simple test
cases would have caught this bug already.  (And for the case
of the builtin buffer() call, it might be good if it used
PyBuffer_New().)


----------------------------------------------------------------------

Comment By: Frederic Giacometti (giacometti)
Date: 2001-10-18 17:35

Message:
Logged In: YES 
user_id=93657

I wasn't looged in when I submitted the item. Don't think
I'm becoming anonymous :))


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472568&group_id=5470



From noreply@sourceforge.net  Mon Jun 17 16:12:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 17 Jun 2002 08:12:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-495624 ] Error building info docs
Message-ID: <E17JyB0-0003Ha-00@usw-sf-web3.sourceforge.net>

Bugs item #495624, was opened at 2001-12-20 16:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495624&group_id=5470

>Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Error building info docs

Initial Comment:
make info fails ...

Element.pm is from the (Debian) package libhtml-tree-
perl, version 3.11. Any hints, what's wrong?

$ make info
cd info && make
make[1]: Entering directory `/export/swt-
dev/users/doko/packages/python2.2/python2.2-
2.1.99c1/Doc/info'
../tools/mkinfo ../html/api/api.html
perl -
I/home/swt/doko/export/packages/python2.2/python2.2-
2.1.99c1/Doc/tools /home/swt/doko/export/packages/pytho
n2.2/python2.2-
2.1.99c1/Doc/tools/html2texi.pl /home/swt/doko/export/p
ackages/python2.2/python2.2-
2.1.99c1/Doc/html/api/api.html
/usr/share/perl5/HTML/Element.pm:2091: function 
main::output_body expected 3 arguments, got 5: Guido 
van Rossum  1 4 HTML::Element=HASH(0x82c479c) 0
make[1]: *** [python-api.info] Error 255
make[1]: Leaving directory `/export/swt-
dev/users/doko/packages/python2.2/python2.2-
2.1.99c1/Doc/info'
make: *** [info] Error 2


----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-01-07 20:01

Message:
Logged In: YES 
user_id=60903

Found updated versions of the conversion scripts

http://pag.lcs.mit.edu/~mernst/software/#html2texi
http://pag.lcs.mit.edu/~mernst/software/#checkargs

with http://pag.lcs.mit.edu/~mernst/software/python-info-
Makefile from the same site I get a step further ...

fixinfo.el is out of date ...

who is pdm/pdm, who builds the info tarballs for download?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495624&group_id=5470



From noreply@sourceforge.net  Mon Jun 17 16:19:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 17 Jun 2002 08:19:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-511737 ] Bug/limitation in ConfigParser
Message-ID: <E17JyHw-0003P6-00@usw-sf-web3.sourceforge.net>

Bugs item #511737, was opened at 2002-02-01 10:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=511737&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Loïc Lefort (loicl)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Bug/limitation in ConfigParser

Initial Comment:
It is not possible to use '%' character in config
options in combination with $() substitution.
Example: Given this configuration file:

[DEFAULT]
option1=xxx
option2=%(option1)s/xxx

ok=%(option1)s/%%s
not_ok=%(option2)s/%%s

config.get('DEFAULT', 'ok') returns xxx/%s
but config.get('DEFAULT', 'not_ok') fails with an
exception because the '%' needs to be escaped multiple
times depending on the evaluation depth:

%(option2)s/%%s -> %(option1)s/xxx/%s -> exception

what I would like it to do is:
%(option2)s/%%s -> %(option1)s/xxx/%%s -> xxx/xxx/%s

Attached to this bug report is a simple patch to work
around this limitation (not very elegant, but it works)



----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-17 11:19

Message:
Logged In: YES 
user_id=3066

I'm afraid getting this "right" is going to be much more
tedious that the proposed patch.  It's unclear to me at the
moment whether this should be a documented limitation or if
we should really fix it.  The ConfigParser module is
generally in bad shape, unfortunately.  ;-(

----------------------------------------------------------------------

Comment By: Loïc Lefort (loicl)
Date: 2002-02-01 10:38

Message:
Logged In: YES 
user_id=78862

Forgot the python version: this problem is present in both
python 2.1.2 and python 2.2

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=511737&group_id=5470



From noreply@sourceforge.net  Mon Jun 17 16:25:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 17 Jun 2002 08:25:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-526390 ] Incomplete list of escape sequences
Message-ID: <E17JyNn-0000Pj-00@usw-sf-web2.sourceforge.net>

Bugs item #526390, was opened at 2002-03-06 08:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526390&group_id=5470

Category: XML
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Mark Carter (comcol)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incomplete list of escape sequences

Initial Comment:
There exist some special character tags (i.e. 
beginning with &) that cause exceptions in minidom - 
and probably in other modeules, too. Example below:

=== PYTHON CODE ===
import xml.dom.minidom 

def do(text):
	print "Processing: ", text
	dom = xml.dom.minidom.parseString(text)
	print "... ok"

do("<body> this is ok </body>") #ok
do("<body> &lt; &gt; &amp; &quot; </body>") #ok
do("<body> &pound;  </body>") # error


=== STDOUT ===
Processing:  <body> this is ok </body>
... ok
Processing:  <body> &lt; &gt; &amp; &quot; </body>
... ok
Processing:  <body> &pound;  </body>

=== STDERR ===
Traceback (most recent call last):
  File "err.py", line 10, in ?
    do("<body> &pound;  </body>") # exception
  File "err.py", line 5, in do
    dom = xml.dom.minidom.parseString(text)
  File "C:\PYTHON22\lib\xml\dom\minidom.py", line 965, 
in parseString
    return _doparse(pulldom.parseString, args, kwargs)
  File "C:\PYTHON22\lib\xml\dom\minidom.py", line 952, 
in _doparse
    toktype, rootNode = events.getEvent()
  File "C:\PYTHON22\lib\xml\dom\pulldom.py", line 255, 
in getEvent
    self.parser.feed(buf)
  File "C:\PYTHON22\lib\xml\sax\expatreader.py", line 
111, in feed
    self._err_handler.fatalError(exc)
  File "C:\PYTHON22\lib\xml\sax\handler.py", line 38, 
in fatalError
    raise exception
xml.sax._exceptions.SAXParseException: <unknown>:1:7: 
undefined entity

=== COMMENTS ===
It is also my observation that special character tags 
(aka HTML escape 
sequences) translations are scattered "hither and 
thither" throughout 
modules
in the XML subdirectory, and that it would be better 
if they were all
put in one place.

I might be persuaded to help with the maintenance work 
that this 
would require!

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-17 11:25

Message:
Logged In: YES 
user_id=3066

"&pound;" is not defined in the XML spec., as Martin points out.

The comment about "special character tags" at the end of the
initial report is not clear; if you still feel that there is
a problem there, please open a new bug report and be
specific.  Examples would be helpful.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-06 16:58

Message:
Logged In: YES 
user_id=21627

I cannot understand the problem. The parser rightfully
complains about &pound; - this is not one of the predefined
entities of XML. Please refer to the XML spec; only amp, lt,
and gt are predefined in XML. Everything else should and
does produce an error.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526390&group_id=5470



From noreply@sourceforge.net  Mon Jun 17 16:30:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 17 Jun 2002 08:30:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-528748 ] range() description: rewording suggested
Message-ID: <E17JySe-0006ir-00@usw-sf-web1.sourceforge.net>

Bugs item #528748, was opened at 2002-03-11 19:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528748&group_id=5470

>Category: Documentation
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Colin J. Williams (cjwhrh)
Assigned to: Nobody/Anonymous (nobody)
Summary: range() description: rewording suggested

Initial Comment:
The help now has: 
     range([start,] stop[, step]) 
     This is a versatile function to create lists containing arithmetic
     progressions. It is most often used in for loops. The arguments
     must be plain integers. If the step argument is omitted, it
     defaults to 1. If the start argument is omitted, it defaults to
     0. The full form returns a list of plain integers [start, start +
     step, start + 2 * step, ...].  If step is positive, the last
     element is the largest start + i * step less than stop; if step is
     negative, the last element is the largest start + i * step greater
     than stop. step must not be zero (or else ValueError is raised). 

It might say:   

     range([start= 0,] stop[, step= 1]) 
     This function creates a list containing an arithmetic progression.
     The arguments must be integers.   If only one argument is passed it 
     is the 'stop' value, if two values are passed then the first is the
     'start' value and the second the 'stop' value.
     The function returns a list of integers [start, start + step, start
     + 2 * step, ...]. The 'step' must not be zero; if 'step' is positive, 
     the last element is the largest; if  'step' is negative, the last
     element is the smallest.
-----------------------------------------------------------
Using Python 2.2

The main intent is to clarify the usage of the optional arguments.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-17 11:30

Message:
Logged In: YES 
user_id=3066

I agree with Raymond.  Closing the bug as rejected.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-04-12 16:52

Message:
Logged In: YES 
user_id=80475

IMO, the current version is clearer than the re-write.  
Also, the docs add further clarity by showing 7 examples.  
The proposed documentation style, range([start=0,] stop
[,step=1 ]) is inconsistent with the style used in the rest 
of the docs.

A side note, the docstring for range() is shorter and 
clearer than both of the above:

range(...)
    range([start,] stop[, step]) -> list of integers
    
    Return a list containing an arithmetic progression of 
integers.  range(i, j) returns [i, i+1, i+2, ..., j-1]; 
start (!) defaults to 0.  When step is given, it specifies 
the increment (or decrement).  For example, range(4) 
returns [0, 1, 2, 3].  The end point is omitted!  These are 
exactly the valid indices for a list of 4 elements.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528748&group_id=5470



From noreply@sourceforge.net  Mon Jun 17 16:30:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 17 Jun 2002 08:30:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-472568 ] PyBuffer_New() memory not aligned
Message-ID: <E17JySu-0003hA-00@usw-sf-web3.sourceforge.net>

Bugs item #472568, was opened at 2001-10-18 17:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472568&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Nobody/Anonymous (nobody)
Summary: PyBuffer_New() memory not aligned

Initial Comment:
Memory buffer areas created by PyBuffer_New are
missaligned on 32 bit machines, for doubles (64 bit).

This typically generates a bus error crash on most RISC
machines when a library function tries to write a
double in a memory buffer allocated by PyBuffer_New().

When looking at the bufferobject.c code, this seems to
come from the fact that  the memory buffer points at
'malloc() + sizeof  struct PyBufferObject'; 	[line:
b->b_ptr = (void *)(b + 1); ]

To the extent that struct PyBufferObject is not a
multiple of sizeof (double), the largest value type;
thus the misalignment, and the crashes on most RISC
processors.

A quick and temporary solution would consist in adding
a dummy double field as the last field of the
PyBufferObject structure:

struct PyBufferObject {
...
double dummy; 
} ;

and setting
b->b_ptr = (void*)&b->dummy;  /*was (void*(b+1)*/

In doing so, b->b_ptr will always by aligned on sizeof
(double), on either 32 and 64 bit architectures.


Since I'm on the buffer type problem: It would be nice
(and probably easy to do) to augment the buffer
protocol interface with the ability to specify the
basic value type stored in the buffer.

A possible list of values (enum ...) would be:

- undefined (backward compatibility)
- char, unsigned char, short, ....int, ... long, long
long, float, double, and void* (memory address).

This would enable to check at runtime the type of
values stored in a buffer (and prevent missalignement
buserrors, as well as catching garbage situations when
improper array types are passed by means of the buffer
interface [e.g.: int/float/double/short...).

Frederic Giacometti


Frederic Giacometti






----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-06-17 11:30

Message:
Logged In: YES 
user_id=31435

Unassigned -- I don't expect to work on this.

----------------------------------------------------------------------

Comment By: Frederic Giacometti (giacometti)
Date: 2001-11-01 12:21

Message:
Logged In: YES 
user_id=93657

The solution Tim proposes (2d malloc) will be very fine with
what we do.

Here are some more details on what we're doing (and this is
a standard operation):

- We want to create an array of double that we pass to a C
function, and then return this array to Python as buffer
object (the buffer is passed latter on as arg to other
functions using the buffer interface); and do it so that
Python takes ownership of the buffer memory management.

- We don't want to require Numerical to operate the package;
just for memory allocation.

- We should actually be using the Python array module
interface.
Unfortunately:
  * the Python array object C definitions are not exported
in a .h file
  * the Array python interface does not provide the ability
to create a new array of an arbitrary size (and certainly
initialized to 0). One has to provide a list or a string to
create an array of a given size.  IThis is not workable if
we work we large arrays (e.g.: an array of 1.000.000 doubles
is only 8 MB RAM ...).

Another  solution, then, would consist in extending the
array Python interface, so as to enable the creation of
arrays of arbitrary sizes (prefereably initialized to 0 or
to something alse with a calloc or a memset).

The extension of the array.array() function could be the
better solution, taking into account our needs as well as
Tim's concerns.

FG

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-31 20:31

Message:
Logged In: YES 
user_id=31435

The only portable way to fix this (assuming it's broken -- 
I don't see any alignment promises in the docs, and since 
we never use it we can't mine the source code for clues 
either) is to have PyBuffer_New do a second separate malloc
(size) and set b_ptr to that.  The C std guarantees memory 
returned by malloc is suitably aligned for all purposes; it 
doesn't promise that any standard type captures the 
strictest alignment requirement (indeed, at KSR we returned 
128-byte aligned memory from malloc, to cater to 
our "subpage" type extension).

----------------------------------------------------------------------

Comment By: Frederic Giacometti (giacometti)
Date: 2001-10-31 19:31

Message:
Logged In: YES 
user_id=93657

A portable solution (im[provement over what I proposed)
would consitst in declaring 'dummy' with a union type,
'unionizing' all C-ANSI value types (and including 'long
long' optionally by mean of an #ifdef).

 { .... union { int Int; long Long; double Double; void*
Pvoid ...} dummy; }

All (void*)obj->dummy can be replaced with obj->dummy.Pvoid

FG


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-10-22 16:19

Message:
Logged In: YES 
user_id=31392

Note to whomever take this bug: PyBuffer_New() is not called
anywhere in the Python source tree; nor are there any tests
for buffer objects that I'm aware of.  A few simple test
cases would have caught this bug already.  (And for the case
of the builtin buffer() call, it might be good if it used
PyBuffer_New().)


----------------------------------------------------------------------

Comment By: Frederic Giacometti (giacometti)
Date: 2001-10-18 17:35

Message:
Logged In: YES 
user_id=93657

I wasn't looged in when I submitted the item. Don't think
I'm becoming anonymous :))


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=472568&group_id=5470



From noreply@sourceforge.net  Mon Jun 17 16:45:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 17 Jun 2002 08:45:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-533735 ] cut-o/paste-o in Marshalling doc: 2.2.1
Message-ID: <E17JyhR-0000wc-00@usw-sf-web2.sourceforge.net>

Bugs item #533735, was opened at 2002-03-22 14:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533735&group_id=5470

>Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Scott David Daniels (scott_daniels)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: cut-o/paste-o in Marshalling doc: 2.2.1

Initial Comment:
Not very hard to figure out, but easy enough to fix:

5.4 Data marshalling support

>>> (A)
void PyMarshal_WriteObjectToFile(PyObject *value, FILE 
*file) 
Marshal a Python object, value, to file. This will 
only write the least-significant 16 bits of value; 
regardless of the size of the native short type.

>>> The final sentence should be dropped (or moved to 
spot XYZ)

>>> (B)
int PyMarshal_ReadShortFromFile(FILE *file) 
Return a C short from the data stream in a FILE* 
opened for reading. Only a 16-bit value can be read in 
using this function, regardless of the native size of 
long. 

>>> perhaps "... native size of short."  (this is XYZ)


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-17 11:45

Message:
Logged In: YES 
user_id=3066

Commited corrections to the sources in Doc/api/utilities.tex
revisions 1.5 and 1.3.8.1.  Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533735&group_id=5470



From noreply@sourceforge.net  Mon Jun 17 18:17:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 17 Jun 2002 10:17:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-523473 ] PyModule_AddObject doesn't set exception
Message-ID: <E17K08Y-0005w4-00@usw-sf-web3.sourceforge.net>

Bugs item #523473, was opened at 2002-02-27 11:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=523473&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Yakov Markovitch (markovitch)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: PyModule_AddObject doesn't set exception

Initial Comment:
PyModule_AddObject tests for its first parameter to be
a module and third to be non-NULL and returns -1 if
these are wrong, but doesn't set any exception. This
behaviour is obviously wrong (at least for the case
when first parameter is not a module - this must be a
PyExc_TypeError).

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-17 13:17

Message:
Logged In: YES 
user_id=3066

Actually, it doesn't check the 3rd arg, nor does it need to.
I've added appropriate exceptions in Python/modsupport.c
revisions 2.55.2.1, 2.58.16.1, and 2.60.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=523473&group_id=5470



From noreply@sourceforge.net  Mon Jun 17 18:36:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 17 Jun 2002 10:36:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-552957 ] email.Utils.encode doesn't obey rfc2047
Message-ID: <E17K0Qx-0003r8-00@usw-sf-web2.sourceforge.net>

Bugs item #552957, was opened at 2002-05-06 14:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=552957&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ty Sarna (tsarna)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Utils.encode doesn't obey rfc2047

Initial Comment:
The email.Utils.encoding function has two bugs, which
are somewhat related -- it fails to deal with long
input strings in two different ways.

First, newlines are not allowed in the middle of
rfc2047 encoded-words (per section 2: "[...] white
space characters MUST NOT appear between components of
an 'encoded-word'"). The _bencode and _qencode routines
that the encode function uses include newlines (or
"=\n"'s for quopri) in their output, and the encode
function doesn't remove them. Try encoding a long
string with 'q' for example. The resulting output will
contain one or more "= \n"'s, and the
email.Utils.decode function will not be able to parse it.

Patch:

*** Utils.py.orig       Mon May  6 13:17:05 2002
--- Utils.py    Mon May  6 13:18:16 2002
***************
*** 98,106 ****
      """Encode a string according to RFC 2047."""
      encoding = encoding.lower()
      if encoding == 'q':
!         estr = _qencode(s)
      elif encoding == 'b':
!         estr = _bencode(s)
      else:
          raise ValueError, 'Illegal encoding code: ' +
encoding
      return '=?%s?%s?%s?=' % (charset.lower(),
encoding, estr)
--- 98,106 ----
      """Encode a string according to RFC 2047."""
      encoding = encoding.lower()
      if encoding == 'q':
!         estr = _qencode(s).replace('=\n','')
      elif encoding == 'b':
!         estr = _bencode(s).replace('\n','')
      else:
          raise ValueError, 'Illegal encoding code: ' +
encoding
      return '=?%s?%s?%s?=' % (charset.lower(),
encoding, estr)

NOTE: The .replace()-ing should NOT be done in _bencode
and _quencode, because they're used other places where
their current behaviour is fine/expected.


Second problem: rfc2047 specifies that an encoded-word
 may be no longer than 75 characters (see section 2).
Also, in the case of, say, a From: header with high-bit
characters in the sender's name, you really want to
encode only the name, not the whole line, so that dumb
mail programs are able to recognize the email address
in the line without having to understand rfc2047.

Proposed solution: rename existing encode function
(with above patche applied) to encode_word. Add a new
encode function that splits the input string into a
list of words and whitespace runs.  Words are encoded
individually using encode_word() iff they are not pure
ascii. The results are then concatenated back with
original whitespace.

This still leaves the possibility that a single word,
when encoded, is longer than 75 characters. The
recommended practice in rfc2047 is to use multiple
encoded words separated by CRLF SPACE (or in our case ,
"\n "). 


Here is code that implements the above:

wsplit = re.compile('([ \n\t]+)').split


def encode(s, charset='iso-8859-1', encoding='q'):
    i = wsplit(s)
    o = []

    # max encoded-word length per rfc2047 section 2 is 75
    # 75 - len("=?" + "?" + "?" + "?=") == 69
    max_enc_text = 69 - len(charset) - len(encoding)
    if encoding == 'q':
        # 3 bytes per character worst case
        safe_wlen = max_enc_text / 3
    elif encoding == 'b':
        safe_wlen = (max_enc_text * 6) / 8
    else:
        safe_wlen = max_enc_text # ?

    for w in i:
        if w[0] in " \n\t":
            o.append(w)
        else:
            try:
                o.append(w.encode('ascii'))
            except:
                ew = encode_word(w, charset, encoding)
                while len(ew) > 75:
                   
o.append(encode_word(w[:safe_wlen],charset,encoding)+"\n ")
                    w = w[safe_wlen:]
                    ew = encode_word(w, charset, encoding)
                o.append(ew)

    return ''.join(o)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=552957&group_id=5470



From noreply@sourceforge.net  Mon Jun 17 18:38:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 17 Jun 2002 10:38:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-556370 ] Expat improperly described in setup.py
Message-ID: <E17K0Sf-00067S-00@usw-sf-web3.sourceforge.net>

Bugs item #556370, was opened at 2002-05-15 10:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556370&group_id=5470

>Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Moshe Yudkowsky (myudkowsky)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Expat improperly described in setup.py

Initial Comment:
This bug is for 2.2.1, not 2.2.1 "candidate."

Setup.py in the home directory explains how to obtain
the current version of the expat package. However, it
gives the path to the private home page of the original
developer. The package at that location is incorrect;
the correct package is at
<http://sourceforge.net/projects/expat/>.

The stale package introduces several problems:
* The package does not create the "expat.h" in
/usr/include that setup.py looks for
* The stale package does not automatically create libaries

The correct package fixes both of these problems.

SUGGESTED FIX:

* Modify setup.py to point to correct package. Note:
configure, make, make install will install the correct
libaries and include files.

* Modify README to include information about expat.
Speaking as a user, there's no reason for me to suspect
that I have to read setup.py to find out which modules
might not be included when I compile! Information about
expat belongs in README, so that I understand what
packages might be necessary for me to install before I
run the installation process.

HELP:

If you wish to assign me to rewrite this documentation,
I can do so; I'm a little reluctant to touch setup.py
because I only have a Linux setup here, and touching
any py module means testing across builds IMHO.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-15 13:24

Message:
Logged In: YES 
user_id=21627

I would appreciate if you could produce a patch (context
diff, please), both for setup.py, and Modules/Setup.

I don't think modifying README is necessary, since the
reader is already directed to read Modules/Setup in README.
If you would like to see specific text, feel free to include
it in your patch.

Please attach the patch to this report.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556370&group_id=5470



From noreply@sourceforge.net  Mon Jun 17 18:43:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 17 Jun 2002 10:43:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-561822 ] ConfigParser has_option case sensitive
Message-ID: <E17K0Wx-0000Lw-00@usw-sf-web4.sourceforge.net>

Bugs item #561822, was opened at 2002-05-29 03:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561822&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Taylor (knet)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: ConfigParser has_option case sensitive

Initial Comment:
In python 2.x ConfigParser.py has_option has the
following case-sensitive code:

	if not section or section == "DEFAULT":
		return self.__defaults.has_key(option)

whereas the rest of the module uses option.lower(). 
This means the DEFAULT section is case-sensitive but
other sections are not.

Attached is a patch to fix the problem in Python 2.2.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561822&group_id=5470



From noreply@sourceforge.net  Mon Jun 17 18:57:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 17 Jun 2002 10:57:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-556370 ] Expat improperly described in setup.py
Message-ID: <E17K0ku-0006Vd-00@usw-sf-web3.sourceforge.net>

Bugs item #556370, was opened at 2002-05-15 10:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556370&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Moshe Yudkowsky (myudkowsky)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Expat improperly described in setup.py

Initial Comment:
This bug is for 2.2.1, not 2.2.1 "candidate."

Setup.py in the home directory explains how to obtain
the current version of the expat package. However, it
gives the path to the private home page of the original
developer. The package at that location is incorrect;
the correct package is at
<http://sourceforge.net/projects/expat/>.

The stale package introduces several problems:
* The package does not create the "expat.h" in
/usr/include that setup.py looks for
* The stale package does not automatically create libaries

The correct package fixes both of these problems.

SUGGESTED FIX:

* Modify setup.py to point to correct package. Note:
configure, make, make install will install the correct
libaries and include files.

* Modify README to include information about expat.
Speaking as a user, there's no reason for me to suspect
that I have to read setup.py to find out which modules
might not be included when I compile! Information about
expat belongs in README, so that I understand what
packages might be necessary for me to install before I
run the installation process.

HELP:

If you wish to assign me to rewrite this documentation,
I can do so; I'm a little reluctant to touch setup.py
because I only have a Linux setup here, and touching
any py module means testing across builds IMHO.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-17 13:57

Message:
Logged In: YES 
user_id=3066

The specific problem you cite is no longer a problem with
the descriptions in our working sources.

I've made additional updates of the descriprion in setup.py
1.94 and 1.73.4.6.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-15 13:24

Message:
Logged In: YES 
user_id=21627

I would appreciate if you could produce a patch (context
diff, please), both for setup.py, and Modules/Setup.

I don't think modifying README is necessary, since the
reader is already directed to read Modules/Setup in README.
If you would like to see specific text, feel free to include
it in your patch.

Please attach the patch to this report.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556370&group_id=5470



From noreply@sourceforge.net  Tue Jun 18 02:24:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 17 Jun 2002 18:24:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-570300 ] inspect.getmodule symlink-related failur
Message-ID: <E17K7jD-0004BB-00@usw-sf-web2.sourceforge.net>

Bugs item #570300, was opened at 2002-06-18 04:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=570300&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Amit Aronovitch (amitar)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.getmodule symlink-related failur

Initial Comment:
news:ae3e29$pib$1@news.netvision.net.il

Description:
--------------

  On a unix python2.2.1 installation I noticed that the 
documentations
generated for modules by pydoc (in any mode - even 
the help command) did NOT
contain any docs for functions.
  After some digging, I found out the reason for that, 
and now I believe it
indicates a deeper problem with the "inspect" module, 
concerning file
identification in the presence of symbolic or hard links, 
which I'll explain
below, and also suggest solutions.

Analysis:
-----------

  The reason the functions were dropped from the doc 
was pydoc's attempt to
remove functions which were imported from other 
modules. This is done by
something like "inspect.getmodule(my_func) is 
my_module". I found out that
inspect.getmodule() returned "None" for these 
functions!

  Now, inspect.getmodule works by getting the 
function's filename, and then
searching it in a dictionary containing the filenames for 
all the modules
that were loaded ("modulesbyfile"). Unfortunately, the 
filename that
getabsfile() returns for the function is not the same 
STRING as the one it
returns for the module, but rather an equivalent unix 
path pointing to the
same FILE
(the reason for this fact is that the filename for a 
function is extracted
from the code-object, which holds the path the module 
was referred to at the
time it was COMPILED to .pyc, whereas the one for 
the module is taken from
it's __file__, which holds the path it was referred to 
when it was
IMPORTED - these two might differ even if it's the 
same file).

 So, the function's file is not found on the dictionary, 
and getmodule()
returns None...

Discussion:
--------------

  We see that the root cause of the problem is 
that "inspect" uses the
"absolute path" (os.path.abspath()) for representing 
the file's identity.
In unix systems, this might cause a problem, since 
this string is NOT unique
(it is a unique path, but different paths may refer to 
the same file).
If we only considered symbolic links, this could be 
resolved by scanning the
path elements and "unfolding" any symlinks, but we 
must recall that unix can
also has "hard links" which are equivalent references to 
the same inode, and
can't be discriminated.

  So, if we want to resolve the problem in a portable 
way, we need an
immutable (platform-dependant) object that will be 
unique to a FILE. This
object could then be used for comparing files and as 
keys for dictionaries.
 A reasonable way to get it would be by means of a 
new function in the os
module. e.g. :

 id = os.get_fileid(filename)
def samefile(f1,f2): return os.get_fileid(f1) is 
os.get_fileid(f2)

 This function could be implemented by the inode 
number (os.stat(f).st_ino)
on unix systems, and by the absolute path 
(os.path.abspath) on systems which
do not support links (such as windows), or by 
anything else, as long as it
would be immutable and unique for each file.


  Please let me know your opinion about this 
suggestion,

       Amit Aronovitch



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=570300&group_id=5470



From noreply@sourceforge.net  Tue Jun 18 04:28:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 17 Jun 2002 20:28:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-223599 ] Need user-centered info for Windows users.
Message-ID: <E17K9ez-0006OS-00@usw-sf-web2.sourceforge.net>

Bugs item #223599, was opened at 2000-11-27 08:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=223599&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 6
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Need user-centered info for Windows users.

Initial Comment:
Users ask questions like "How do I write batch files using Python?"; there should be a document that acts as a user's guide specifically for Windows users.  This could be similar to what the Macintosh Modules Reference is becoming.  This should be part of the standard documentation and could acquire the Windows module documentation.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-17 20:28

Message:
Logged In: NO 

is it a really bad effect after i batch the file

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-07 08:46

Message:
Logged In: NO 

hello! i am wantin! plz

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 14:37

Message:
Logged In: YES 
user_id=31392

Can we move this out of bugs and into feature requests?


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-22 08:04

Message:
Another question that should be answered in this document:  "How do I create/recall modules?"  This one comes up most with first time programmers and users from environments that don't expose source code as editable text files (VB?).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=223599&group_id=5470



From noreply@sourceforge.net  Tue Jun 18 05:19:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 17 Jun 2002 21:19:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-569257 ] __slots__ attribute and private variable
Message-ID: <E17KASe-0006yv-00@usw-sf-web3.sourceforge.net>

Bugs item #569257, was opened at 2002-06-14 19:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470

Category: Type/class unification
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Keyton Weissinger (keytonw)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: __slots__ attribute and private variable

Initial Comment:
If you use a __slots__ class variable and include a 
variable with a double underscore as the first two 
characters, that variable is NOT private as would be the 
case for any other variable whose name begins with a 
double underscore.

If this is by design, then it should be in the docs. If it is 
not and represents a bug, it needs to be investigated.

Thank you!!!

Keyton Weissinger

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-17 23:19

Message:
Logged In: YES 
user_id=80475

Agree that it is a bug.
Working on a patch.

----------------------------------------------------------------------

Comment By: Keyton Weissinger (keytonw)
Date: 2002-06-14 22:31

Message:
Logged In: YES 
user_id=396481

Also, this issue prevents you from using the combination of 
property() and __slots__ which would be powerful, as 
attempting to use them would make __property_name__ a 
legal public variable, no?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470



From noreply@sourceforge.net  Tue Jun 18 05:20:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 17 Jun 2002 21:20:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-563530 ] Missing operator docs
Message-ID: <E17KATp-0006za-00@usw-sf-web3.sourceforge.net>

Bugs item #563530, was opened at 2002-06-02 08:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563530&group_id=5470

Category: Documentation
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: David Abrahams (david_abrahams)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Missing operator docs

Initial Comment:
I see no mention of the following at 
http://www.python.org/dev/doc/devel/ref/numeric-
types.html:

__rfloordiv__
__rtruediv__
__ifloordiv__
__itruediv__


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-17 23:20

Message:
Logged In: YES 
user_id=80475

Will patch and re-assign back to Fred.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563530&group_id=5470



From noreply@sourceforge.net  Tue Jun 18 16:31:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 18 Jun 2002 08:31:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-570640 ] .PYO files not imported unless -OO used
Message-ID: <E17KKwr-0002jJ-00@usw-sf-web3.sourceforge.net>

Bugs item #570640, was opened at 2002-06-18 10:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=570640&group_id=5470

Category: Parser/Compiler
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Sasmor (jeffsasmor)
Assigned to: Nobody/Anonymous (nobody)
Summary: .PYO files not imported unless -OO used

Initial Comment:
If you execute a program where all the files/modules 
are .pyo, that is, compiled while the interpreter had been 
started with the -OO command-line option (and presumably -
O as well), then imports fail unless the interpreter had been 
started with -OO (-O?) during that run of the program.

Thus, if you want to distribute a program in its smallest form 
where you might run a 'build' script that uses the compileall
built-in to create a distribution fileset that comprises 
only .pyo files, you'd obviously need to run that script with 
the Python interpreter in -OO 'mode'.  

When you you try to run the target program from the 
distribution fileset, you are required to start the interpreter 
in -OO mode or all imports fail since the interpreter does not 
search for that extension unless -OO has been used. One 
workaround is to rename all the .pyo files to .pyc files, but 
this is somewhat silly....  This sitution is undocumented 
AFAIK. 

Additionally, it would be nice to be able to switch this 
optimize mode on/off programmatically.  In the app I am 
working on (an 'IDE' for Python) I store code objects 
(created by using the compile built-in)  in the ZODB.  If I 
have to run the interpreter in -OO mode then I lose debug 
information that I'd like to keep. Hence it would be nice to 
be able to turn this mode on and off.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=570640&group_id=5470



From noreply@sourceforge.net  Tue Jun 18 17:07:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 18 Jun 2002 09:07:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-570655 ] bdist_rpm and the changelog option
Message-ID: <E17KLWE-0006OR-00@usw-sf-web1.sourceforge.net>

Bugs item #570655, was opened at 2002-06-18 12:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=570655&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mihai Ibanescu (misa)
Assigned to: Nobody/Anonymous (nobody)
Summary: bdist_rpm and the changelog option

Initial Comment:
I think the changelog option for bdist_rpm is not
correctly handled. The documentation says it should
expect a path to a file containing the changelog
entries, but in bdist_rpm.py, line 200, it tries to
read it as a string (ensure_string etc).

The changelogs are multiple lines, and I was unable to
add multi-lined entries in setup.cfg. Even so, the
documentation is still misleading.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=570655&group_id=5470



From noreply@sourceforge.net  Tue Jun 18 17:59:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 18 Jun 2002 09:59:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-570678 ] CGIHTTPServer flushes read-only file.
Message-ID: <E17KMJq-0000Am-00@usw-sf-web4.sourceforge.net>

Bugs item #570678, was opened at 2002-06-18 16:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=570678&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Tony Lownds (tonylownds)
Assigned to: Nobody/Anonymous (nobody)
Summary: CGIHTTPServer flushes read-only file.

Initial Comment:
On Mac OS X, flushing a file open only for reading
causing an IOError. That behavior matches what the
system's fflush man page describes:

ERRORS
     [EBADF]            Stream is not an open stream,
or, in the case of
                        fflush(), not a stream open for
writing.

CGIHTTPServer.py calls .flush on the read-only part of
it's socket before it forks and then quickly breaks.

The attached patch simply removes that line.
The bug is listed as Platform-specific because this
behavior does not appear under Linux (even though the
fflush man page on Linux lists the same EBADF error).



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=570678&group_id=5470



From noreply@sourceforge.net  Tue Jun 18 19:43:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 18 Jun 2002 11:43:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-493243 ] ext call doco warts
Message-ID: <E17KNwo-0002iY-00@usw-sf-web4.sourceforge.net>

Bugs item #493243, was opened at 2001-12-14 05:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493243&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Michael Hudson (mwh)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: ext call doco warts

Initial Comment:
Now they've been compiled <wink>, I notice that there
are some warts in my docs for the *- and **-style call
syntax.

1) the "argument_list" production is really, really
confusing.  there must be a better BNF-style way of
saying that.  I don't think vertically centering the
production name against the production helps.

2) For some reason, where I say

It is unusual for both keyword arguments and the
"*expression"syntax to be used in the same call, so in
practice this confusion does not arise.

there's no space between `"*expression"' and `syntax'.
 I'd guess that this is because in the source, the
\samp{} macro is the last thing on the line, but why
that should lead to a missing space is beyond me --
more latex2html bugs?

(just noticed the same thing a bit higher up too -- 

the "**expression"argument, if any 

No hurry with these.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-18 14:43

Message:
Logged In: YES 
user_id=3066

1) Do you still see vertical centering of the production
name?  That should be aligned with the top of the definition
text.  I've played contortionist with that production in
Doc/ref/ref5.tex revision 1.62.

2) That's not another bug, that's the one that keeps biting
us.  I'm not sure whether that's in latex2html itself or in
my extension code for it.  ;-(  This has already been fixed
on the trunk.

I'm closing this, since I think we're ok now; feel free to
re-open or file a new report if you think my changes aren't
sufficient.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-14 10:24

Message:
Logged In: YES 
user_id=3066

Bumped priority; needs review.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-06-14 10:09

Message:
Logged In: YES 
user_id=6656

I'm going to check my fix in unless someone complains *real*
soon.

At least I know it compiles now, and I think it's an
improvement.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-12-20 09:25

Message:
Logged In: YES 
user_id=6656

Another problem with the pseudo-EBNF: it's wrong.  Oops.

It suggests that f(a, **b) isn't legal, for example.

I've attached an attempt I think it right, but I'm not sure 
and haven't compiled it (& so don't know if it looks any less 
confusing than last time).


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-12-14 12:01

Message:
Logged In: YES 
user_id=3066

Fixed table cell alignment in Doc/perl/python.perl revision
1.115.

Fixed item 2:  Worked around spaces problem in
Doc/ref/ref5.tex 1.53

This bug remains open; I still need to address the basic
problem in item 1 (confusing pseudo-EBNF).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493243&group_id=5470



From noreply@sourceforge.net  Tue Jun 18 19:52:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 18 Jun 2002 11:52:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-551912 ] mimify.mime_decode_header only latin1
Message-ID: <E17KO5g-0002tN-00@usw-sf-web4.sourceforge.net>

Bugs item #551912, was opened at 2002-05-03 12:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551912&group_id=5470

Category: Python Library
Group: None
>Status: Closed
Resolution: Wont Fix
Priority: 3
Submitted By: Gerhard Häring (ghaering)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: mimify.mime_decode_header only latin1

Initial Comment:
This function only works for iso-8859-1. If you look at
the regex it uses, it's also clear why. I'll try to
come up with a patch.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-18 14:52

Message:
Logged In: YES 
user_id=3066

Documentation updated to note the limitation in
Doc/lib/libmimify.tex revisions 1.12, 1.11.18.1, and 1.10.8.1.

----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2002-05-08 09:22

Message:
Logged In: YES 
user_id=163326

Assigning to Fred Drake and lowering priority and marking
WONTFIX.

Fred, do you think that a note should be added to the docs
about the weaknesses of the mimify module and that the new
stuff from the email module should be used instead?

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-05-03 13:05

Message:
Logged In: YES 
user_id=12800

Yup, I agree.  For a while, I've wanted to deprecate mimify,
(the api to) rfc822, MIMEWriter, and mimetools.  I think the
hangup on doing this for Python 2.2 was to try to come up
with recipes for folks to migrate their code to the email
package.  I don't have time to do that though.  Maybe a faq
or howto on the email package could address these issues, so
that we can deprecate them for Python2.3 (but not remove
them for a long time, probably 2 years at least, see PEP 4)

----------------------------------------------------------------------

Comment By: Gerhard Häring (ghaering)
Date: 2002-05-03 12:48

Message:
Logged In: YES 
user_id=163326

Some of the code in this module is rather brain-dead (not
unicode-aware, hard-wired to latin1). Maybe it's best to
deprecate it or mark it as buggy in the docs. The new email
module provides better functions for this, anyway (info from
MvL):

email.Utils.decode (Python 2.2)

email.Header.decode_header (CVS)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551912&group_id=5470



From noreply@sourceforge.net  Tue Jun 18 20:19:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 18 Jun 2002 12:19:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-553262 ] [RefMan] Special status of "as"
Message-ID: <E17KOVg-0002VI-00@usw-sf-web3.sourceforge.net>

Bugs item #553262, was opened at 2002-05-07 09:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553262&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: [RefMan] Special status of "as"

Initial Comment:
The special status of "as" in import statements needs
to be acknowledged in the list of keywords (RefMan 2.3.1).

(Based on note sent to python-docs.)

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-18 15:19

Message:
Logged In: YES 
user_id=3066

Documention updated in Doc/ref/ref2.tex revisions 1.37,
1.34.6.2, and 1.23.4.1.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-13 02:39

Message:
Logged In: YES 
user_id=31435

That's OK. *I* still love you!  Not sure about Fred <wink>.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-13 02:33

Message:
Logged In: YES 
user_id=80475

My mistake :(

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-12 03:45

Message:
Logged In: YES 
user_id=31435

Reopened.  When an active developer opens a bug and assigns 
it to themself (Fred opened this and assigned it to 
himself), they have a reason that shouldn't be second-
guessed without discussion (in this case, "as" is not a 
builtin name, and it is special in one context -- Fred 
wants a reminder here to change the docs accordingly).

Unfortunately, once the Resolution field on an SF report is 
set to anything other than "None", it can't be changed back 
to None again.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-12 03:33

Message:
Logged In: YES 
user_id=80475

Several important words like None are not listed as 
keywords.  In this case, there is no need because assigning 
to 'as' does not ambiguate the syntax:

>>> import sys as sass
>>> dir()
['__builtins__', '__doc__', '__name__', 'sass']
>>> as = 12
>>> import os as oz
>>> dir()
['__builtins__', '__doc__', '__name__', 'as', 'oz', 'sass']

Thanks for raising the issue.  I'm going to close this one 
because I think it's invalid.  If someone disagrees, feel 
free to resurrect it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553262&group_id=5470



From noreply@sourceforge.net  Tue Jun 18 21:32:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 18 Jun 2002 13:32:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-530637 ] Popen3 might cause dead lock
Message-ID: <E17KPei-0003i7-00@usw-sf-web1.sourceforge.net>

Bugs item #530637, was opened at 2002-03-16 04:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530637&group_id=5470

Category: Documentation
Group: Feature Request
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Thomas Guettler (guettli)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Popen3 might cause dead lock

Initial Comment:
Please include a hint in the documentation of popen3
that it can produce a dead lock.

Example:

The subprocess writes a lot of data to stderr and
blocks and your application reads from stdout. It
might result in a dead lock

An other explanation to this can be found here:
http://mail.python.org/pipermail/python-dev/2000-September/009460.html

Unfortunately popen3 is documented twice. Would be nice
if there is a
hint to deadlocks at both places. I am programming
quite long and I
lost hours debugging why this happens sometimes and
sometimes not. (It
only happens if you have a lot of output)

In the documentation of Perl there is a hint
to this problem, too.

thomas

(I already submitted this feature request to
python-docs@python.org. But received no response)









----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-18 16:32

Message:
Logged In: YES 
user_id=3066

Added a section on flow control issues to the documentation
for the popen2 module, with a reference from the
corresponding functions in the os module.

Doc/lib/libos.tex:     1.90, 1.74.2.1.2.5, 1.53.4.9.
Doc/lib/libpopen2.tex: 1.16, 1.15.12.1, 1.13.6.2.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530637&group_id=5470



From noreply@sourceforge.net  Tue Jun 18 21:41:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 18 Jun 2002 13:41:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-530637 ] Popen3 might cause dead lock
Message-ID: <E17KPmo-00049V-00@usw-sf-web3.sourceforge.net>

Bugs item #530637, was opened at 2002-03-16 09:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530637&group_id=5470

Category: Documentation
Group: Feature Request
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Thomas Guettler (guettli)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Popen3 might cause dead lock

Initial Comment:
Please include a hint in the documentation of popen3
that it can produce a dead lock.

Example:

The subprocess writes a lot of data to stderr and
blocks and your application reads from stdout. It
might result in a dead lock

An other explanation to this can be found here:
http://mail.python.org/pipermail/python-dev/2000-September/009460.html

Unfortunately popen3 is documented twice. Would be nice
if there is a
hint to deadlocks at both places. I am programming
quite long and I
lost hours debugging why this happens sometimes and
sometimes not. (It
only happens if you have a lot of output)

In the documentation of Perl there is a hint
to this problem, too.

thomas

(I already submitted this feature request to
python-docs@python.org. But received no response)









----------------------------------------------------------------------

>Comment By: Thomas Guettler (guettli)
Date: 2002-06-18 20:41

Message:
Logged In: YES 
user_id=22123

Thank you very much!


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-18 20:32

Message:
Logged In: YES 
user_id=3066

Added a section on flow control issues to the documentation
for the popen2 module, with a reference from the
corresponding functions in the os module.

Doc/lib/libos.tex:     1.90, 1.74.2.1.2.5, 1.53.4.9.
Doc/lib/libpopen2.tex: 1.16, 1.15.12.1, 1.13.6.2.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530637&group_id=5470



From noreply@sourceforge.net  Wed Jun 19 10:26:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 19 Jun 2002 02:26:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-570678 ] CGIHTTPServer flushes read-only file.
Message-ID: <E17Kbji-0000L1-00@usw-sf-web3.sourceforge.net>

Bugs item #570678, was opened at 2002-06-18 18:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=570678&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Tony Lownds (tonylownds)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: CGIHTTPServer flushes read-only file.

Initial Comment:
On Mac OS X, flushing a file open only for reading
causing an IOError. That behavior matches what the
system's fflush man page describes:

ERRORS
     [EBADF]            Stream is not an open stream,
or, in the case of
                        fflush(), not a stream open for
writing.

CGIHTTPServer.py calls .flush on the read-only part of
it's socket before it forks and then quickly breaks.

The attached patch simply removes that line.
The bug is listed as Platform-specific because this
behavior does not appear under Linux (even though the
fflush man page on Linux lists the same EBADF error).



----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-06-19 11:26

Message:
Logged In: YES 
user_id=45365

Apparently Guido is the one who put the self.rfile.flush() call in there, so he's probably also the person who knows whether it's a good idea to take it out again.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=570678&group_id=5470



From noreply@sourceforge.net  Wed Jun 19 11:25:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 19 Jun 2002 03:25:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-493243 ] ext call doco warts
Message-ID: <E17Kcek-0002Wv-00@usw-sf-web4.sourceforge.net>

Bugs item #493243, was opened at 2001-12-14 10:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493243&group_id=5470

Category: Documentation
Group: None
>Status: Open
Resolution: Fixed
Priority: 6
Submitted By: Michael Hudson (mwh)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: ext call doco warts

Initial Comment:
Now they've been compiled <wink>, I notice that there
are some warts in my docs for the *- and **-style call
syntax.

1) the "argument_list" production is really, really
confusing.  there must be a better BNF-style way of
saying that.  I don't think vertically centering the
production name against the production helps.

2) For some reason, where I say

It is unusual for both keyword arguments and the
"*expression"syntax to be used in the same call, so in
practice this confusion does not arise.

there's no space between `"*expression"' and `syntax'.
 I'd guess that this is because in the source, the
\samp{} macro is the last thing on the line, but why
that should lead to a missing space is beyond me --
more latex2html bugs?

(just noticed the same thing a bit higher up too -- 

the "**expression"argument, if any 

No hurry with these.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-06-19 10:25

Message:
Logged In: YES 
user_id=6656

Sorry, you need to reread my comment of 2001-12-20: the
problem with the pseudo-BNF as it stands is that it is
WRONG!  This is what my patch attempts to fix.

The problems mentioned originally have been fixed -- perhaps
I should have opened a new report.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-18 18:43

Message:
Logged In: YES 
user_id=3066

1) Do you still see vertical centering of the production
name?  That should be aligned with the top of the definition
text.  I've played contortionist with that production in
Doc/ref/ref5.tex revision 1.62.

2) That's not another bug, that's the one that keeps biting
us.  I'm not sure whether that's in latex2html itself or in
my extension code for it.  ;-(  This has already been fixed
on the trunk.

I'm closing this, since I think we're ok now; feel free to
re-open or file a new report if you think my changes aren't
sufficient.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-14 14:24

Message:
Logged In: YES 
user_id=3066

Bumped priority; needs review.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-06-14 14:09

Message:
Logged In: YES 
user_id=6656

I'm going to check my fix in unless someone complains *real*
soon.

At least I know it compiles now, and I think it's an
improvement.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-12-20 14:25

Message:
Logged In: YES 
user_id=6656

Another problem with the pseudo-EBNF: it's wrong.  Oops.

It suggests that f(a, **b) isn't legal, for example.

I've attached an attempt I think it right, but I'm not sure 
and haven't compiled it (& so don't know if it looks any less 
confusing than last time).


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-12-14 17:01

Message:
Logged In: YES 
user_id=3066

Fixed table cell alignment in Doc/perl/python.perl revision
1.115.

Fixed item 2:  Worked around spaces problem in
Doc/ref/ref5.tex 1.53

This bug remains open; I still need to address the basic
problem in item 1 (confusing pseudo-EBNF).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493243&group_id=5470



From noreply@sourceforge.net  Wed Jun 19 14:36:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 19 Jun 2002 06:36:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows)
Message-ID: <E17KfdU-0003RZ-00@usw-sf-web2.sourceforge.net>

Bugs item #216289, was opened at 2000-10-06 19:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: Later
Priority: 3
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: Programs using Tkinter sometimes can't shut down (Windows)

Initial Comment:
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


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-19 06:36

Message:
Logged In: NO 

I just downloaded Ruby 1.6.6 for Windows, which also uses 
Tcl/Tk 8.3 and I experience exactly the same problem there. 
So this is definitely a Tcl problem (but we know that already).

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-06-07 12:01

Message:
Logged In: YES 
user_id=143340

Hmmm. 
I run a Python Tcl/Tk application several times every day - 
the very application that prompted my bug-hunt.

I do use "pythonw.exe" to launch it, but it used to hang 
almost as badly as "python.exe".

Whilst developing this app I used "python.exe" and 
experienced no hang-ups.

The Tcl guys point out that this bug is only one of several 
possible causes of the hang-up, maybe you are just out of 
luck.

The patch has fixed the problem on three Win98 machines, 
all of which exhibited the problem before updating the DLLs.

One thought - are you sure there weren't multiple copies of 
the tcl83.dll and tk83.dll files? My (only) copies were 
in "D:\python20\DLLs"

good luck,
John.


----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-06-03 11:55

Message:
Logged In: YES 
user_id=72656

providing Tim with a fixed DLL exactly according to John 
Popplewell's patch did not fix the problem for him.  That 
makes it seem fishy that John really didn't see the problem 
any more.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-03 09:59

Message:
Logged In: YES 
user_id=31435

I tried replacing Python 2.2.1's tk83.dll and tcl83.dll (from 
Tcl/Tk 8.3.2) with newer matched sets from

A) PythonWare's py21 distribution (Tcl/Tk 8.3.3).

and again from

B) ActiveState's Tcl/Tk 8.3.4.

All the symptoms originally reported here persisted on 
Win98SE despite that.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-22 06:57

Message:
Logged In: NO 

I am new to Python and encountered this bug on my very first 
Tkinter application.  It persists in Python 2.2.1 under 
Windows Me. Needless to say, it makes a bad first 
impression.  Basically, this thread says that Tkinter has been 
broken for a year and a half on a popular platform at a time 
when Python is trying to expand its user base.  Hopefully, this 
bug will be corrected soon.

If Tcl/Tk 8.4 is not released shortly you might try repackaging 
Tkinter for Win32 with an earlier version of Tcl/Tk, such as 
8.0, that doesn't encounter this problem.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 19:36

Message:
Logged In: YES 
user_id=6380

The proper action is to wait until Tcl 8.3.5 is released,
and then shaming someone else in providing you with a set of
Windowsbinaries for Tcl. You may also ask Hobbs if there's a
Windows project file to build Tcl/Tk for Windows.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-03-11 18:31

Message:
Logged In: YES 
user_id=72656

I did end up back-porting this to the 8.3.4+ Tcl CVS on 
2002-02-25, which means it will be in an eventual 8.3.5.  
It is already in the release 8.4 alpha series.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 17:50

Message:
Logged In: YES 
user_id=31435

Back to Guido:  Do you think you know what the proper 
action is?  (You said that's why you reopened it, and 
there's been no new info here since then.)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 16:55

Message:
Logged In: YES 
user_id=143340

I knew I wasn't getting to the heart of it ....

Almost a one-liner!

It has been seriously spoiling my (otherwise crash free) 
Python experience on Win9x - hope it gets fixed soon.

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-25 15:39

Message:
Logged In: YES 
user_id=6380

Reopened until we know what the proper action is.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-02-25 15:32

Message:
Logged In: YES 
user_id=72656

This is mostly correct, and is fixed in the 8.4 Tcl sources 
already (I guess we can backport this).  This was mentioned 
in SF Tcl bug (account for chopped URL):

https://sourceforge.net/tracker/?
func=detail&aid=217982&group_id=10894&atid=110894

and the code comment is:

    /*
     * Only finalize the notifier if a notifier was 
installed in the
     * current thread; there is a route in which this is not
     * guaranteed to be true (when tclWin32Dll.c:DllMain() 
is called
     * with the flag DLL_PROCESS_DETACH by the OS, which 
could be
     * doing so from a thread that's never previously been 
involved
     * with Tcl, e.g. the task manager) so this check is 
important.
     *
     * Fixes Bug #217982 reported by Hugh Vu and Gene 
Leache.
     */
    if (tsdPtr == NULL) {
	return;
    }


----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 14:41

Message:
Logged In: YES 
user_id=143340

This one has been torturing me for a while.

Managed to track it down to a problem inside Tcl.
For the Tcl8.3.4 source distribution the problem is in
the file win/tclWinNotify.c 

void Tcl_FinalizeNotifier(ClientData clientData)
{
    ThreadSpecificData *tsdPtr = 
                         (ThreadSpecificData *) clientData;

    /* sometimes called with tsdPtr == NULL */
    if ( tsdPtr != NULL )
    {
        DeleteCriticalSection(&tsdPtr->crit);
        CloseHandle(tsdPtr->event);

        /*
         * Clean up the timer and messaging 
         * window for this thread.
         */

        if (tsdPtr->hwnd) {
	    KillTimer(tsdPtr->hwnd, INTERVAL_TIMER);
            DestroyWindow(tsdPtr->hwnd);
        }
    }

    /*
     * If this is the last thread to use the notifier, 
     * unregister the notifier window class.
     */

    Tcl_MutexLock(&notifierMutex);
    if ( notifierCount && !--notifierCount ) {
	UnregisterClassA( "TclNotifier", 
                          TclWinGetTclInstance());
    }
    Tcl_MutexUnlock(&notifierMutex);
}

This bodge doesn't address the underlying problem but has 
stopped me from tearing all my hair out,

cheers,
John Popplewell.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-24 15:27

Message:
Logged In: YES 
user_id=31435

FYI, you don't need an IDE to do this -- in Win9x, hit 
Ctrl+Alt+Del and kill the process directly.

A saner <wink> solution is to develop under Win2K, which 
doesn't appear to suffer this problem (the only reports 
I've seen, and experienced myself, came from Win9x boxes).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-24 01:52

Message:
Logged In: NO 

For those who are still trapped in this bug's hell, I will 
gladly share the one thing that saved my sanity:  
WingIDE's 'Kill' command will shut down the program with 
apparent 100% certainty and no fear of lockups.  WingIDE 
has its own issues, so its not a perfect solution, but if 
you are like me and Joe (above) who test in small 
iterations, then using 'Kill' to quit out of your app while 
testing is a workaround that may preserve your sanity.

Perhaps the python gods and the Wing guys can get together 
and tell us how to replicate 'kill' into our code.  For 
now, I'll use WingIDE to edit, and pythonw.exe for my final 
client's delivery.

----------------------------------------------------------------------

Comment By: Howard Lightstone (hlightstone)
Date: 2001-09-05 10:43

Message:
Logged In: YES 
user_id=66570

I sometimes get bunches of these....

A tool I use (Taskinfo2000) reports that (after killing 
winoldap):

python.exe is blocked on a mutex named OLESCELOCKMUTEX.
The reported state is "Console Terminating".  There appears 
to be only one (os) thread running.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-02 13:06

Message:
Logged In: YES 
user_id=31435

No sign of progress on this presumed Tk/Tcl Windows bug in 
over 3 months, so closing it for lack of hope.

----------------------------------------------------------------------

Comment By: Doug Henderson (djhender)
Date: 2001-02-05 21:13

Message:
This was a symptom I saw while tracking down the essence of the problem reported in #131207.  Using Win98SE, I would get an error dialog (GPF?) in the Kernel, and sometimes the dos prompt would not come back.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-12-12 18:00

Message:
Just reproduced w/ current CVS, but didn't hang until the 8th try.

http://dev.scriptics.com/software/tcltk/ says 8.3 is still the latest released version; don't know whether that URL still makes sense, though.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-12-12 12:58

Message:
Tim, can you still reproduce this with the current CVS version?

There's been one critical patch to _tkinter since the 2.0 release.

An alternative would be to try with a newer version of Tcl (isn't 8.4 out already?).


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-15 09:47

Message:
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>

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-13 07:40

Message:
Back to Tim since I have no clue what to do here.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-12 10:25

Message:
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.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-10-07 00:37

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470



From noreply@sourceforge.net  Wed Jun 19 16:26:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 19 Jun 2002 08:26:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-570678 ] CGIHTTPServer flushes read-only file.
Message-ID: <E17KhLh-00062c-00@usw-sf-web2.sourceforge.net>

Bugs item #570678, was opened at 2002-06-18 12:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=570678&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Tony Lownds (tonylownds)
>Assigned to: Jack Jansen (jackjansen)
Summary: CGIHTTPServer flushes read-only file.

Initial Comment:
On Mac OS X, flushing a file open only for reading
causing an IOError. That behavior matches what the
system's fflush man page describes:

ERRORS
     [EBADF]            Stream is not an open stream,
or, in the case of
                        fflush(), not a stream open for
writing.

CGIHTTPServer.py calls .flush on the read-only part of
it's socket before it forks and then quickly breaks.

The attached patch simply removes that line.
The bug is listed as Platform-specific because this
behavior does not appear under Linux (even though the
fflush man page on Linux lists the same EBADF error).



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 11:26

Message:
Logged In: YES 
user_id=6380

I thought the C standard supports fflush() on a stream open
for reading as a way to clear the buffer and reposition the
file descriptor to its logical position. Maybe I'm mistaken;
maybe the MacOS X stdio library is not standard-conforming.
But I think it's fine to take that flush() out here, because
(1) it's a socket, and (2) it's unbuffered.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-06-19 05:26

Message:
Logged In: YES 
user_id=45365

Apparently Guido is the one who put the self.rfile.flush() call in there, so he's probably also the person who knows whether it's a good idea to take it out again.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=570678&group_id=5470



From noreply@sourceforge.net  Wed Jun 19 16:29:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 19 Jun 2002 08:29:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-571167 ] glob() fails for network drive in cgi
Message-ID: <E17KhOu-0006XJ-00@usw-sf-web3.sourceforge.net>

Bugs item #571167, was opened at 2002-06-19 10:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571167&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Schuweiler (bshoe282)
Assigned to: Nobody/Anonymous (nobody)
Summary: glob() fails for network drive in cgi

Initial Comment:
glob.glob() does not work when globbing a network 
mapped drive while running as a cgi script.  The method 
works fine when run as a normal python script (even for 
mapped drives), but does not work when run from a 
browser as a cgi script.  The glob returns an empty list 
as if the drive just isn't there.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571167&group_id=5470



From noreply@sourceforge.net  Wed Jun 19 16:31:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 19 Jun 2002 08:31:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-571167 ] glob() fails for network drive in cgi
Message-ID: <E17KhQT-0006YP-00@usw-sf-web3.sourceforge.net>

Bugs item #571167, was opened at 2002-06-19 10:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571167&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
>Priority: 7
Submitted By: Brian Schuweiler (bshoe282)
Assigned to: Nobody/Anonymous (nobody)
Summary: glob() fails for network drive in cgi

Initial Comment:
glob.glob() does not work when globbing a network 
mapped drive while running as a cgi script.  The method 
works fine when run as a normal python script (even for 
mapped drives), but does not work when run from a 
browser as a cgi script.  The glob returns an empty list 
as if the drive just isn't there.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571167&group_id=5470



From noreply@sourceforge.net  Wed Jun 19 19:13:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 19 Jun 2002 11:13:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-569257 ] __slots__ attribute and private variable
Message-ID: <E17KjxN-0001IA-00@usw-sf-web3.sourceforge.net>

Bugs item #569257, was opened at 2002-06-14 19:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470

Category: Type/class unification
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Keyton Weissinger (keytonw)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: __slots__ attribute and private variable

Initial Comment:
If you use a __slots__ class variable and include a 
variable with a double underscore as the first two 
characters, that variable is NOT private as would be the 
case for any other variable whose name begins with a 
double underscore.

If this is by design, then it should be in the docs. If it is 
not and represents a bug, it needs to be investigated.

Thank you!!!

Keyton Weissinger

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-19 13:13

Message:
Logged In: YES 
user_id=80475

Added patch.

Note, the patch would be much shorter if mangle() in 
compile.c were made non-static.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-17 23:19

Message:
Logged In: YES 
user_id=80475

Agree that it is a bug.
Working on a patch.

----------------------------------------------------------------------

Comment By: Keyton Weissinger (keytonw)
Date: 2002-06-14 22:31

Message:
Logged In: YES 
user_id=396481

Also, this issue prevents you from using the combination of 
property() and __slots__ which would be powerful, as 
attempting to use them would make __property_name__ a 
legal public variable, no?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470



From noreply@sourceforge.net  Wed Jun 19 20:30:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 19 Jun 2002 12:30:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-569257 ] __slots__ attribute and private variable
Message-ID: <E17KlA2-0002rq-00@usw-sf-web3.sourceforge.net>

Bugs item #569257, was opened at 2002-06-14 20:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470

Category: Type/class unification
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Keyton Weissinger (keytonw)
Assigned to: Guido van Rossum (gvanrossum)
Summary: __slots__ attribute and private variable

Initial Comment:
If you use a __slots__ class variable and include a 
variable with a double underscore as the first two 
characters, that variable is NOT private as would be the 
case for any other variable whose name begins with a 
double underscore.

If this is by design, then it should be in the docs. If it is 
not and represents a bug, it needs to be investigated.

Thank you!!!

Keyton Weissinger

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 15:30

Message:
Logged In: YES 
user_id=6380

rhettinger: I haven't seen the patch, but I agree this ought
to be fixed -- in Python 2.3, as a new feature though. Why
don't you make munge() a private global (with an _Py prefix
to its name).

keytonw: I have no idea what you meant in your comment about
properties and slots and __property_name__. Can you
elaborate that?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-19 14:13

Message:
Logged In: YES 
user_id=80475

Added patch.

Note, the patch would be much shorter if mangle() in 
compile.c were made non-static.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-18 00:19

Message:
Logged In: YES 
user_id=80475

Agree that it is a bug.
Working on a patch.

----------------------------------------------------------------------

Comment By: Keyton Weissinger (keytonw)
Date: 2002-06-14 23:31

Message:
Logged In: YES 
user_id=396481

Also, this issue prevents you from using the combination of 
property() and __slots__ which would be powerful, as 
attempting to use them would make __property_name__ a 
legal public variable, no?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470



From noreply@sourceforge.net  Wed Jun 19 22:22:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 19 Jun 2002 14:22:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-571334 ] imaplib fetch is broken
Message-ID: <E17KmuS-0005Wt-00@usw-sf-web2.sourceforge.net>

Bugs item #571334, was opened at 2002-06-19 16:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571334&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Goerzen (jgoerzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: imaplib fetch is broken

Initial Comment:
This bug is 100% reproducible in Python 2.2.1 and the 
imaplib.py from Python's CVS tree. 
 
They'll send the message body in this form: 
{100} 
Headers here, body here, (100 characters worth) 
 
This is specified in RFC2060 secion 4.3.  imaplib's fetch 
chokes on 
"unexpected data" in the response. 
 
imaplib should receive this prefix-quoted string properly 
and return it in a 
non-quoted fashion. 
 
As it is, it is totally impossible to read messages from 
most imap servers. 
 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571334&group_id=5470



From noreply@sourceforge.net  Wed Jun 19 22:49:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 19 Jun 2002 14:49:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-571343 ] Mixing framework and static Pythons
Message-ID: <E17KnKN-0005zh-00@usw-sf-web2.sourceforge.net>

Bugs item #571343, was opened at 2002-06-19 23:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571343&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Mixing framework and static Pythons

Initial Comment:
We need to check that (on OS X) the error message you get when you attempt to load an extension module in the "wrong" Python (i.e. an extension module built for a static Python into a framework python or vice versa) is of a form understandable to naive users, and not of the "undefined external: foobar" variety. As the situation of having both Pythons on your system may well become commonplace this needs to be addressed in 2.2.X too.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571343&group_id=5470



From noreply@sourceforge.net  Wed Jun 19 22:57:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 19 Jun 2002 14:57:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect
Message-ID: <E17KnRk-0004m6-00@usw-sf-web1.sourceforge.net>

Bugs item #549151, was opened at 2002-04-26 17:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Jeremy Hylton (jhylton)
Summary: urllib2 POSTs on redirect

Initial Comment:

urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the 
POST method on redirect, contrary to RFC1945 section 9.3:

> 9.3  Redirection 3xx
> 
>    This class of status code indicates that further action needs to be
>    taken by the user agent in order to fulfill the request. The action
>    required may be carried out by the user agent without interaction
>    with the user if and only if the method used in the subsequent
>    request is GET or HEAD. A user agent should never automatically
>    redirect a request more than 5 times, since such redirections usually
>    indicate an infinite loop.

Can be fixed in HTTPRedirectHandler.http_error_302 by replacing
        new = Request(newurl, req.get_data())

with
        new = Request(newurl)

so that GET is done on redirect instead of POST.

I suppose the limit of 10 in the same function should be changed to 5, also.


----------------------------------------------------------------------

>Comment By: John J Lee (jjlee)
Date: 2002-06-19 22:56

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-06 22:25

Message:
Logged In: YES 
user_id=261020

Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I
check, I see that even RFC 1945 (HTTP/1.0) has a whole set of
restrictions on 30x for particular values of x which I missed
completely.

I guess it should do what Guido suggested -- report an error if a
POST is redirected -- until somebody gets time to do it properly.
I won't have time for a couple of months, but if nobody has done
it by then I'll upload a patch.


John


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-06 16:09

Message:
Logged In: YES 
user_id=31392

I think you need to review the current HTTP spec -- RFC 2616
-- and look at the section on redirection (10.3).  I think
urllib2 could improve its handling of redirection, but the
behavior you describe from lynx sounds incorrect.  I'd be
happy to review a patch the implemented the current spec.

Also, RFC 2616 removes the recommendation of a 5 redirect limit.




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 19:10

Message:
Logged In: YES 
user_id=6380

Fair enough. I'll leve it to Jeremy to review the proposed
fix. (Note that he's busy though.)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-29 17:29

Message:
Logged In: YES 
user_id=261020

I don't see why it shouldn't substitue a GET.  That certainly seems to be
the standard practice (well, at least that's what lynx does), and in the case
of the only site where I've encountered redirects on POST, the redirect URL
contains urlencoded stuff, so it clearly expects the user-agent to do a GET.
The site would break if this didn't happen, so I guess Netscape and IE must
do the same thing.

Clearly the RFC *does* allow this, though it doesn't require it (or specify
what should happen here in any way other than to say that a POST is not
allowed, in fact).  Since it's standard practice and allowed by the RFC, I
don't think it should be an error.

John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 01:53

Message:
Logged In: YES 
user_id=6380

Hm, the way I interpret the text you quote, if the original
request is  a POST, it should probably not substitute a GET
but report the error.

Assigning to Jeremy since it's his module.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-28 17:21

Message:
Logged In: YES 
user_id=261020

1. Bug is also in 2.2 branch

2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers:

new = Request(newurl, headers=req.headers)

3. I guess 10 should be replaced with 4, not 5.


John


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470



From noreply@sourceforge.net  Wed Jun 19 22:57:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 19 Jun 2002 14:57:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect
Message-ID: <E17KnRl-0004mQ-00@usw-sf-web1.sourceforge.net>

Bugs item #549151, was opened at 2002-04-26 17:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Jeremy Hylton (jhylton)
Summary: urllib2 POSTs on redirect

Initial Comment:

urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the 
POST method on redirect, contrary to RFC1945 section 9.3:

> 9.3  Redirection 3xx
> 
>    This class of status code indicates that further action needs to be
>    taken by the user agent in order to fulfill the request. The action
>    required may be carried out by the user agent without interaction
>    with the user if and only if the method used in the subsequent
>    request is GET or HEAD. A user agent should never automatically
>    redirect a request more than 5 times, since such redirections usually
>    indicate an infinite loop.

Can be fixed in HTTPRedirectHandler.http_error_302 by replacing
        new = Request(newurl, req.get_data())

with
        new = Request(newurl)

so that GET is done on redirect instead of POST.

I suppose the limit of 10 in the same function should be changed to 5, also.


----------------------------------------------------------------------

>Comment By: John J Lee (jjlee)
Date: 2002-06-19 22:57

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-19 22:56

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-06 22:25

Message:
Logged In: YES 
user_id=261020

Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I
check, I see that even RFC 1945 (HTTP/1.0) has a whole set of
restrictions on 30x for particular values of x which I missed
completely.

I guess it should do what Guido suggested -- report an error if a
POST is redirected -- until somebody gets time to do it properly.
I won't have time for a couple of months, but if nobody has done
it by then I'll upload a patch.


John


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-06 16:09

Message:
Logged In: YES 
user_id=31392

I think you need to review the current HTTP spec -- RFC 2616
-- and look at the section on redirection (10.3).  I think
urllib2 could improve its handling of redirection, but the
behavior you describe from lynx sounds incorrect.  I'd be
happy to review a patch the implemented the current spec.

Also, RFC 2616 removes the recommendation of a 5 redirect limit.




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 19:10

Message:
Logged In: YES 
user_id=6380

Fair enough. I'll leve it to Jeremy to review the proposed
fix. (Note that he's busy though.)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-29 17:29

Message:
Logged In: YES 
user_id=261020

I don't see why it shouldn't substitue a GET.  That certainly seems to be
the standard practice (well, at least that's what lynx does), and in the case
of the only site where I've encountered redirects on POST, the redirect URL
contains urlencoded stuff, so it clearly expects the user-agent to do a GET.
The site would break if this didn't happen, so I guess Netscape and IE must
do the same thing.

Clearly the RFC *does* allow this, though it doesn't require it (or specify
what should happen here in any way other than to say that a POST is not
allowed, in fact).  Since it's standard practice and allowed by the RFC, I
don't think it should be an error.

John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 01:53

Message:
Logged In: YES 
user_id=6380

Hm, the way I interpret the text you quote, if the original
request is  a POST, it should probably not substitute a GET
but report the error.

Assigning to Jeremy since it's his module.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-28 17:21

Message:
Logged In: YES 
user_id=261020

1. Bug is also in 2.2 branch

2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers:

new = Request(newurl, headers=req.headers)

3. I guess 10 should be replaced with 4, not 5.


John


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 00:45:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 19 Jun 2002 16:45:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-571382 ] Numeric Literal Anomoly
Message-ID: <E17Kp8l-0007r9-00@usw-sf-web2.sourceforge.net>

Bugs item #571382, was opened at 2002-06-19 16:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571382&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Otto J. A. Smith (ottojas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Numeric Literal Anomoly

Initial Comment:
I hope I am not beating a dead horse.  This might have 
been dealt with in the past, although I failed to find any 
reference to it in a search.

A string representation of a numeric literal is evaluated
differently by "int" and "string.atoi" than by "eval".  The 
functions "int" and "string.atoi" treat the leading zero as
a leading zero in a decimal numeric literal, while "eval" 
treats it as an indication of the literal representing an octal 
value.

Consider the string "077"

>>> 0077
63
>>> eval('077')
63
>>> int('0077')
77
>>> string.atoi("0077")
77

It is probably not possible to change the behavior of "int"
or "string.atoi" due to historic reasons.  I would suggest 
adding a method to the string class that does conversions
from hex and octal string literals correctly.

This may seem like a minor problem but should be done for
the following reasons.

1.  Python is a remarkably regular language and my 
favorite for that reason among others.  The current 
behavior deviates from what one might rationally expect 
and is a blemish (although minor) on an otherwise beutiful 
language.

2.  The only quick way to evaluate a hex or octal numeric 
constant that comes from an outside source, such as the 
web, is with "eval".  This poses security risks.  The use of 
custom programs and/or safe-eval seems like overkill and 
one would expect a builti n safe way to convert from any 
string representing a numeric literal to the internal 
representation.

One would expect the functions "oct" and "int" to allow 
conversions back and forth.   Here is what really happens.

>>> oct(77)
'0115'
>>> int(oct(77))
115
>>> oct(int(oct(77)))
'0163'
>>> int(oct(int(oct(77))))
163
>>> oct(int(oct(int(oct(77)))))
'0243'
>>> int(oct(int(oct(int(oct(77))))))
243
>>> oct(int(oct(int(oct(int(oct(77)))))))
'0363'

Although the above is intriguing, it is not really a 
language feature, nor does it generate errors as would
occur with the use of "hex" instead of "oct".

I would suggest the addition of a new method with a new 
name. (maybe "aint") to the string class., a method that 
would evaluate all the forms of integer numeric literals
with the same behavior as "eval".

Regards
Otto



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571382&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 01:12:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 19 Jun 2002 17:12:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-571382 ] Numeric Literal Anomoly
Message-ID: <E17KpZA-0007Hr-00@usw-sf-web3.sourceforge.net>

Bugs item #571382, was opened at 2002-06-19 19:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571382&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Otto J. A. Smith (ottojas)
>Assigned to: Tim Peters (tim_one)
Summary: Numeric Literal Anomoly

Initial Comment:
I hope I am not beating a dead horse.  This might have 
been dealt with in the past, although I failed to find any 
reference to it in a search.

A string representation of a numeric literal is evaluated
differently by "int" and "string.atoi" than by "eval".  The 
functions "int" and "string.atoi" treat the leading zero as
a leading zero in a decimal numeric literal, while "eval" 
treats it as an indication of the literal representing an octal 
value.

Consider the string "077"

>>> 0077
63
>>> eval('077')
63
>>> int('0077')
77
>>> string.atoi("0077")
77

It is probably not possible to change the behavior of "int"
or "string.atoi" due to historic reasons.  I would suggest 
adding a method to the string class that does conversions
from hex and octal string literals correctly.

This may seem like a minor problem but should be done for
the following reasons.

1.  Python is a remarkably regular language and my 
favorite for that reason among others.  The current 
behavior deviates from what one might rationally expect 
and is a blemish (although minor) on an otherwise beutiful 
language.

2.  The only quick way to evaluate a hex or octal numeric 
constant that comes from an outside source, such as the 
web, is with "eval".  This poses security risks.  The use of 
custom programs and/or safe-eval seems like overkill and 
one would expect a builti n safe way to convert from any 
string representing a numeric literal to the internal 
representation.

One would expect the functions "oct" and "int" to allow 
conversions back and forth.   Here is what really happens.

>>> oct(77)
'0115'
>>> int(oct(77))
115
>>> oct(int(oct(77)))
'0163'
>>> int(oct(int(oct(77))))
163
>>> oct(int(oct(int(oct(77)))))
'0243'
>>> int(oct(int(oct(int(oct(77))))))
243
>>> oct(int(oct(int(oct(int(oct(77)))))))
'0363'

Although the above is intriguing, it is not really a 
language feature, nor does it generate errors as would
occur with the use of "hex" instead of "oct".

I would suggest the addition of a new method with a new 
name. (maybe "aint") to the string class., a method that 
would evaluate all the forms of integer numeric literals
with the same behavior as "eval".

Regards
Otto



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-06-19 20:12

Message:
Logged In: YES 
user_id=31435

Read the docs for the int() function.  Is there something you 
want that you can't already do by passing int an optional 
base argument of 0?:

>>> int('077', 0)
63
>>> int('0x77', 0)
119
>>> int('77', 0)
77
>>>

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571382&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 01:57:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 19 Jun 2002 17:57:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect
Message-ID: <E17KqGR-0007ph-00@usw-sf-web3.sourceforge.net>

Bugs item #549151, was opened at 2002-04-26 12:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Jeremy Hylton (jhylton)
Summary: urllib2 POSTs on redirect

Initial Comment:

urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the 
POST method on redirect, contrary to RFC1945 section 9.3:

> 9.3  Redirection 3xx
> 
>    This class of status code indicates that further action needs to be
>    taken by the user agent in order to fulfill the request. The action
>    required may be carried out by the user agent without interaction
>    with the user if and only if the method used in the subsequent
>    request is GET or HEAD. A user agent should never automatically
>    redirect a request more than 5 times, since such redirections usually
>    indicate an infinite loop.

Can be fixed in HTTPRedirectHandler.http_error_302 by replacing
        new = Request(newurl, req.get_data())

with
        new = Request(newurl)

so that GET is done on redirect instead of POST.

I suppose the limit of 10 in the same function should be changed to 5, also.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 20:57

Message:
Logged In: YES 
user_id=6380

Hm, I thought that 307 should be treated differently than
303. In particular, a 307 response to POST should cause the
POST to be redirected. And I'm not sure about what a 301
response to POST should do.

(In the mean time I have been convinced that changing POST
to GET on 302 is the best thing to do given that most
browsers do that. The old urllib.py should be fixed too.)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-19 17:57

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-19 17:56

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-06 17:25

Message:
Logged In: YES 
user_id=261020

Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I
check, I see that even RFC 1945 (HTTP/1.0) has a whole set of
restrictions on 30x for particular values of x which I missed
completely.

I guess it should do what Guido suggested -- report an error if a
POST is redirected -- until somebody gets time to do it properly.
I won't have time for a couple of months, but if nobody has done
it by then I'll upload a patch.


John


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-06 11:09

Message:
Logged In: YES 
user_id=31392

I think you need to review the current HTTP spec -- RFC 2616
-- and look at the section on redirection (10.3).  I think
urllib2 could improve its handling of redirection, but the
behavior you describe from lynx sounds incorrect.  I'd be
happy to review a patch the implemented the current spec.

Also, RFC 2616 removes the recommendation of a 5 redirect limit.




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 14:10

Message:
Logged In: YES 
user_id=6380

Fair enough. I'll leve it to Jeremy to review the proposed
fix. (Note that he's busy though.)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-29 12:29

Message:
Logged In: YES 
user_id=261020

I don't see why it shouldn't substitue a GET.  That certainly seems to be
the standard practice (well, at least that's what lynx does), and in the case
of the only site where I've encountered redirects on POST, the redirect URL
contains urlencoded stuff, so it clearly expects the user-agent to do a GET.
The site would break if this didn't happen, so I guess Netscape and IE must
do the same thing.

Clearly the RFC *does* allow this, though it doesn't require it (or specify
what should happen here in any way other than to say that a POST is not
allowed, in fact).  Since it's standard practice and allowed by the RFC, I
don't think it should be an error.

John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-28 20:53

Message:
Logged In: YES 
user_id=6380

Hm, the way I interpret the text you quote, if the original
request is  a POST, it should probably not substitute a GET
but report the error.

Assigning to Jeremy since it's his module.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-28 12:21

Message:
Logged In: YES 
user_id=261020

1. Bug is also in 2.2 branch

2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers:

new = Request(newurl, headers=req.headers)

3. I guess 10 should be replaced with 4, not 5.


John


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 03:51:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 19 Jun 2002 19:51:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-569257 ] __slots__ attribute and private variable
Message-ID: <E17Ks35-0002OQ-00@usw-sf-web2.sourceforge.net>

Bugs item #569257, was opened at 2002-06-14 19:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Keyton Weissinger (keytonw)
Assigned to: Guido van Rossum (gvanrossum)
Summary: __slots__ attribute and private variable

Initial Comment:
If you use a __slots__ class variable and include a 
variable with a double underscore as the first two 
characters, that variable is NOT private as would be the 
case for any other variable whose name begins with a 
double underscore.

If this is by design, then it should be in the docs. If it is 
not and represents a bug, it needs to be investigated.

Thank you!!!

Keyton Weissinger

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-19 21:51

Message:
Logged In: YES 
user_id=80475

Done.  New patch attached. Okay to commit?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 14:30

Message:
Logged In: YES 
user_id=6380

rhettinger: I haven't seen the patch, but I agree this ought
to be fixed -- in Python 2.3, as a new feature though. Why
don't you make munge() a private global (with an _Py prefix
to its name).

keytonw: I have no idea what you meant in your comment about
properties and slots and __property_name__. Can you
elaborate that?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-19 13:13

Message:
Logged In: YES 
user_id=80475

Added patch.

Note, the patch would be much shorter if mangle() in 
compile.c were made non-static.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-17 23:19

Message:
Logged In: YES 
user_id=80475

Agree that it is a bug.
Working on a patch.

----------------------------------------------------------------------

Comment By: Keyton Weissinger (keytonw)
Date: 2002-06-14 22:31

Message:
Logged In: YES 
user_id=396481

Also, this issue prevents you from using the combination of 
property() and __slots__ which would be powerful, as 
attempting to use them would make __property_name__ a 
legal public variable, no?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 04:04:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 19 Jun 2002 20:04:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-569257 ] __slots__ attribute and private variable
Message-ID: <E17KsF8-0001ZO-00@usw-sf-web3.sourceforge.net>

Bugs item #569257, was opened at 2002-06-14 20:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Keyton Weissinger (keytonw)
Assigned to: Guido van Rossum (gvanrossum)
Summary: __slots__ attribute and private variable

Initial Comment:
If you use a __slots__ class variable and include a 
variable with a double underscore as the first two 
characters, that variable is NOT private as would be the 
case for any other variable whose name begins with a 
double underscore.

If this is by design, then it should be in the docs. If it is 
not and represents a bug, it needs to be investigated.

Thank you!!!

Keyton Weissinger

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 23:04

Message:
Logged In: YES 
user_id=6380

Eh, no, I think there's a bug. The slots variable is made a
tuple by calling PySequence_Tuple(). If it was already a
tuple, this adds a reference to the existing tuple. And
later you're modifying it in-place! This gives the
"impossible" semantics of the following example:

>>> t = ("__foo", "__bar")
>>> class C(object):
      __slots__ = t
    
>>> t
('_C__foo', '_C__bar')
>>> 

I'm afraid you'll have to clone the tuple when you find its
refcount is >1.

Also, please make lines < 79 chars. And a readability
recommendation: if an if statement's expression is several
lines long, don't hide the '{' at the end of a line, but put
it at the beginning of the next, under the if: e.g.

    if (blah, blah, blah,
        blah, blah, blah,
        blah, blah, blah)
    {
        blah;
        blah;
    }

Barry taught me this trick. :-)

Also, I think it's wrong to #include "compile.h" in
Python.h, it exposes too many internals... Better declare
the _Py_Munge() prototype somewhere else (directly in
Python.h would be fine).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-19 22:51

Message:
Logged In: YES 
user_id=80475

Done.  New patch attached. Okay to commit?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 15:30

Message:
Logged In: YES 
user_id=6380

rhettinger: I haven't seen the patch, but I agree this ought
to be fixed -- in Python 2.3, as a new feature though. Why
don't you make munge() a private global (with an _Py prefix
to its name).

keytonw: I have no idea what you meant in your comment about
properties and slots and __property_name__. Can you
elaborate that?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-19 14:13

Message:
Logged In: YES 
user_id=80475

Added patch.

Note, the patch would be much shorter if mangle() in 
compile.c were made non-static.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-18 00:19

Message:
Logged In: YES 
user_id=80475

Agree that it is a bug.
Working on a patch.

----------------------------------------------------------------------

Comment By: Keyton Weissinger (keytonw)
Date: 2002-06-14 23:31

Message:
Logged In: YES 
user_id=396481

Also, this issue prevents you from using the combination of 
property() and __slots__ which would be powerful, as 
attempting to use them would make __property_name__ a 
legal public variable, no?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 05:09:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 19 Jun 2002 21:09:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-532467 ] 6.9 The raise statement is confusing
Message-ID: <E17KtGI-000605-00@usw-sf-web4.sourceforge.net>

Bugs item #532467, was opened at 2002-03-20 08:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532467&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
>Priority: 7
Submitted By: Patrick K. O'Brien (pobrien)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: 6.9 The raise statement is confusing

Initial Comment:
The description supplied for "6.9 The raise statement" 
is confusing. In particular, it starts by explaining 
the intent of each "expresssion" and midway switches 
to "object" instead of expression. In particular, I 
can't make heads or tails out of the following passage:

"If the first object is a string, it then raises the 
exception identified by the first object, with the 
second one (or None) as its parameter. If the first 
object is a class or instance, it raises the exception 
identified by the class of the instance determined in 
the previous step, with the instance as its parameter."

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-20 00:09

Message:
Logged In: YES 
user_id=3066

Raymond is still waiting, so bumping to 7 so I notice it in
the morning (when I'm not really asleep).

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-29 15:45

Message:
Logged In: YES 
user_id=3066

Bumped priority since Raymond is waiting for my review.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-18 21:25

Message:
Logged In: YES 
user_id=80475

Thanks Patrick.

Since I'm the new guy, I'll defer additional changes to 
Fred.  My patch style is to make the least invasive change 
that improves clarity and accuracy.  

Also, this may be a case where additional wording, even if 
informative and accurate, may detract from a strong 
understanding of how raise works.  

This section's cyclomatic complexity (nested if/elif/else 
paths) already impinges its understandability.

----------------------------------------------------------------------

Comment By: Patrick K. O'Brien (pobrien)
Date: 2002-05-16 10:34

Message:
Logged In: YES 
user_id=179604

Raymond, I really appreciate your patches. The big patch is 
terrific and gets my vote. I do have one more request for 
clarification in what you wrote. You say:

"If the first expression is a class object, it raises the 
exception identified by the class of an instance determined 
by the second expression.  If the second expression is an 
instance, that instance is used."

So we're talking about the form: raise class, instance

What I'm picturing is a situation where the second 
expression is an instance of a class other than the class 
object used as the first expression. Is this allowed, 
disallowed, allowed but nonsensical or allowed because it 
offers some practical benefit that I'm just not grasping?

I found and read the essay on "Standard Exception Classes 
in Python 1.5" 
(http://www.python.org/doc/essays/stdexceptions.html) and I 
can see that much was done to maintain backward 
compatibility. and apparently the "raise class, instance" 
form goes back quite a ways. Is this just a wart to be 
avoided? I'm probably expecting too much to expect the 
language reference to distinguish between what is strictly 
allowed vs. why it is allowed and whether it should even be 
used at all. It's just that the more I dug into this the 
more confused I became. I think I'm understanding the 
situation now.

In any case, make of this what you will. The bottom line is 
that your batch is definitely an improvement and I greatly 
appreciate your time and effort on this. Thanks.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-16 00:10

Message:
Logged In: YES 
user_id=80475

Attached two alternative patches.

The first makes minimal changes to achieve a clear and 
consistent use of "objects" versus "expressions".

The second alternative re-paragraphs the text and uses 
parallel sentence contruction to provide (IMHO) 
greater clarity without getting a headache reading it.

If accepted, please re-assign to Raymond for a commit to 
2.3 and to release22-maint.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532467&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 05:11:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 19 Jun 2002 21:11:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-569257 ] __slots__ attribute and private variable
Message-ID: <E17KtIT-000625-00@usw-sf-web4.sourceforge.net>

Bugs item #569257, was opened at 2002-06-14 20:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Keyton Weissinger (keytonw)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: __slots__ attribute and private variable

Initial Comment:
If you use a __slots__ class variable and include a 
variable with a double underscore as the first two 
characters, that variable is NOT private as would be the 
case for any other variable whose name begins with a 
double underscore.

If this is by design, then it should be in the docs. If it is 
not and represents a bug, it needs to be investigated.

Thank you!!!

Keyton Weissinger

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 23:04

Message:
Logged In: YES 
user_id=6380

Eh, no, I think there's a bug. The slots variable is made a
tuple by calling PySequence_Tuple(). If it was already a
tuple, this adds a reference to the existing tuple. And
later you're modifying it in-place! This gives the
"impossible" semantics of the following example:

>>> t = ("__foo", "__bar")
>>> class C(object):
      __slots__ = t
    
>>> t
('_C__foo', '_C__bar')
>>> 

I'm afraid you'll have to clone the tuple when you find its
refcount is >1.

Also, please make lines < 79 chars. And a readability
recommendation: if an if statement's expression is several
lines long, don't hide the '{' at the end of a line, but put
it at the beginning of the next, under the if: e.g.

    if (blah, blah, blah,
        blah, blah, blah,
        blah, blah, blah)
    {
        blah;
        blah;
    }

Barry taught me this trick. :-)

Also, I think it's wrong to #include "compile.h" in
Python.h, it exposes too many internals... Better declare
the _Py_Munge() prototype somewhere else (directly in
Python.h would be fine).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-19 22:51

Message:
Logged In: YES 
user_id=80475

Done.  New patch attached. Okay to commit?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 15:30

Message:
Logged In: YES 
user_id=6380

rhettinger: I haven't seen the patch, but I agree this ought
to be fixed -- in Python 2.3, as a new feature though. Why
don't you make munge() a private global (with an _Py prefix
to its name).

keytonw: I have no idea what you meant in your comment about
properties and slots and __property_name__. Can you
elaborate that?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-19 14:13

Message:
Logged In: YES 
user_id=80475

Added patch.

Note, the patch would be much shorter if mangle() in 
compile.c were made non-static.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-18 00:19

Message:
Logged In: YES 
user_id=80475

Agree that it is a bug.
Working on a patch.

----------------------------------------------------------------------

Comment By: Keyton Weissinger (keytonw)
Date: 2002-06-14 23:31

Message:
Logged In: YES 
user_id=396481

Also, this issue prevents you from using the combination of 
property() and __slots__ which would be powerful, as 
attempting to use them would make __property_name__ a 
legal public variable, no?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 06:19:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 19 Jun 2002 22:19:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-569257 ] __slots__ attribute and private variable
Message-ID: <E17KuLt-00032P-00@usw-sf-web1.sourceforge.net>

Bugs item #569257, was opened at 2002-06-14 19:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Keyton Weissinger (keytonw)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: __slots__ attribute and private variable

Initial Comment:
If you use a __slots__ class variable and include a 
variable with a double underscore as the first two 
characters, that variable is NOT private as would be the 
case for any other variable whose name begins with a 
double underscore.

If this is by design, then it should be in the docs. If it is 
not and represents a bug, it needs to be investigated.

Thank you!!!

Keyton Weissinger

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-20 00:19

Message:
Logged In: YES 
user_id=80475

Done.
Revised patch attached.
No more modifying immutables for me!

Thanks for the comments -- they really help me get to the 
root of a problem, get it fixed, and learn something for the 
next bugfix.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 22:04

Message:
Logged In: YES 
user_id=6380

Eh, no, I think there's a bug. The slots variable is made a
tuple by calling PySequence_Tuple(). If it was already a
tuple, this adds a reference to the existing tuple. And
later you're modifying it in-place! This gives the
"impossible" semantics of the following example:

>>> t = ("__foo", "__bar")
>>> class C(object):
      __slots__ = t
    
>>> t
('_C__foo', '_C__bar')
>>> 

I'm afraid you'll have to clone the tuple when you find its
refcount is >1.

Also, please make lines < 79 chars. And a readability
recommendation: if an if statement's expression is several
lines long, don't hide the '{' at the end of a line, but put
it at the beginning of the next, under the if: e.g.

    if (blah, blah, blah,
        blah, blah, blah,
        blah, blah, blah)
    {
        blah;
        blah;
    }

Barry taught me this trick. :-)

Also, I think it's wrong to #include "compile.h" in
Python.h, it exposes too many internals... Better declare
the _Py_Munge() prototype somewhere else (directly in
Python.h would be fine).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-19 21:51

Message:
Logged In: YES 
user_id=80475

Done.  New patch attached. Okay to commit?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 14:30

Message:
Logged In: YES 
user_id=6380

rhettinger: I haven't seen the patch, but I agree this ought
to be fixed -- in Python 2.3, as a new feature though. Why
don't you make munge() a private global (with an _Py prefix
to its name).

keytonw: I have no idea what you meant in your comment about
properties and slots and __property_name__. Can you
elaborate that?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-19 13:13

Message:
Logged In: YES 
user_id=80475

Added patch.

Note, the patch would be much shorter if mangle() in 
compile.c were made non-static.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-17 23:19

Message:
Logged In: YES 
user_id=80475

Agree that it is a bug.
Working on a patch.

----------------------------------------------------------------------

Comment By: Keyton Weissinger (keytonw)
Date: 2002-06-14 22:31

Message:
Logged In: YES 
user_id=396481

Also, this issue prevents you from using the combination of 
property() and __slots__ which would be powerful, as 
attempting to use them would make __property_name__ a 
legal public variable, no?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 07:19:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 19 Jun 2002 23:19:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-563530 ] Missing operator docs
Message-ID: <E17KvIN-0007tp-00@usw-sf-web4.sourceforge.net>

Bugs item #563530, was opened at 2002-06-02 08:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563530&group_id=5470

Category: Documentation
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Missing operator docs

Initial Comment:
I see no mention of the following at 
http://www.python.org/dev/doc/devel/ref/numeric-
types.html:

__rfloordiv__
__rtruediv__
__ifloordiv__
__itruediv__


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-20 01:19

Message:
Logged In: YES 
user_id=80475

Easy fix.
Committed ref3.tex ver 1.92 and 1.82.4.4
Closing bug.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-17 23:20

Message:
Logged In: YES 
user_id=80475

Will patch and re-assign back to Fred.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563530&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 07:22:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 19 Jun 2002 23:22:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-560064 ] inconsistent behavior of __getslice__
Message-ID: <E17KvLI-0007w9-00@usw-sf-web4.sourceforge.net>

Bugs item #560064, was opened at 2002-05-24 06:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560064&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Cesar Douady (douady)
>Assigned to: Nobody/Anonymous (nobody)
Summary: inconsistent behavior of __getslice__

Initial Comment:
The following trace shows what I mean:
>>> help(str.__getslice__)
Help on wrapper_descriptor:

__getslice__(...)
    x.__getslice__(i, j) <==> x[i:j]
>>> 'ab'[-1]
'b'
>>> 'ab'.__getitem__(-1)
'b'
>>> 'ab'[-2:-1]
'a'
>>> 'ab'.__getslice__(-2,-1)
''

that is, __getslice__ does not add the length of the
sequence to its arguments when they are negative as
indexing with [:] does.
This contradicts the docstring which says __getslice__
is equivalent to indexing.
The same behavior applies to lists.

Note that __getitem__ does it right.

This bug may be linked to bug 473985 ('str, __getitem__
and slices') but should be much easier to fix.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 14:23

Message:
Logged In: YES 
user_id=6380

This should NOT be fixed this way, Raymond!

The docs are (subtly) wrong. For historical reasons, 
__getslice__ expects the Python VM to do the adjustment of 
negative indices. If you did another adjustment inside getslice, 
certain indices would start behaving differently (e.g. s[:-5] 
where len(s)==3).

Maybe the docstring should be fixed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-24 07:58

Message:
Logged In: YES 
user_id=80475

Tim,  I attached a tiny patch which fixes the behavior for 
strings.  I've also tried out the same change in listobject.c 
and unicodeobject.c.  Is this the right this to do or are 
there more subtleties to this than meet the eye?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560064&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 08:35:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 00:35:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-546434 ] buffer slice type inconsistant
Message-ID: <E17KwU2-0000fy-00@usw-sf-web4.sourceforge.net>

Bugs item #546434, was opened at 2002-04-20 02:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546434&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Donald Wallace Rouse II (dwr2)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: buffer slice type inconsistant

Initial Comment:
The type of a buffer slice is either 'buffer' 
or 'str', depending on the slice parameters.
If the slice encompasses the entire buffer, the buffer 
itself is returned.
Otherwise, a string is returned.
Here is a sample session:
--------------------------
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
IDLE 0.8 -- press F1 for help
>>> a="0123456789"
>>> b = buffer(a, 1, 8)
>>> b
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[:]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[:8]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[2:4]
'34'
>>> b[5]
'6'
>>> c = buffer(a, 4, 1)
>>> c
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C8, size 
1 at 0x00AAA370>
>>> c[0]
'4'
>>> c[0:1]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C8, size 
1 at 0x00AAA370>
--------------------------
Either b[:] should produce a string, or, more 
preferably, b[x:y] should be equivalent to buffer(b, 
x, y), and c[0] should be equivalent to buffer(c, 0, 
1).
The reason that the types should be similar is because 
if a buffer is passed to a function that's checking 
for strings, the function should always fail or always 
succeed.

This is especially important because types.BufferType 
isn't in the types.StringTypes list, so the 
expression "type(b) in types.StringTypes" will also 
behave inconsistantly.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-20 02:35

Message:
Logged In: YES 
user_id=80475

Added Py2.3 patch to make slicing and repetition always 
return a string.  Unsure if it is a 2.2 backport candidate.



----------------------------------------------------------------------

Comment By: Donald Wallace Rouse II (dwr2)
Date: 2002-04-20 02:36

Message:
Logged In: YES 
user_id=111611

Sorry about the formatting; the form wrapped the lines.
A slight correction:
  "b[x:y] should be equivalent to buffer(b, x, y)"
should be
"b[x:y] should be equivalent to buffer(b, x1, y1 - x1), 
where x1 == x if x is positive and len(b) + x if x is 
negative, and similarly for y and y1".

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546434&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 08:59:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 00:59:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-495978 ] It's the future for generators
Message-ID: <E17Kwqu-00014o-00@usw-sf-web4.sourceforge.net>

Bugs item #495978, was opened at 2001-12-21 17:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495978&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: It's the future for generators

Initial Comment:
"from __future__ import generators" should no longer 
be required in 2.3a1.  Such stmts should also be 
removed from the Python library (there's a script 
under Tools to automate this).

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-20 02:59

Message:
Logged In: YES 
user_id=80475

Can this be closed?
The library is free of from __future__ generators and the 
core doesn't require it now.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 17:18

Message:
Logged In: YES 
user_id=6380

It's not too late!  Neil hasn't checked it in yet.

Neil, would you be willing to change your patch so that it
disables the yield keyword using #ifdef rather than by
erasing all of the code?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 16:59

Message:
Logged In: YES 
user_id=31435

Na, you should read me as saying I don't know how to write 
the kinds of docs you want.  I didn't do the parser changes 
here, so if you think there's something predictable and 
useful to be said here, you're the one to say it.

Keeping at least one example around under an "#if 0" sounds 
like an excellent idea.  The last time I implemented a 
future gimmick, it was spread around in so many places that 
the only sane way to proceed was to search for "the other" 
future gimmick that happened to be implemented already.

But doing that kind of search again is the only sane way I 
know to get rid of the future-generator business now too.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 16:39

Message:
Logged In: YES 
user_id=6380

Actually, each time a future feature introduces a new
keyword that has to remain an identifier when the feature is
not enabled, almost *exactly* the same hacks have to be
applied to the parser. That's just how the parser works. I
would almost recommend keeping those changes around at all
times, just #ifdef'ed out or something.

The other stuff that feels like it's very similar each time
is the handling of the flags passed around between the
various passes of the code generator.

But I know it's hopeless to argue with you, so I'll let you
rediscover all that when you decide to finally implement the
braces feature. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 16:22

Message:
Logged In: YES 
user_id=31435

The internal future machinery has changed every time we've 
added a new future gimmick.  So there's really nothing to 
be said other than to scour the source code looking for now-
obsolete "stuff".  For example, it's possible that the 
kinds of parser changes made for "yield" will never happen 
again, and, even if they do, I think it's impossible to 
predict where and how the parser will need to be unchanged.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 16:13

Message:
Logged In: YES 
user_id=6380

There ought to be documentation on what to do when an
optional feature becomes mandatory. Maybe a block comment or
docstring in __future__.py?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 15:34

Message:
Logged In: YES 
user_id=31435

Neil, if you don't enjoy using the patch system for 
straightforward stuff like this, don't feel compelled to 
use it.  That is, just check it in.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 15:04

Message:
Logged In: YES 
user_id=35752

The attached patch removes the "yield is an optional keyword"
hacks from the parser.  It's not a complete fix for this
bug though.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495978&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 09:13:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 01:13:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-571334 ] imaplib fetch is broken
Message-ID: <E17Kx4g-0005mN-00@usw-sf-web1.sourceforge.net>

Bugs item #571334, was opened at 2002-06-19 21:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571334&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Goerzen (jgoerzen)
>Assigned to: Piers Lauder (pierslauder)
Summary: imaplib fetch is broken

Initial Comment:
This bug is 100% reproducible in Python 2.2.1 and the 
imaplib.py from Python's CVS tree. 
 
They'll send the message body in this form: 
{100} 
Headers here, body here, (100 characters worth) 
 
This is specified in RFC2060 secion 4.3.  imaplib's fetch 
chokes on 
"unexpected data" in the response. 
 
imaplib should receive this prefix-quoted string properly 
and return it in a 
non-quoted fashion. 
 
As it is, it is totally impossible to read messages from 
most imap servers. 
 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571334&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 09:46:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 01:46:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-571334 ] imaplib fetch is broken
Message-ID: <E17KxaB-0006Xc-00@usw-sf-web1.sourceforge.net>

Bugs item #571334, was opened at 2002-06-20 07:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571334&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Goerzen (jgoerzen)
Assigned to: Piers Lauder (pierslauder)
Summary: imaplib fetch is broken

Initial Comment:
This bug is 100% reproducible in Python 2.2.1 and the 
imaplib.py from Python's CVS tree. 
 
They'll send the message body in this form: 
{100} 
Headers here, body here, (100 characters worth) 
 
This is specified in RFC2060 secion 4.3.  imaplib's fetch 
chokes on 
"unexpected data" in the response. 
 
imaplib should receive this prefix-quoted string properly 
and return it in a 
non-quoted fashion. 
 
As it is, it is totally impossible to read messages from 
most imap servers. 
 

----------------------------------------------------------------------

>Comment By: Piers Lauder (pierslauder)
Date: 2002-06-20 18:46

Message:
Logged In: YES 
user_id=196212

I can't duplicate this.

The test code at the end of imaplib.py includes a FETCH
command which is returned as a literal by my imap server.

Perhaps you could run that test on your server and cut
and paste the response.

Run the test like this:
  python2.2 imaplib.py -d5 <imap_server_host_name>

>From which I get the following:
	...
 43:26.15 > KDP19 UID FETCH 19570 (FLAGS INTERNALDATE
RFC822.SIZE RFC822.HEADER RFC822.TEXT)
  43:26.46 < * 83 FETCH (UID 19570 FLAGS (\Seen)
INTERNALDATE "20-Jun-2002 18:36:51 +1000" RFC822.SIZE 55
RFC822.HEADER {46}
  43:26.46      matched r'\* (?P<data>\d+)
(?P<type>[A-Z-]+)( (?P<data2>.*))?' => ('83', 'FETCH', '
(UID 19570 FLAGS (\Seen) INTERNALDATE "20-Jun-2002 18:36:51
+1000" RFC822.SIZE 55 RFC822.HEADER {46}', '(UID 19570 FLAGS
(\Seen) INTERNALDATE "20-Jun-2002 18:36:51 +1000"
RFC822.SIZE 55 RFC822.HEADER {46}')
  43:26.46      matched r'.*{(?P<size>\d+)}$' => ('46',)
  43:26.47 read literal size 46
	...
and so on.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571334&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 10:56:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 02:56:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-571568 ] binary file read/write inconsistency
Message-ID: <E17KygB-0000TZ-00@usw-sf-web3.sourceforge.net>

Bugs item #571568, was opened at 2002-06-20 12:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571568&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anatoly Artamonov (arthem)
Assigned to: Tim Peters (tim_one)
Summary: binary file read/write inconsistency

Initial Comment:
I'm using py 2.1.3 for windows
here's a sample code that works fine in Unix and somekind 
weird in Win32:
###############################
import os.path

pth = "22"
f = open(pth,'w')
for k in range(256):  
    f.write(chr(k))
f.close()

f = open(pth)
dat = f.read()
f.close()
print len(dat), 'vs' , os.path.getsize(pth)
print "last read symbol is: 0x%x" % ord(dat[-1])
#################################

Windows version writes 0x0D 0x0A instead of 0x0A so file 
length is 257 bytes instead of 256 as one might expect
and reading just ends at 0x19 (probably end of file 
symbol). 


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571568&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 13:15:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 05:15:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-571568 ] binary file read/write inconsistency
Message-ID: <E17L0r1-0003P6-00@usw-sf-web3.sourceforge.net>

Bugs item #571568, was opened at 2002-06-20 09:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571568&group_id=5470

Category: Windows
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Anatoly Artamonov (arthem)
>Assigned to: Michael Hudson (mwh)
Summary: binary file read/write inconsistency

Initial Comment:
I'm using py 2.1.3 for windows
here's a sample code that works fine in Unix and somekind 
weird in Win32:
###############################
import os.path

pth = "22"
f = open(pth,'w')
for k in range(256):  
    f.write(chr(k))
f.close()

f = open(pth)
dat = f.read()
f.close()
print len(dat), 'vs' , os.path.getsize(pth)
print "last read symbol is: 0x%x" % ord(dat[-1])
#################################

Windows version writes 0x0D 0x0A instead of 0x0A so file 
length is 257 bytes instead of 256 as one might expect
and reading just ends at 0x19 (probably end of file 
symbol). 


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-06-20 12:15

Message:
Logged In: YES 
user_id=6656

Files are opened in text mode by default.

You can question this, but it ain't gonna change.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571568&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 14:48:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 06:48:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-571568 ] binary file read/write inconsistency
Message-ID: <E17L2IX-0005EC-00@usw-sf-web2.sourceforge.net>

Bugs item #571568, was opened at 2002-06-20 05:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571568&group_id=5470

Category: Windows
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Anatoly Artamonov (arthem)
Assigned to: Michael Hudson (mwh)
Summary: binary file read/write inconsistency

Initial Comment:
I'm using py 2.1.3 for windows
here's a sample code that works fine in Unix and somekind 
weird in Win32:
###############################
import os.path

pth = "22"
f = open(pth,'w')
for k in range(256):  
    f.write(chr(k))
f.close()

f = open(pth)
dat = f.read()
f.close()
print len(dat), 'vs' , os.path.getsize(pth)
print "last read symbol is: 0x%x" % ord(dat[-1])
#################################

Windows version writes 0x0D 0x0A instead of 0x0A so file 
length is 257 bytes instead of 256 as one might expect
and reading just ends at 0x19 (probably end of file 
symbol). 


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-06-20 09:48

Message:
Logged In: YES 
user_id=31435

Change your open() line to

f = open(pth, 'w'b')

and the test case should work the same across platforms.  
chr(26) is also an end-of-file symbol in text mode on 
Windows.  Opening in binary mode is again the cure.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-06-20 08:15

Message:
Logged In: YES 
user_id=6656

Files are opened in text mode by default.

You can question this, but it ain't gonna change.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571568&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 15:01:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 07:01:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-571334 ] imaplib fetch is broken
Message-ID: <E17L2Vb-0005F7-00@usw-sf-web1.sourceforge.net>

Bugs item #571334, was opened at 2002-06-19 16:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571334&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Goerzen (jgoerzen)
Assigned to: Piers Lauder (pierslauder)
Summary: imaplib fetch is broken

Initial Comment:
This bug is 100% reproducible in Python 2.2.1 and the 
imaplib.py from Python's CVS tree. 
 
They'll send the message body in this form: 
{100} 
Headers here, body here, (100 characters worth) 
 
This is specified in RFC2060 secion 4.3.  imaplib's fetch 
chokes on 
"unexpected data" in the response. 
 
imaplib should receive this prefix-quoted string properly 
and return it in a 
non-quoted fashion. 
 
As it is, it is totally impossible to read messages from 
most imap servers. 
 

----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 2002-06-20 09:01

Message:
Logged In: YES 
user_id=491567

It turns out that it is a bug in read() in the imaplib.  It does not 
obey the principle that the read() call will return UP TO the 
amount of bytes specified.  The below diff fixes it for me.  I 
have not yet tried append(), but I suspect that the write calls 
will have the same problem. 
 
--- imaplib.py  18 Jun 2002 15:36:03 -0000      1.1 
+++ imaplib.py  20 Jun 2002 04:02:49 -0000      1.2 
@@ -222,8 +222,10 @@ 
 
     def read(self, size): 
         """Read 'size' bytes from remote.""" 
-        return self.file.read(size) 
- 
+        retval = '' 
+        while len(retval) < size: 
+            retval += self.file.read(size - len(retval)) 
+        return retval 
 
     def readline(self): 
         """Read line from remote.""" 
@@ -1056,7 +1059,10 @@ 
 
     def read(self, size): 
         """Read 'size' bytes from remote.""" 
-        return self.sslobj.read(size) 
+        retval = '' 
+        while len(retval) < size: 
+            retval += self.sslobj.read(size - len(retval)) 
+        return retval 
 
 
     def readline(self): 
 

----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-20 03:46

Message:
Logged In: YES 
user_id=196212

I can't duplicate this.

The test code at the end of imaplib.py includes a FETCH
command which is returned as a literal by my imap server.

Perhaps you could run that test on your server and cut
and paste the response.

Run the test like this:
  python2.2 imaplib.py -d5 <imap_server_host_name>

>From which I get the following:
	...
 43:26.15 > KDP19 UID FETCH 19570 (FLAGS INTERNALDATE
RFC822.SIZE RFC822.HEADER RFC822.TEXT)
  43:26.46 < * 83 FETCH (UID 19570 FLAGS (\Seen)
INTERNALDATE "20-Jun-2002 18:36:51 +1000" RFC822.SIZE 55
RFC822.HEADER {46}
  43:26.46      matched r'\* (?P<data>\d+)
(?P<type>[A-Z-]+)( (?P<data2>.*))?' => ('83', 'FETCH', '
(UID 19570 FLAGS (\Seen) INTERNALDATE "20-Jun-2002 18:36:51
+1000" RFC822.SIZE 55 RFC822.HEADER {46}', '(UID 19570 FLAGS
(\Seen) INTERNALDATE "20-Jun-2002 18:36:51 +1000"
RFC822.SIZE 55 RFC822.HEADER {46}')
  43:26.46      matched r'.*{(?P<size>\d+)}$' => ('46',)
  43:26.47 read literal size 46
	...
and so on.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571334&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 15:25:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 07:25:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-493243 ] ext call doco warts
Message-ID: <E17L2sJ-00066E-00@usw-sf-web2.sourceforge.net>

Bugs item #493243, was opened at 2001-12-14 05:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493243&group_id=5470

Category: Documentation
Group: None
>Status: Closed
Resolution: Fixed
Priority: 6
Submitted By: Michael Hudson (mwh)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: ext call doco warts

Initial Comment:
Now they've been compiled <wink>, I notice that there
are some warts in my docs for the *- and **-style call
syntax.

1) the "argument_list" production is really, really
confusing.  there must be a better BNF-style way of
saying that.  I don't think vertically centering the
production name against the production helps.

2) For some reason, where I say

It is unusual for both keyword arguments and the
"*expression"syntax to be used in the same call, so in
practice this confusion does not arise.

there's no space between `"*expression"' and `syntax'.
 I'd guess that this is because in the source, the
\samp{} macro is the last thing on the line, but why
that should lead to a missing space is beyond me --
more latex2html bugs?

(just noticed the same thing a bit higher up too -- 

the "**expression"argument, if any 

No hurry with these.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-20 10:25

Message:
Logged In: YES 
user_id=3066

Ok, I've fixed that with a different patch.  Checked in as
Doc/ref/ref5.tex revision 1.63.

Thanks for your patience, and persistence!

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-06-19 06:25

Message:
Logged In: YES 
user_id=6656

Sorry, you need to reread my comment of 2001-12-20: the
problem with the pseudo-BNF as it stands is that it is
WRONG!  This is what my patch attempts to fix.

The problems mentioned originally have been fixed -- perhaps
I should have opened a new report.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-18 14:43

Message:
Logged In: YES 
user_id=3066

1) Do you still see vertical centering of the production
name?  That should be aligned with the top of the definition
text.  I've played contortionist with that production in
Doc/ref/ref5.tex revision 1.62.

2) That's not another bug, that's the one that keeps biting
us.  I'm not sure whether that's in latex2html itself or in
my extension code for it.  ;-(  This has already been fixed
on the trunk.

I'm closing this, since I think we're ok now; feel free to
re-open or file a new report if you think my changes aren't
sufficient.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-14 10:24

Message:
Logged In: YES 
user_id=3066

Bumped priority; needs review.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-06-14 10:09

Message:
Logged In: YES 
user_id=6656

I'm going to check my fix in unless someone complains *real*
soon.

At least I know it compiles now, and I think it's an
improvement.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-12-20 09:25

Message:
Logged In: YES 
user_id=6656

Another problem with the pseudo-EBNF: it's wrong.  Oops.

It suggests that f(a, **b) isn't legal, for example.

I've attached an attempt I think it right, but I'm not sure 
and haven't compiled it (& so don't know if it looks any less 
confusing than last time).


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-12-14 12:01

Message:
Logged In: YES 
user_id=3066

Fixed table cell alignment in Doc/perl/python.perl revision
1.115.

Fixed item 2:  Worked around spaces problem in
Doc/ref/ref5.tex 1.53

This bug remains open; I still need to address the basic
problem in item 1 (confusing pseudo-EBNF).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493243&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 15:54:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 07:54:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-495978 ] It's the future for generators
Message-ID: <E17L3Kc-0006kc-00@usw-sf-web2.sourceforge.net>

Bugs item #495978, was opened at 2001-12-21 17:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495978&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Tim Peters (tim_one)
Summary: It's the future for generators

Initial Comment:
"from __future__ import generators" should no longer 
be required in 2.3a1.  Such stmts should also be 
removed from the Python library (there's a script 
under Tools to automate this).

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-06-20 10:54

Message:
Logged In: YES 
user_id=31435

Thanks for the reminder!  There was still a generator future 
stmt in test_enumerate.py, which I just got rid of.  I don't 
know of any other glitches here, so finally closing this.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-20 03:59

Message:
Logged In: YES 
user_id=80475

Can this be closed?
The library is free of from __future__ generators and the 
core doesn't require it now.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 17:18

Message:
Logged In: YES 
user_id=6380

It's not too late!  Neil hasn't checked it in yet.

Neil, would you be willing to change your patch so that it
disables the yield keyword using #ifdef rather than by
erasing all of the code?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 16:59

Message:
Logged In: YES 
user_id=31435

Na, you should read me as saying I don't know how to write 
the kinds of docs you want.  I didn't do the parser changes 
here, so if you think there's something predictable and 
useful to be said here, you're the one to say it.

Keeping at least one example around under an "#if 0" sounds 
like an excellent idea.  The last time I implemented a 
future gimmick, it was spread around in so many places that 
the only sane way to proceed was to search for "the other" 
future gimmick that happened to be implemented already.

But doing that kind of search again is the only sane way I 
know to get rid of the future-generator business now too.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 16:39

Message:
Logged In: YES 
user_id=6380

Actually, each time a future feature introduces a new
keyword that has to remain an identifier when the feature is
not enabled, almost *exactly* the same hacks have to be
applied to the parser. That's just how the parser works. I
would almost recommend keeping those changes around at all
times, just #ifdef'ed out or something.

The other stuff that feels like it's very similar each time
is the handling of the flags passed around between the
various passes of the code generator.

But I know it's hopeless to argue with you, so I'll let you
rediscover all that when you decide to finally implement the
braces feature. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 16:22

Message:
Logged In: YES 
user_id=31435

The internal future machinery has changed every time we've 
added a new future gimmick.  So there's really nothing to 
be said other than to scour the source code looking for now-
obsolete "stuff".  For example, it's possible that the 
kinds of parser changes made for "yield" will never happen 
again, and, even if they do, I think it's impossible to 
predict where and how the parser will need to be unchanged.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 16:13

Message:
Logged In: YES 
user_id=6380

There ought to be documentation on what to do when an
optional feature becomes mandatory. Maybe a block comment or
docstring in __future__.py?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 15:34

Message:
Logged In: YES 
user_id=31435

Neil, if you don't enjoy using the patch system for 
straightforward stuff like this, don't feel compelled to 
use it.  That is, just check it in.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 15:04

Message:
Logged In: YES 
user_id=35752

The attached patch removes the "yield is an optional keyword"
hacks from the parser.  It's not a complete fix for this
bug though.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495978&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 19:00:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 11:00:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-546434 ] buffer slice type inconsistant
Message-ID: <E17L6Dw-0001Qj-00@usw-sf-web3.sourceforge.net>

Bugs item #546434, was opened at 2002-04-20 03:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546434&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Donald Wallace Rouse II (dwr2)
Assigned to: Guido van Rossum (gvanrossum)
Summary: buffer slice type inconsistant

Initial Comment:
The type of a buffer slice is either 'buffer' 
or 'str', depending on the slice parameters.
If the slice encompasses the entire buffer, the buffer 
itself is returned.
Otherwise, a string is returned.
Here is a sample session:
--------------------------
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
IDLE 0.8 -- press F1 for help
>>> a="0123456789"
>>> b = buffer(a, 1, 8)
>>> b
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[:]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[:8]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[2:4]
'34'
>>> b[5]
'6'
>>> c = buffer(a, 4, 1)
>>> c
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C8, size 
1 at 0x00AAA370>
>>> c[0]
'4'
>>> c[0:1]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C8, size 
1 at 0x00AAA370>
--------------------------
Either b[:] should produce a string, or, more 
preferably, b[x:y] should be equivalent to buffer(b, 
x, y), and c[0] should be equivalent to buffer(c, 0, 
1).
The reason that the types should be similar is because 
if a buffer is passed to a function that's checking 
for strings, the function should always fail or always 
succeed.

This is especially important because types.BufferType 
isn't in the types.StringTypes list, so the 
expression "type(b) in types.StringTypes" will also 
behave inconsistantly.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-20 14:00

Message:
Logged In: YES 
user_id=6380

Hm, shoudldn't slicing a buffer always return a buffer
object? That's what the OP requested and seems to be the
most consistent. (On the other hand getting a single item
with b[i] should return a character.)

I think that repetition on a buffer object should be an error.

This would be a semantic change that can't be backported to 2.2.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-20 03:35

Message:
Logged In: YES 
user_id=80475

Added Py2.3 patch to make slicing and repetition always 
return a string.  Unsure if it is a 2.2 backport candidate.



----------------------------------------------------------------------

Comment By: Donald Wallace Rouse II (dwr2)
Date: 2002-04-20 03:36

Message:
Logged In: YES 
user_id=111611

Sorry about the formatting; the form wrapped the lines.
A slight correction:
  "b[x:y] should be equivalent to buffer(b, x, y)"
should be
"b[x:y] should be equivalent to buffer(b, x1, y1 - x1), 
where x1 == x if x is positive and len(b) + x if x is 
negative, and similarly for y and y1".

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546434&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 19:17:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 11:17:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-569257 ] __slots__ attribute and private variable
Message-ID: <E17L6VA-0001pz-00@usw-sf-web1.sourceforge.net>

Bugs item #569257, was opened at 2002-06-14 20:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Keyton Weissinger (keytonw)
Assigned to: Guido van Rossum (gvanrossum)
Summary: __slots__ attribute and private variable

Initial Comment:
If you use a __slots__ class variable and include a 
variable with a double underscore as the first two 
characters, that variable is NOT private as would be the 
case for any other variable whose name begins with a 
double underscore.

If this is by design, then it should be in the docs. If it is 
not and represents a bug, it needs to be investigated.

Thank you!!!

Keyton Weissinger

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-20 14:17

Message:
Logged In: YES 
user_id=6380

Looks fine now, except you are missing an "if (newslots ==
NULL) return NULL;" error check.

I sort of wish that we could avoid first turning the list
(or other sequence) into a tuple and then making another
copy, but the full dance to turn something into a tuple is
complicated (see PySequence_Tuple -- it's got special cases
galore). Maybe you can avoid creating a new tuple when the
refcnt equals one -- then you know it's a new tuple returned
by PySequence_Tuple() that isn't shared with anyone else.

E.g.

if (slots->ob_refcnt == 1) {
  Py_INCREF(slots);
  newslots = slots;
}
else {
  newslots = PyTuple_New(nslots);
}

But then the subsequent loop must be a bit more careful with
refcounts.
OK if you check in what you have now, which is more provably
correct (after adding the error check).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-20 01:19

Message:
Logged In: YES 
user_id=80475

Done.
Revised patch attached.
No more modifying immutables for me!

Thanks for the comments -- they really help me get to the 
root of a problem, get it fixed, and learn something for the 
next bugfix.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 23:04

Message:
Logged In: YES 
user_id=6380

Eh, no, I think there's a bug. The slots variable is made a
tuple by calling PySequence_Tuple(). If it was already a
tuple, this adds a reference to the existing tuple. And
later you're modifying it in-place! This gives the
"impossible" semantics of the following example:

>>> t = ("__foo", "__bar")
>>> class C(object):
      __slots__ = t
    
>>> t
('_C__foo', '_C__bar')
>>> 

I'm afraid you'll have to clone the tuple when you find its
refcount is >1.

Also, please make lines < 79 chars. And a readability
recommendation: if an if statement's expression is several
lines long, don't hide the '{' at the end of a line, but put
it at the beginning of the next, under the if: e.g.

    if (blah, blah, blah,
        blah, blah, blah,
        blah, blah, blah)
    {
        blah;
        blah;
    }

Barry taught me this trick. :-)

Also, I think it's wrong to #include "compile.h" in
Python.h, it exposes too many internals... Better declare
the _Py_Munge() prototype somewhere else (directly in
Python.h would be fine).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-19 22:51

Message:
Logged In: YES 
user_id=80475

Done.  New patch attached. Okay to commit?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 15:30

Message:
Logged In: YES 
user_id=6380

rhettinger: I haven't seen the patch, but I agree this ought
to be fixed -- in Python 2.3, as a new feature though. Why
don't you make munge() a private global (with an _Py prefix
to its name).

keytonw: I have no idea what you meant in your comment about
properties and slots and __property_name__. Can you
elaborate that?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-19 14:13

Message:
Logged In: YES 
user_id=80475

Added patch.

Note, the patch would be much shorter if mangle() in 
compile.c were made non-static.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-18 00:19

Message:
Logged In: YES 
user_id=80475

Agree that it is a bug.
Working on a patch.

----------------------------------------------------------------------

Comment By: Keyton Weissinger (keytonw)
Date: 2002-06-14 23:31

Message:
Logged In: YES 
user_id=396481

Also, this issue prevents you from using the combination of 
property() and __slots__ which would be powerful, as 
attempting to use them would make __property_name__ a 
legal public variable, no?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 19:41:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 11:41:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-571759 ] sys.getrefcount()==1 is possible
Message-ID: <E17L6sT-0003lX-00@usw-sf-web2.sourceforge.net>

Bugs item #571759, was opened at 2002-06-20 14:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571759&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Smith (gregsmith)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: sys.getrefcount()==1 is possible

Initial Comment:
the __doc__ for sys.getrefcount says
"This includes the temporary reference in the argument
list, so it is at least 2."

However, 
sys.getrefcount(  ('some', 'new', 'object') )

returns 1, either at the interpreter or when run  in a
script. Tested on 2.2,
but it happens on 1.5 also.

Is this nit-picking?

Greg



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571759&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 20:03:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 12:03:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-571767 ] string.capitlize() documentation
Message-ID: <E17L7Df-0002tn-00@usw-sf-web3.sourceforge.net>

Bugs item #571767, was opened at 2002-06-20 14:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571767&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Cowles (mdcowles)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: string.capitlize() documentation

Initial Comment:
(Brought up on python-help)

The documentation for string.capitalize() says:

capitalize(word)
Capitalize the first character of the argument.

while it should really say what the documentation for
the corresponding string method says:

capitalize()
Return a copy of the string with only its first
character capitalized. 

since it makes the rest of the string lowercase.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571767&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 22:00:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 14:00:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-532467 ] 6.9 The raise statement is confusing
Message-ID: <E17L92s-0006N7-00@usw-sf-web2.sourceforge.net>

Bugs item #532467, was opened at 2002-03-20 08:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532467&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Patrick K. O'Brien (pobrien)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: 6.9 The raise statement is confusing

Initial Comment:
The description supplied for "6.9 The raise statement" 
is confusing. In particular, it starts by explaining 
the intent of each "expresssion" and midway switches 
to "object" instead of expression. In particular, I 
can't make heads or tails out of the following passage:

"If the first object is a string, it then raises the 
exception identified by the first object, with the 
second one (or None) as its parameter. If the first 
object is a class or instance, it raises the exception 
identified by the class of the instance determined in 
the previous step, with the instance as its parameter."

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-20 17:00

Message:
Logged In: YES 
user_id=3066

I've checked in a different patch as Doc/ref/ref4.tex 1.32
and Doc/ref/ref6.tex 1.54.

Please review the changes; if not sufficient, please re-open
this report with comments on what else is needed (or file a
new report).

http://www.python.org/dev/doc/devel/ref/raise.html

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-20 00:09

Message:
Logged In: YES 
user_id=3066

Raymond is still waiting, so bumping to 7 so I notice it in
the morning (when I'm not really asleep).

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-29 15:45

Message:
Logged In: YES 
user_id=3066

Bumped priority since Raymond is waiting for my review.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-18 21:25

Message:
Logged In: YES 
user_id=80475

Thanks Patrick.

Since I'm the new guy, I'll defer additional changes to 
Fred.  My patch style is to make the least invasive change 
that improves clarity and accuracy.  

Also, this may be a case where additional wording, even if 
informative and accurate, may detract from a strong 
understanding of how raise works.  

This section's cyclomatic complexity (nested if/elif/else 
paths) already impinges its understandability.

----------------------------------------------------------------------

Comment By: Patrick K. O'Brien (pobrien)
Date: 2002-05-16 10:34

Message:
Logged In: YES 
user_id=179604

Raymond, I really appreciate your patches. The big patch is 
terrific and gets my vote. I do have one more request for 
clarification in what you wrote. You say:

"If the first expression is a class object, it raises the 
exception identified by the class of an instance determined 
by the second expression.  If the second expression is an 
instance, that instance is used."

So we're talking about the form: raise class, instance

What I'm picturing is a situation where the second 
expression is an instance of a class other than the class 
object used as the first expression. Is this allowed, 
disallowed, allowed but nonsensical or allowed because it 
offers some practical benefit that I'm just not grasping?

I found and read the essay on "Standard Exception Classes 
in Python 1.5" 
(http://www.python.org/doc/essays/stdexceptions.html) and I 
can see that much was done to maintain backward 
compatibility. and apparently the "raise class, instance" 
form goes back quite a ways. Is this just a wart to be 
avoided? I'm probably expecting too much to expect the 
language reference to distinguish between what is strictly 
allowed vs. why it is allowed and whether it should even be 
used at all. It's just that the more I dug into this the 
more confused I became. I think I'm understanding the 
situation now.

In any case, make of this what you will. The bottom line is 
that your batch is definitely an improvement and I greatly 
appreciate your time and effort on this. Thanks.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-16 00:10

Message:
Logged In: YES 
user_id=80475

Attached two alternative patches.

The first makes minimal changes to achieve a clear and 
consistent use of "objects" versus "expressions".

The second alternative re-paragraphs the text and uses 
parallel sentence contruction to provide (IMHO) 
greater clarity without getting a headache reading it.

If accepted, please re-assign to Raymond for a commit to 
2.3 and to release22-maint.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532467&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 22:20:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 14:20:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-571767 ] string.capitlize() documentation
Message-ID: <E17L9LV-0006Ak-00@usw-sf-web1.sourceforge.net>

Bugs item #571767, was opened at 2002-06-20 15:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571767&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matthew Cowles (mdcowles)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: string.capitlize() documentation

Initial Comment:
(Brought up on python-help)

The documentation for string.capitalize() says:

capitalize(word)
Capitalize the first character of the argument.

while it should really say what the documentation for
the corresponding string method says:

capitalize()
Return a copy of the string with only its first
character capitalized. 

since it makes the rest of the string lowercase.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-20 17:20

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/lib/libstring.tex revisions 1.47, 1.45.8.2, and
1.42.4.2.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571767&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 22:30:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 14:30:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-571845 ] test_import crashes/hangs for MacPython
Message-ID: <E17L9Vf-0006Od-00@usw-sf-web1.sourceforge.net>

Bugs item #571845, was opened at 2002-06-20 23:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571845&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: test_import crashes/hangs for MacPython

Initial Comment:
Test_import breaks for MacPython after the patches for bug #561858 were committed.
On Mac OS 9 the test runs into an out-of-memory situation (after gobbling up 23MB), on Mac OS X it hangs (or, at least, it doesn't respond for 15 minutes).

I think this is unrelated to the original bug, so I'm putting this in a separate report. For now I am disabling the specific test when running under MacPython, but this should be fixed eventually.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571845&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 22:37:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 14:37:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-571759 ] sys.getrefcount()==1 is possible
Message-ID: <E17L9bx-0005EJ-00@usw-sf-web3.sourceforge.net>

Bugs item #571759, was opened at 2002-06-20 14:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571759&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gregory Smith (gregsmith)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: sys.getrefcount()==1 is possible

Initial Comment:
the __doc__ for sys.getrefcount says
"This includes the temporary reference in the argument
list, so it is at least 2."

However, 
sys.getrefcount(  ('some', 'new', 'object') )

returns 1, either at the interpreter or when run  in a
script. Tested on 2.2,
but it happens on 1.5 also.

Is this nit-picking?

Greg



----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-20 17:37

Message:
Logged In: YES 
user_id=3066

Yes, this is nitpicking, but that's ok -- documentation has
to be right too!

Fixed in Python/sysmodule.c revisions 2.105 and 2.98.6.5.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571759&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 22:38:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 14:38:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-569257 ] __slots__ attribute and private variable
Message-ID: <E17L9dU-0007E2-00@usw-sf-web2.sourceforge.net>

Bugs item #569257, was opened at 2002-06-14 19:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Keyton Weissinger (keytonw)
Assigned to: Guido van Rossum (gvanrossum)
Summary: __slots__ attribute and private variable

Initial Comment:
If you use a __slots__ class variable and include a 
variable with a double underscore as the first two 
characters, that variable is NOT private as would be the 
case for any other variable whose name begins with a 
double underscore.

If this is by design, then it should be in the docs. If it is 
not and represents a bug, it needs to be investigated.

Thank you!!!

Keyton Weissinger

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-20 16:38

Message:
Logged In: YES 
user_id=80475

Rather than just check it in, I took another crack at it and 
added a patch with the special (and most common) case 
where the refcnt==1.

I haven't decided whether I like it.  It doubles the code size, 
but is fast, doesn't waste mallocs, has a clear 
intention/expression, and it is easy to verify the refcnts.

Let me know whether you prefer this or the previous 
version (with the null check added).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-20 13:17

Message:
Logged In: YES 
user_id=6380

Looks fine now, except you are missing an "if (newslots ==
NULL) return NULL;" error check.

I sort of wish that we could avoid first turning the list
(or other sequence) into a tuple and then making another
copy, but the full dance to turn something into a tuple is
complicated (see PySequence_Tuple -- it's got special cases
galore). Maybe you can avoid creating a new tuple when the
refcnt equals one -- then you know it's a new tuple returned
by PySequence_Tuple() that isn't shared with anyone else.

E.g.

if (slots->ob_refcnt == 1) {
  Py_INCREF(slots);
  newslots = slots;
}
else {
  newslots = PyTuple_New(nslots);
}

But then the subsequent loop must be a bit more careful with
refcounts.
OK if you check in what you have now, which is more provably
correct (after adding the error check).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-20 00:19

Message:
Logged In: YES 
user_id=80475

Done.
Revised patch attached.
No more modifying immutables for me!

Thanks for the comments -- they really help me get to the 
root of a problem, get it fixed, and learn something for the 
next bugfix.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 22:04

Message:
Logged In: YES 
user_id=6380

Eh, no, I think there's a bug. The slots variable is made a
tuple by calling PySequence_Tuple(). If it was already a
tuple, this adds a reference to the existing tuple. And
later you're modifying it in-place! This gives the
"impossible" semantics of the following example:

>>> t = ("__foo", "__bar")
>>> class C(object):
      __slots__ = t
    
>>> t
('_C__foo', '_C__bar')
>>> 

I'm afraid you'll have to clone the tuple when you find its
refcount is >1.

Also, please make lines < 79 chars. And a readability
recommendation: if an if statement's expression is several
lines long, don't hide the '{' at the end of a line, but put
it at the beginning of the next, under the if: e.g.

    if (blah, blah, blah,
        blah, blah, blah,
        blah, blah, blah)
    {
        blah;
        blah;
    }

Barry taught me this trick. :-)

Also, I think it's wrong to #include "compile.h" in
Python.h, it exposes too many internals... Better declare
the _Py_Munge() prototype somewhere else (directly in
Python.h would be fine).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-19 21:51

Message:
Logged In: YES 
user_id=80475

Done.  New patch attached. Okay to commit?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 14:30

Message:
Logged In: YES 
user_id=6380

rhettinger: I haven't seen the patch, but I agree this ought
to be fixed -- in Python 2.3, as a new feature though. Why
don't you make munge() a private global (with an _Py prefix
to its name).

keytonw: I have no idea what you meant in your comment about
properties and slots and __property_name__. Can you
elaborate that?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-19 13:13

Message:
Logged In: YES 
user_id=80475

Added patch.

Note, the patch would be much shorter if mangle() in 
compile.c were made non-static.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-17 23:19

Message:
Logged In: YES 
user_id=80475

Agree that it is a bug.
Working on a patch.

----------------------------------------------------------------------

Comment By: Keyton Weissinger (keytonw)
Date: 2002-06-14 22:31

Message:
Logged In: YES 
user_id=396481

Also, this issue prevents you from using the combination of 
property() and __slots__ which would be powerful, as 
attempting to use them would make __property_name__ a 
legal public variable, no?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 22:44:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 14:44:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-569257 ] __slots__ attribute and private variable
Message-ID: <E17L9jJ-0006hV-00@usw-sf-web1.sourceforge.net>

Bugs item #569257, was opened at 2002-06-14 20:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Keyton Weissinger (keytonw)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: __slots__ attribute and private variable

Initial Comment:
If you use a __slots__ class variable and include a 
variable with a double underscore as the first two 
characters, that variable is NOT private as would be the 
case for any other variable whose name begins with a 
double underscore.

If this is by design, then it should be in the docs. If it is 
not and represents a bug, it needs to be investigated.

Thank you!!!

Keyton Weissinger

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-20 17:44

Message:
Logged In: YES 
user_id=6380

Hm, I don't like the code duplication. :-(

I liked the previous version better.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-20 17:38

Message:
Logged In: YES 
user_id=80475

Rather than just check it in, I took another crack at it and 
added a patch with the special (and most common) case 
where the refcnt==1.

I haven't decided whether I like it.  It doubles the code size, 
but is fast, doesn't waste mallocs, has a clear 
intention/expression, and it is easy to verify the refcnts.

Let me know whether you prefer this or the previous 
version (with the null check added).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-20 14:17

Message:
Logged In: YES 
user_id=6380

Looks fine now, except you are missing an "if (newslots ==
NULL) return NULL;" error check.

I sort of wish that we could avoid first turning the list
(or other sequence) into a tuple and then making another
copy, but the full dance to turn something into a tuple is
complicated (see PySequence_Tuple -- it's got special cases
galore). Maybe you can avoid creating a new tuple when the
refcnt equals one -- then you know it's a new tuple returned
by PySequence_Tuple() that isn't shared with anyone else.

E.g.

if (slots->ob_refcnt == 1) {
  Py_INCREF(slots);
  newslots = slots;
}
else {
  newslots = PyTuple_New(nslots);
}

But then the subsequent loop must be a bit more careful with
refcounts.
OK if you check in what you have now, which is more provably
correct (after adding the error check).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-20 01:19

Message:
Logged In: YES 
user_id=80475

Done.
Revised patch attached.
No more modifying immutables for me!

Thanks for the comments -- they really help me get to the 
root of a problem, get it fixed, and learn something for the 
next bugfix.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 23:04

Message:
Logged In: YES 
user_id=6380

Eh, no, I think there's a bug. The slots variable is made a
tuple by calling PySequence_Tuple(). If it was already a
tuple, this adds a reference to the existing tuple. And
later you're modifying it in-place! This gives the
"impossible" semantics of the following example:

>>> t = ("__foo", "__bar")
>>> class C(object):
      __slots__ = t
    
>>> t
('_C__foo', '_C__bar')
>>> 

I'm afraid you'll have to clone the tuple when you find its
refcount is >1.

Also, please make lines < 79 chars. And a readability
recommendation: if an if statement's expression is several
lines long, don't hide the '{' at the end of a line, but put
it at the beginning of the next, under the if: e.g.

    if (blah, blah, blah,
        blah, blah, blah,
        blah, blah, blah)
    {
        blah;
        blah;
    }

Barry taught me this trick. :-)

Also, I think it's wrong to #include "compile.h" in
Python.h, it exposes too many internals... Better declare
the _Py_Munge() prototype somewhere else (directly in
Python.h would be fine).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-19 22:51

Message:
Logged In: YES 
user_id=80475

Done.  New patch attached. Okay to commit?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 15:30

Message:
Logged In: YES 
user_id=6380

rhettinger: I haven't seen the patch, but I agree this ought
to be fixed -- in Python 2.3, as a new feature though. Why
don't you make munge() a private global (with an _Py prefix
to its name).

keytonw: I have no idea what you meant in your comment about
properties and slots and __property_name__. Can you
elaborate that?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-19 14:13

Message:
Logged In: YES 
user_id=80475

Added patch.

Note, the patch would be much shorter if mangle() in 
compile.c were made non-static.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-18 00:19

Message:
Logged In: YES 
user_id=80475

Agree that it is a bug.
Working on a patch.

----------------------------------------------------------------------

Comment By: Keyton Weissinger (keytonw)
Date: 2002-06-14 23:31

Message:
Logged In: YES 
user_id=396481

Also, this issue prevents you from using the combination of 
property() and __slots__ which would be powerful, as 
attempting to use them would make __property_name__ a 
legal public variable, no?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 23:09:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 15:09:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-566631 ] PyUnicode_Find() returns wrong results
Message-ID: <E17LA7i-00087X-00@usw-sf-web2.sourceforge.net>

Bugs item #566631, was opened at 2002-06-09 20:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566631&group_id=5470

Category: Documentation
Group: Python 2.1.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: PyUnicode_Find() returns wrong results

Initial Comment:
The following is used to search for u'h' inside
the string u'+#&.' (stored in self->seperator)

static PyObject *
Splitter_test(Splitter *self) {
    PyObject *test, *res, *word;

    test = Py_BuildValue("s","h");
    word =
PyUnicode_FromEncodedObject(test,"ascii","strict");

    printf("seperator: ");
    PyObject_Print(self->seperator, stdout, 0);
    puts("");

    printf("Searching for: ");
    PyObject_Print(word, stdout, 0);
    puts("");

    res = PyUnicode_Find(self->seperator, word, 0,
PyUnicode_GET_SIZE(self->seperator), 1);
    if (res==0) puts("not found");
    else puts("found");

}

The output is: 

yetix(366)% python2.1 test.py
seperator: u'+#&.'
Searching for: u'h'
found

So PyUnicode_Find() returns a match although
u'h' is not contained within self->seperator.

Env: Linux 2.4, Python 2.1.3





----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-20 18:09

Message:
Logged In: YES 
user_id=3066

Fixed in:
Doc/api/concrete.tex 1.17, 1.6.6.5.
Doc/api/refcounts.dat 1.42, 1.38.6.3.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-10 07:09

Message:
Logged In: YES 
user_id=31435

Thanks for spotting this, Andreas!

Changed Category to Docs.

Fred, the correct return conditions are documented in 
unicodeobject.h:

"""
Return the first position of substr in str[start:end] using the
given search direction or -1 if not found. -2 is returned in
case  an error occurred and an exception is set.
"""

While looking that up, I noticed that PyUnicode_Count is 
similarly misdocumented.  There may well be others.

----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2002-06-10 06:53

Message:
Logged In: YES 
user_id=11084

Fred, could you please fix the docs for PyUnicode_Find()?
The return value is an int instead of a PyObject *. Also -1
is returned for "not found" instead of 0.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-10 06:52

Message:
Logged In: YES 
user_id=38388

The docs should say it's an int.

----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2002-06-10 06:48

Message:
Logged In: YES 
user_id=11084

Looking it the source, it is a documentation bug since 
PyUnicode_Find()  really returns int. 

Can you assign this issue to Fred to fix the docs *wink*?

-aj

----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2002-06-10 06:45

Message:
Logged In: YES 
user_id=11084

So what does PyUnicode_Find() return?

>From the docs:
PyObject* PyUnicode_Find(PyObject *str, PyObject *substr,
int start, int end, int direction)
    Return value: New reference.
Return the first position of substr in str[start:end] using
the given direction (direction == 1 means to do a forward
search, direction == -1 a backward search), 0 otherwise. 

Does it return an int with the position or a PyObject * ?

-aj

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-06-10 05:17

Message:
Logged In: YES 
user_id=38388

You should check what res actually is rather then doing
the check for == 0. Note that res == -1 means
"not found", res == 0 maps to: match found at position
0.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=566631&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 23:25:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 15:25:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-569257 ] __slots__ attribute and private variable
Message-ID: <E17LANC-0001nk-00@usw-sf-web4.sourceforge.net>

Bugs item #569257, was opened at 2002-06-14 19:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470

Category: Type/class unification
Group: Python 2.3
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Keyton Weissinger (keytonw)
Assigned to: Raymond Hettinger (rhettinger)
Summary: __slots__ attribute and private variable

Initial Comment:
If you use a __slots__ class variable and include a 
variable with a double underscore as the first two 
characters, that variable is NOT private as would be the 
case for any other variable whose name begins with a 
double underscore.

If this is by design, then it should be in the docs. If it is 
not and represents a bug, it needs to be investigated.

Thank you!!!

Keyton Weissinger

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-20 17:25

Message:
Logged In: YES 
user_id=80475

Commited the previous version (with the Null check) as:
typeobject.c 2.156
compile.c 2.246
Python.h 2.52
test_descr.py 1.143

Closing bug.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-20 16:44

Message:
Logged In: YES 
user_id=6380

Hm, I don't like the code duplication. :-(

I liked the previous version better.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-20 16:38

Message:
Logged In: YES 
user_id=80475

Rather than just check it in, I took another crack at it and 
added a patch with the special (and most common) case 
where the refcnt==1.

I haven't decided whether I like it.  It doubles the code size, 
but is fast, doesn't waste mallocs, has a clear 
intention/expression, and it is easy to verify the refcnts.

Let me know whether you prefer this or the previous 
version (with the null check added).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-20 13:17

Message:
Logged In: YES 
user_id=6380

Looks fine now, except you are missing an "if (newslots ==
NULL) return NULL;" error check.

I sort of wish that we could avoid first turning the list
(or other sequence) into a tuple and then making another
copy, but the full dance to turn something into a tuple is
complicated (see PySequence_Tuple -- it's got special cases
galore). Maybe you can avoid creating a new tuple when the
refcnt equals one -- then you know it's a new tuple returned
by PySequence_Tuple() that isn't shared with anyone else.

E.g.

if (slots->ob_refcnt == 1) {
  Py_INCREF(slots);
  newslots = slots;
}
else {
  newslots = PyTuple_New(nslots);
}

But then the subsequent loop must be a bit more careful with
refcounts.
OK if you check in what you have now, which is more provably
correct (after adding the error check).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-20 00:19

Message:
Logged In: YES 
user_id=80475

Done.
Revised patch attached.
No more modifying immutables for me!

Thanks for the comments -- they really help me get to the 
root of a problem, get it fixed, and learn something for the 
next bugfix.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 22:04

Message:
Logged In: YES 
user_id=6380

Eh, no, I think there's a bug. The slots variable is made a
tuple by calling PySequence_Tuple(). If it was already a
tuple, this adds a reference to the existing tuple. And
later you're modifying it in-place! This gives the
"impossible" semantics of the following example:

>>> t = ("__foo", "__bar")
>>> class C(object):
      __slots__ = t
    
>>> t
('_C__foo', '_C__bar')
>>> 

I'm afraid you'll have to clone the tuple when you find its
refcount is >1.

Also, please make lines < 79 chars. And a readability
recommendation: if an if statement's expression is several
lines long, don't hide the '{' at the end of a line, but put
it at the beginning of the next, under the if: e.g.

    if (blah, blah, blah,
        blah, blah, blah,
        blah, blah, blah)
    {
        blah;
        blah;
    }

Barry taught me this trick. :-)

Also, I think it's wrong to #include "compile.h" in
Python.h, it exposes too many internals... Better declare
the _Py_Munge() prototype somewhere else (directly in
Python.h would be fine).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-19 21:51

Message:
Logged In: YES 
user_id=80475

Done.  New patch attached. Okay to commit?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-19 14:30

Message:
Logged In: YES 
user_id=6380

rhettinger: I haven't seen the patch, but I agree this ought
to be fixed -- in Python 2.3, as a new feature though. Why
don't you make munge() a private global (with an _Py prefix
to its name).

keytonw: I have no idea what you meant in your comment about
properties and slots and __property_name__. Can you
elaborate that?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-19 13:13

Message:
Logged In: YES 
user_id=80475

Added patch.

Note, the patch would be much shorter if mangle() in 
compile.c were made non-static.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-17 23:19

Message:
Logged In: YES 
user_id=80475

Agree that it is a bug.
Working on a patch.

----------------------------------------------------------------------

Comment By: Keyton Weissinger (keytonw)
Date: 2002-06-14 22:31

Message:
Logged In: YES 
user_id=396481

Also, this issue prevents you from using the combination of 
property() and __slots__ which would be powerful, as 
attempting to use them would make __property_name__ a 
legal public variable, no?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=569257&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 23:37:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 15:37:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-571334 ] imaplib fetch is broken
Message-ID: <E17LAY2-0005zJ-00@usw-sf-web3.sourceforge.net>

Bugs item #571334, was opened at 2002-06-20 07:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571334&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Goerzen (jgoerzen)
Assigned to: Piers Lauder (pierslauder)
Summary: imaplib fetch is broken

Initial Comment:
This bug is 100% reproducible in Python 2.2.1 and the 
imaplib.py from Python's CVS tree. 
 
They'll send the message body in this form: 
{100} 
Headers here, body here, (100 characters worth) 
 
This is specified in RFC2060 secion 4.3.  imaplib's fetch 
chokes on 
"unexpected data" in the response. 
 
imaplib should receive this prefix-quoted string properly 
and return it in a 
non-quoted fashion. 
 
As it is, it is totally impossible to read messages from 
most imap servers. 
 

----------------------------------------------------------------------

>Comment By: Piers Lauder (pierslauder)
Date: 2002-06-21 08:37

Message:
Logged In: YES 
user_id=196212

I'm very surprised by this. According to the Python library
manual for the read method:

read([size])
 Read at most size bytes from the file (less if the read
hits EOF before obtaining size bytes). If the size argument
is negative or omitted, read all data until EOF is reached.
The bytes are returned as a string object. An empty string
is returned when EOF is encountered immediately. (For
certain files, like ttys, it makes sense to continue reading
after an EOF is hit.) Note that this method may call the
underlying C function fread() more than once in an effort to
acquire as close to size bytes as possible.

So read(size) should return size bytes unless EOF is found.
(And as imaplib has been in use for several years, I take it
the manual is factual :-)

Maybe this is an O/S-specific problem in the python interpreter?
What O/S (and version) is your Python 2.2.1 interpreter
running on?


----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 2002-06-21 00:01

Message:
Logged In: YES 
user_id=491567

It turns out that it is a bug in read() in the imaplib.  It does not 
obey the principle that the read() call will return UP TO the 
amount of bytes specified.  The below diff fixes it for me.  I 
have not yet tried append(), but I suspect that the write calls 
will have the same problem. 
 
--- imaplib.py  18 Jun 2002 15:36:03 -0000      1.1 
+++ imaplib.py  20 Jun 2002 04:02:49 -0000      1.2 
@@ -222,8 +222,10 @@ 
 
     def read(self, size): 
         """Read 'size' bytes from remote.""" 
-        return self.file.read(size) 
- 
+        retval = '' 
+        while len(retval) < size: 
+            retval += self.file.read(size - len(retval)) 
+        return retval 
 
     def readline(self): 
         """Read line from remote.""" 
@@ -1056,7 +1059,10 @@ 
 
     def read(self, size): 
         """Read 'size' bytes from remote.""" 
-        return self.sslobj.read(size) 
+        retval = '' 
+        while len(retval) < size: 
+            retval += self.sslobj.read(size - len(retval)) 
+        return retval 
 
 
     def readline(self): 
 

----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-20 18:46

Message:
Logged In: YES 
user_id=196212

I can't duplicate this.

The test code at the end of imaplib.py includes a FETCH
command which is returned as a literal by my imap server.

Perhaps you could run that test on your server and cut
and paste the response.

Run the test like this:
  python2.2 imaplib.py -d5 <imap_server_host_name>

>From which I get the following:
	...
 43:26.15 > KDP19 UID FETCH 19570 (FLAGS INTERNALDATE
RFC822.SIZE RFC822.HEADER RFC822.TEXT)
  43:26.46 < * 83 FETCH (UID 19570 FLAGS (\Seen)
INTERNALDATE "20-Jun-2002 18:36:51 +1000" RFC822.SIZE 55
RFC822.HEADER {46}
  43:26.46      matched r'\* (?P<data>\d+)
(?P<type>[A-Z-]+)( (?P<data2>.*))?' => ('83', 'FETCH', '
(UID 19570 FLAGS (\Seen) INTERNALDATE "20-Jun-2002 18:36:51
+1000" RFC822.SIZE 55 RFC822.HEADER {46}', '(UID 19570 FLAGS
(\Seen) INTERNALDATE "20-Jun-2002 18:36:51 +1000"
RFC822.SIZE 55 RFC822.HEADER {46}')
  43:26.46      matched r'.*{(?P<size>\d+)}$' => ('46',)
  43:26.47 read literal size 46
	...
and so on.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571334&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 23:45:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 15:45:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-571334 ] imaplib fetch is broken
Message-ID: <E17LAfy-00065S-00@usw-sf-web3.sourceforge.net>

Bugs item #571334, was opened at 2002-06-20 07:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571334&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Goerzen (jgoerzen)
Assigned to: Piers Lauder (pierslauder)
Summary: imaplib fetch is broken

Initial Comment:
This bug is 100% reproducible in Python 2.2.1 and the 
imaplib.py from Python's CVS tree. 
 
They'll send the message body in this form: 
{100} 
Headers here, body here, (100 characters worth) 
 
This is specified in RFC2060 secion 4.3.  imaplib's fetch 
chokes on 
"unexpected data" in the response. 
 
imaplib should receive this prefix-quoted string properly 
and return it in a 
non-quoted fashion. 
 
As it is, it is totally impossible to read messages from 
most imap servers. 
 

----------------------------------------------------------------------

>Comment By: Piers Lauder (pierslauder)
Date: 2002-06-21 08:45

Message:
Logged In: YES 
user_id=196212

PS: could you also state which imaplib class you are using -
there may be a difference between the socket.socket and
socket.ssl behaviours.


----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-21 08:37

Message:
Logged In: YES 
user_id=196212

I'm very surprised by this. According to the Python library
manual for the read method:

read([size])
 Read at most size bytes from the file (less if the read
hits EOF before obtaining size bytes). If the size argument
is negative or omitted, read all data until EOF is reached.
The bytes are returned as a string object. An empty string
is returned when EOF is encountered immediately. (For
certain files, like ttys, it makes sense to continue reading
after an EOF is hit.) Note that this method may call the
underlying C function fread() more than once in an effort to
acquire as close to size bytes as possible.

So read(size) should return size bytes unless EOF is found.
(And as imaplib has been in use for several years, I take it
the manual is factual :-)

Maybe this is an O/S-specific problem in the python interpreter?
What O/S (and version) is your Python 2.2.1 interpreter
running on?


----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 2002-06-21 00:01

Message:
Logged In: YES 
user_id=491567

It turns out that it is a bug in read() in the imaplib.  It does not 
obey the principle that the read() call will return UP TO the 
amount of bytes specified.  The below diff fixes it for me.  I 
have not yet tried append(), but I suspect that the write calls 
will have the same problem. 
 
--- imaplib.py  18 Jun 2002 15:36:03 -0000      1.1 
+++ imaplib.py  20 Jun 2002 04:02:49 -0000      1.2 
@@ -222,8 +222,10 @@ 
 
     def read(self, size): 
         """Read 'size' bytes from remote.""" 
-        return self.file.read(size) 
- 
+        retval = '' 
+        while len(retval) < size: 
+            retval += self.file.read(size - len(retval)) 
+        return retval 
 
     def readline(self): 
         """Read line from remote.""" 
@@ -1056,7 +1059,10 @@ 
 
     def read(self, size): 
         """Read 'size' bytes from remote.""" 
-        return self.sslobj.read(size) 
+        retval = '' 
+        while len(retval) < size: 
+            retval += self.sslobj.read(size - len(retval)) 
+        return retval 
 
 
     def readline(self): 
 

----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-20 18:46

Message:
Logged In: YES 
user_id=196212

I can't duplicate this.

The test code at the end of imaplib.py includes a FETCH
command which is returned as a literal by my imap server.

Perhaps you could run that test on your server and cut
and paste the response.

Run the test like this:
  python2.2 imaplib.py -d5 <imap_server_host_name>

>From which I get the following:
	...
 43:26.15 > KDP19 UID FETCH 19570 (FLAGS INTERNALDATE
RFC822.SIZE RFC822.HEADER RFC822.TEXT)
  43:26.46 < * 83 FETCH (UID 19570 FLAGS (\Seen)
INTERNALDATE "20-Jun-2002 18:36:51 +1000" RFC822.SIZE 55
RFC822.HEADER {46}
  43:26.46      matched r'\* (?P<data>\d+)
(?P<type>[A-Z-]+)( (?P<data2>.*))?' => ('83', 'FETCH', '
(UID 19570 FLAGS (\Seen) INTERNALDATE "20-Jun-2002 18:36:51
+1000" RFC822.SIZE 55 RFC822.HEADER {46}', '(UID 19570 FLAGS
(\Seen) INTERNALDATE "20-Jun-2002 18:36:51 +1000"
RFC822.SIZE 55 RFC822.HEADER {46}')
  43:26.46      matched r'.*{(?P<size>\d+)}$' => ('46',)
  43:26.47 read literal size 46
	...
and so on.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571334&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 23:46:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 15:46:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-571885 ] Segmentation fault in Python 2.3
Message-ID: <E17LAhb-0008A3-00@usw-sf-web1.sourceforge.net>

Bugs item #571885, was opened at 2002-06-21 00:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571885&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christophe Delord (cdelord)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault in Python 2.3

Initial Comment:
It seems there's a bug in python 2.3

The following script works with python 2.2, not with 2.3

def flatten(L):
	for i in L: 
		if type(i) == list: 
			for j in flatten(i):
				yield j
		else:
			yield i 

def mklist(n):
	if n:
		return [ str(n), mklist(n-1), str(n) ] 
	else:
		return []
 
L = mklist(6) 
print "".join(flatten(L))
 
flatten seems to work but join makes a segmentation fault. 
 
It works fine with print "".join(list(flatten(L)))
or when L = mklist(4)

I'm using Python 2.3 with Linux (Redhat)

Best regards,
Christophe Delord.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571885&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 23:50:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 15:50:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-571885 ] Segmentation fault in Python 2.3
Message-ID: <E17LAkn-0008Gm-00@usw-sf-web1.sourceforge.net>

Bugs item #571885, was opened at 2002-06-21 00:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571885&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christophe Delord (cdelord)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault in Python 2.3

Initial Comment:
It seems there's a bug in python 2.3

The following script works with python 2.2, not with 2.3

def flatten(L):
	for i in L: 
		if type(i) == list: 
			for j in flatten(i):
				yield j
		else:
			yield i 

def mklist(n):
	if n:
		return [ str(n), mklist(n-1), str(n) ] 
	else:
		return []
 
L = mklist(6) 
print "".join(flatten(L))
 
flatten seems to work but join makes a segmentation fault. 
 
It works fine with print "".join(list(flatten(L)))
or when L = mklist(4)

I'm using Python 2.3 with Linux (Redhat)

Best regards,
Christophe Delord.

----------------------------------------------------------------------

>Comment By: Christophe Delord (cdelord)
Date: 2002-06-21 00:50

Message:
Logged In: YES 
user_id=566423

Of course, with a correct indentation, it is:

def flatten(L):
    for i in L:
        if type(i) == list:
            for j in flatten(i):
            yield j
        else:
            yield i

def mklist(n):
    if n:
        return [ str(n), mklist(n-1), str(n) ]
    else:
        return [] 

L = mklist(6)
print "".join(flatten(L))

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571885&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 23:52:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 15:52:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-571885 ] Segmentation fault in Python 2.3
Message-ID: <E17LAnG-0006EH-00@usw-sf-web3.sourceforge.net>

Bugs item #571885, was opened at 2002-06-20 22:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571885&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christophe Delord (cdelord)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault in Python 2.3

Initial Comment:
It seems there's a bug in python 2.3

The following script works with python 2.2, not with 2.3

def flatten(L):
	for i in L: 
		if type(i) == list: 
			for j in flatten(i):
				yield j
		else:
			yield i 

def mklist(n):
	if n:
		return [ str(n), mklist(n-1), str(n) ] 
	else:
		return []
 
L = mklist(6) 
print "".join(flatten(L))
 
flatten seems to work but join makes a segmentation fault. 
 
It works fine with print "".join(list(flatten(L)))
or when L = mklist(4)

I'm using Python 2.3 with Linux (Redhat)

Best regards,
Christophe Delord.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-20 22:52

Message:
Logged In: YES 
user_id=31392

When I run the test script, python2.3 says:
654321123456

If I add a future statement to the script and run it with
2.2, I get a core dump.


----------------------------------------------------------------------

Comment By: Christophe Delord (cdelord)
Date: 2002-06-20 22:50

Message:
Logged In: YES 
user_id=566423

Of course, with a correct indentation, it is:

def flatten(L):
    for i in L:
        if type(i) == list:
            for j in flatten(i):
            yield j
        else:
            yield i

def mklist(n):
    if n:
        return [ str(n), mklist(n-1), str(n) ]
    else:
        return [] 

L = mklist(6)
print "".join(flatten(L))

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571885&group_id=5470



From noreply@sourceforge.net  Thu Jun 20 23:56:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 15:56:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-571885 ] Segmentation fault in Python 2.3
Message-ID: <E17LAr2-0002DY-00@usw-sf-web4.sourceforge.net>

Bugs item #571885, was opened at 2002-06-20 22:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571885&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Christophe Delord (cdelord)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault in Python 2.3

Initial Comment:
It seems there's a bug in python 2.3

The following script works with python 2.2, not with 2.3

def flatten(L):
	for i in L: 
		if type(i) == list: 
			for j in flatten(i):
				yield j
		else:
			yield i 

def mklist(n):
	if n:
		return [ str(n), mklist(n-1), str(n) ] 
	else:
		return []
 
L = mklist(6) 
print "".join(flatten(L))
 
flatten seems to work but join makes a segmentation fault. 
 
It works fine with print "".join(list(flatten(L)))
or when L = mklist(4)

I'm using Python 2.3 with Linux (Redhat)

Best regards,
Christophe Delord.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-20 22:56

Message:
Logged In: YES 
user_id=31392

The latest CVS on the 2.2 maintenance branch also works
correctly.

I suspect you've hit a bug that is already fixed.  I'm
closing for now, but feel free to re-open if you can provoke
it with a current checkout from CVS.  If so, it would be
helpful if you could provide a stack trace from gdb.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-20 22:52

Message:
Logged In: YES 
user_id=31392

When I run the test script, python2.3 says:
654321123456

If I add a future statement to the script and run it with
2.2, I get a core dump.


----------------------------------------------------------------------

Comment By: Christophe Delord (cdelord)
Date: 2002-06-20 22:50

Message:
Logged In: YES 
user_id=566423

Of course, with a correct indentation, it is:

def flatten(L):
    for i in L:
        if type(i) == list:
            for j in flatten(i):
            yield j
        else:
            yield i

def mklist(n):
    if n:
        return [ str(n), mklist(n-1), str(n) ]
    else:
        return [] 

L = mklist(6)
print "".join(flatten(L))

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571885&group_id=5470



From noreply@sourceforge.net  Fri Jun 21 00:00:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 16:00:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-571885 ] Segmentation fault in Python 2.3
Message-ID: <E17LAue-0002GL-00@usw-sf-web4.sourceforge.net>

Bugs item #571885, was opened at 2002-06-20 22:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571885&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Christophe Delord (cdelord)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault in Python 2.3

Initial Comment:
It seems there's a bug in python 2.3

The following script works with python 2.2, not with 2.3

def flatten(L):
	for i in L: 
		if type(i) == list: 
			for j in flatten(i):
				yield j
		else:
			yield i 

def mklist(n):
	if n:
		return [ str(n), mklist(n-1), str(n) ] 
	else:
		return []
 
L = mklist(6) 
print "".join(flatten(L))
 
flatten seems to work but join makes a segmentation fault. 
 
It works fine with print "".join(list(flatten(L)))
or when L = mklist(4)

I'm using Python 2.3 with Linux (Redhat)

Best regards,
Christophe Delord.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-20 23:00

Message:
Logged In: YES 
user_id=31392

I was a bit hasty.  It doesn't dump core everytime, but it
does seem to dump core occasionally.  Here's a stack trace
from gdb:
#0  0x806ad98 in _PyTuple_Resize (pv=0xbffff5d8, newsize=12)
    at ../Objects/tupleobject.c:687
#1  0x80b746a in PySequence_Tuple (v=0x4019c72c) at
../Objects/abstract.c:1347
#2  0x80b94bf in PySequence_Fast (v=0x4019c72c, m=0x80d02dc "")
    at ../Objects/abstract.c:1444
#3  0x8065a71 in string_join (self=0x40148098, orig=0x4019c72c)
    at ../Objects/stringobject.c:1212
#4  0x8088166 in fast_cfunction (func=0x4018db0c,
pp_stack=0xbffff724, na=1)
    at ../Python/ceval.c:3108
#5  0x80868c6 in eval_frame (f=0x810afbc) at
../Python/ceval.c:1975
#6  0x80878b2 in PyEval_EvalCodeEx (co=0x4019b360,
globals=0x4015f2d4, 
    locals=0x4015f2d4, args=0x0, argcount=0, kws=0x0,
kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at ../Python/ceval.c:2553
#7  0x80898e0 in PyEval_EvalCode (co=0x4019b360,
globals=0x4015f2d4, 
    locals=0x4015f2d4) at ../Python/ceval.c:482
#8  0x80a42d1 in run_node (n=0x81402f8, filename=0xbffffb23
"/tmp/foo.py", 
    globals=0x4015f2d4, locals=0x4015f2d4, flags=0xbffff928)
    at ../Python/pythonrun.c:1088
#9  0x80a4282 in run_err_node (n=0x81402f8,
filename=0xbffffb23 "/tmp/foo.py", 
    globals=0x4015f2d4, locals=0x4015f2d4, flags=0xbffff928)
    at ../Python/pythonrun.c:1075
#10 0x80a3f01 in PyRun_FileExFlags (fp=0x8102cb0, 
    filename=0xbffffb23 "/tmp/foo.py", start=257,
globals=0x4015f2d4, 
    locals=0x4015f2d4, closeit=1, flags=0xbffff928)
    at ../Python/pythonrun.c:1066
#11 0x80a2af1 in PyRun_SimpleFileExFlags (fp=0x8102cb0, 
    filename=0xbffffb23 "/tmp/foo.py", closeit=1,
flags=0xbffff928)
    at ../Python/pythonrun.c:697
#12 0x80a3a63 in PyRun_AnyFileExFlags (fp=0x8102cb0, 
    filename=0xbffffb23 "/tmp/foo.py", closeit=1,
flags=0xbffff928)
    at ../Python/pythonrun.c:500
#13 0x805374d in Py_Main (argc=2, argv=0xbffff9b4) at
../Modules/main.c:368
#14 0x8052fea in main (argc=2, argv=0xbffff9b4) at
../Modules/python.c:10
#15 0x40077cbe in __libc_start_main () from /lib/libc.so.6


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-20 22:56

Message:
Logged In: YES 
user_id=31392

The latest CVS on the 2.2 maintenance branch also works
correctly.

I suspect you've hit a bug that is already fixed.  I'm
closing for now, but feel free to re-open if you can provoke
it with a current checkout from CVS.  If so, it would be
helpful if you could provide a stack trace from gdb.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-20 22:52

Message:
Logged In: YES 
user_id=31392

When I run the test script, python2.3 says:
654321123456

If I add a future statement to the script and run it with
2.2, I get a core dump.


----------------------------------------------------------------------

Comment By: Christophe Delord (cdelord)
Date: 2002-06-20 22:50

Message:
Logged In: YES 
user_id=566423

Of course, with a correct indentation, it is:

def flatten(L):
    for i in L:
        if type(i) == list:
            for j in flatten(i):
            yield j
        else:
            yield i

def mklist(n):
    if n:
        return [ str(n), mklist(n-1), str(n) ]
    else:
        return [] 

L = mklist(6)
print "".join(flatten(L))

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571885&group_id=5470



From noreply@sourceforge.net  Fri Jun 21 00:14:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 16:14:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-571885 ] Segmentation fault in Python 2.3
Message-ID: <E17LB8I-0000P9-00@usw-sf-web2.sourceforge.net>

Bugs item #571885, was opened at 2002-06-20 22:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571885&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Christophe Delord (cdelord)
>Assigned to: Jeremy Hylton (jhylton)
Summary: Segmentation fault in Python 2.3

Initial Comment:
It seems there's a bug in python 2.3

The following script works with python 2.2, not with 2.3

def flatten(L):
	for i in L: 
		if type(i) == list: 
			for j in flatten(i):
				yield j
		else:
			yield i 

def mklist(n):
	if n:
		return [ str(n), mklist(n-1), str(n) ] 
	else:
		return []
 
L = mklist(6) 
print "".join(flatten(L))
 
flatten seems to work but join makes a segmentation fault. 
 
It works fine with print "".join(list(flatten(L)))
or when L = mklist(4)

I'm using Python 2.3 with Linux (Redhat)

Best regards,
Christophe Delord.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-20 23:14

Message:
Logged In: YES 
user_id=31392

I think this is fixed in CVS now, but I'm waiting to close
the bug because I don't have a test case for it.  Thanks to
Neal for writing a good checkin message.  (Seriously.)


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-20 23:00

Message:
Logged In: YES 
user_id=31392

I was a bit hasty.  It doesn't dump core everytime, but it
does seem to dump core occasionally.  Here's a stack trace
from gdb:
#0  0x806ad98 in _PyTuple_Resize (pv=0xbffff5d8, newsize=12)
    at ../Objects/tupleobject.c:687
#1  0x80b746a in PySequence_Tuple (v=0x4019c72c) at
../Objects/abstract.c:1347
#2  0x80b94bf in PySequence_Fast (v=0x4019c72c, m=0x80d02dc "")
    at ../Objects/abstract.c:1444
#3  0x8065a71 in string_join (self=0x40148098, orig=0x4019c72c)
    at ../Objects/stringobject.c:1212
#4  0x8088166 in fast_cfunction (func=0x4018db0c,
pp_stack=0xbffff724, na=1)
    at ../Python/ceval.c:3108
#5  0x80868c6 in eval_frame (f=0x810afbc) at
../Python/ceval.c:1975
#6  0x80878b2 in PyEval_EvalCodeEx (co=0x4019b360,
globals=0x4015f2d4, 
    locals=0x4015f2d4, args=0x0, argcount=0, kws=0x0,
kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at ../Python/ceval.c:2553
#7  0x80898e0 in PyEval_EvalCode (co=0x4019b360,
globals=0x4015f2d4, 
    locals=0x4015f2d4) at ../Python/ceval.c:482
#8  0x80a42d1 in run_node (n=0x81402f8, filename=0xbffffb23
"/tmp/foo.py", 
    globals=0x4015f2d4, locals=0x4015f2d4, flags=0xbffff928)
    at ../Python/pythonrun.c:1088
#9  0x80a4282 in run_err_node (n=0x81402f8,
filename=0xbffffb23 "/tmp/foo.py", 
    globals=0x4015f2d4, locals=0x4015f2d4, flags=0xbffff928)
    at ../Python/pythonrun.c:1075
#10 0x80a3f01 in PyRun_FileExFlags (fp=0x8102cb0, 
    filename=0xbffffb23 "/tmp/foo.py", start=257,
globals=0x4015f2d4, 
    locals=0x4015f2d4, closeit=1, flags=0xbffff928)
    at ../Python/pythonrun.c:1066
#11 0x80a2af1 in PyRun_SimpleFileExFlags (fp=0x8102cb0, 
    filename=0xbffffb23 "/tmp/foo.py", closeit=1,
flags=0xbffff928)
    at ../Python/pythonrun.c:697
#12 0x80a3a63 in PyRun_AnyFileExFlags (fp=0x8102cb0, 
    filename=0xbffffb23 "/tmp/foo.py", closeit=1,
flags=0xbffff928)
    at ../Python/pythonrun.c:500
#13 0x805374d in Py_Main (argc=2, argv=0xbffff9b4) at
../Modules/main.c:368
#14 0x8052fea in main (argc=2, argv=0xbffff9b4) at
../Modules/python.c:10
#15 0x40077cbe in __libc_start_main () from /lib/libc.so.6


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-20 22:56

Message:
Logged In: YES 
user_id=31392

The latest CVS on the 2.2 maintenance branch also works
correctly.

I suspect you've hit a bug that is already fixed.  I'm
closing for now, but feel free to re-open if you can provoke
it with a current checkout from CVS.  If so, it would be
helpful if you could provide a stack trace from gdb.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-20 22:52

Message:
Logged In: YES 
user_id=31392

When I run the test script, python2.3 says:
654321123456

If I add a future statement to the script and run it with
2.2, I get a core dump.


----------------------------------------------------------------------

Comment By: Christophe Delord (cdelord)
Date: 2002-06-20 22:50

Message:
Logged In: YES 
user_id=566423

Of course, with a correct indentation, it is:

def flatten(L):
    for i in L:
        if type(i) == list:
            for j in flatten(i):
            yield j
        else:
            yield i

def mklist(n):
    if n:
        return [ str(n), mklist(n-1), str(n) ]
    else:
        return [] 

L = mklist(6)
print "".join(flatten(L))

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571885&group_id=5470



From noreply@sourceforge.net  Fri Jun 21 00:42:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 16:42:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-571885 ] Segmentation fault in Python 2.3
Message-ID: <E17LBZq-00013p-00@usw-sf-web1.sourceforge.net>

Bugs item #571885, was opened at 2002-06-21 00:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571885&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Christophe Delord (cdelord)
Assigned to: Jeremy Hylton (jhylton)
Summary: Segmentation fault in Python 2.3

Initial Comment:
It seems there's a bug in python 2.3

The following script works with python 2.2, not with 2.3

def flatten(L):
	for i in L: 
		if type(i) == list: 
			for j in flatten(i):
				yield j
		else:
			yield i 

def mklist(n):
	if n:
		return [ str(n), mklist(n-1), str(n) ] 
	else:
		return []
 
L = mklist(6) 
print "".join(flatten(L))
 
flatten seems to work but join makes a segmentation fault. 
 
It works fine with print "".join(list(flatten(L)))
or when L = mklist(4)

I'm using Python 2.3 with Linux (Redhat)

Best regards,
Christophe Delord.

----------------------------------------------------------------------

>Comment By: Christophe Delord (cdelord)
Date: 2002-06-21 01:42

Message:
Logged In: YES 
user_id=566423

I don't get the segmentation fault any more with this last
update.
Your reactivity is so impressive...
Thanks!

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-21 01:14

Message:
Logged In: YES 
user_id=31392

I think this is fixed in CVS now, but I'm waiting to close
the bug because I don't have a test case for it.  Thanks to
Neal for writing a good checkin message.  (Seriously.)


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-21 01:00

Message:
Logged In: YES 
user_id=31392

I was a bit hasty.  It doesn't dump core everytime, but it
does seem to dump core occasionally.  Here's a stack trace
from gdb:
#0  0x806ad98 in _PyTuple_Resize (pv=0xbffff5d8, newsize=12)
    at ../Objects/tupleobject.c:687
#1  0x80b746a in PySequence_Tuple (v=0x4019c72c) at
../Objects/abstract.c:1347
#2  0x80b94bf in PySequence_Fast (v=0x4019c72c, m=0x80d02dc "")
    at ../Objects/abstract.c:1444
#3  0x8065a71 in string_join (self=0x40148098, orig=0x4019c72c)
    at ../Objects/stringobject.c:1212
#4  0x8088166 in fast_cfunction (func=0x4018db0c,
pp_stack=0xbffff724, na=1)
    at ../Python/ceval.c:3108
#5  0x80868c6 in eval_frame (f=0x810afbc) at
../Python/ceval.c:1975
#6  0x80878b2 in PyEval_EvalCodeEx (co=0x4019b360,
globals=0x4015f2d4, 
    locals=0x4015f2d4, args=0x0, argcount=0, kws=0x0,
kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at ../Python/ceval.c:2553
#7  0x80898e0 in PyEval_EvalCode (co=0x4019b360,
globals=0x4015f2d4, 
    locals=0x4015f2d4) at ../Python/ceval.c:482
#8  0x80a42d1 in run_node (n=0x81402f8, filename=0xbffffb23
"/tmp/foo.py", 
    globals=0x4015f2d4, locals=0x4015f2d4, flags=0xbffff928)
    at ../Python/pythonrun.c:1088
#9  0x80a4282 in run_err_node (n=0x81402f8,
filename=0xbffffb23 "/tmp/foo.py", 
    globals=0x4015f2d4, locals=0x4015f2d4, flags=0xbffff928)
    at ../Python/pythonrun.c:1075
#10 0x80a3f01 in PyRun_FileExFlags (fp=0x8102cb0, 
    filename=0xbffffb23 "/tmp/foo.py", start=257,
globals=0x4015f2d4, 
    locals=0x4015f2d4, closeit=1, flags=0xbffff928)
    at ../Python/pythonrun.c:1066
#11 0x80a2af1 in PyRun_SimpleFileExFlags (fp=0x8102cb0, 
    filename=0xbffffb23 "/tmp/foo.py", closeit=1,
flags=0xbffff928)
    at ../Python/pythonrun.c:697
#12 0x80a3a63 in PyRun_AnyFileExFlags (fp=0x8102cb0, 
    filename=0xbffffb23 "/tmp/foo.py", closeit=1,
flags=0xbffff928)
    at ../Python/pythonrun.c:500
#13 0x805374d in Py_Main (argc=2, argv=0xbffff9b4) at
../Modules/main.c:368
#14 0x8052fea in main (argc=2, argv=0xbffff9b4) at
../Modules/python.c:10
#15 0x40077cbe in __libc_start_main () from /lib/libc.so.6


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-21 00:56

Message:
Logged In: YES 
user_id=31392

The latest CVS on the 2.2 maintenance branch also works
correctly.

I suspect you've hit a bug that is already fixed.  I'm
closing for now, but feel free to re-open if you can provoke
it with a current checkout from CVS.  If so, it would be
helpful if you could provide a stack trace from gdb.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-21 00:52

Message:
Logged In: YES 
user_id=31392

When I run the test script, python2.3 says:
654321123456

If I add a future statement to the script and run it with
2.2, I get a core dump.


----------------------------------------------------------------------

Comment By: Christophe Delord (cdelord)
Date: 2002-06-21 00:50

Message:
Logged In: YES 
user_id=566423

Of course, with a correct indentation, it is:

def flatten(L):
    for i in L:
        if type(i) == list:
            for j in flatten(i):
            yield j
        else:
            yield i

def mklist(n):
    if n:
        return [ str(n), mklist(n-1), str(n) ]
    else:
        return [] 

L = mklist(6)
print "".join(flatten(L))

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571885&group_id=5470



From noreply@sourceforge.net  Fri Jun 21 00:45:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 20 Jun 2002 16:45:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-571334 ] imaplib fetch is broken
Message-ID: <E17LBca-0000hD-00@usw-sf-web2.sourceforge.net>

Bugs item #571334, was opened at 2002-06-19 16:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571334&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Goerzen (jgoerzen)
Assigned to: Piers Lauder (pierslauder)
Summary: imaplib fetch is broken

Initial Comment:
This bug is 100% reproducible in Python 2.2.1 and the 
imaplib.py from Python's CVS tree. 
 
They'll send the message body in this form: 
{100} 
Headers here, body here, (100 characters worth) 
 
This is specified in RFC2060 secion 4.3.  imaplib's fetch 
chokes on 
"unexpected data" in the response. 
 
imaplib should receive this prefix-quoted string properly 
and return it in a 
non-quoted fashion. 
 
As it is, it is totally impossible to read messages from 
most imap servers. 
 

----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 2002-06-20 18:45

Message:
Logged In: YES 
user_id=491567

Note, though, that AFAIK there is no canonical code for 
"read" in python like there is in C.  File objects have a read(), 
socket objects have a read, StringIO has a read, and in this 
case, SSL sockets have a read. 
 
I suspect that it could be an issue unique to SSL sockets. 
 
I'm using Python 2.2.1 with the imaplib.py pulled from the 
development tree's CVS as of two days ago.  Sorry, I don't 
know the exact version number.  I needed that one for the SSL 
support. 
 
It is possible that this could be considered a bug in the SSL 
socket support.  I find it highly annoying that, among other 
things, imaplib.py has to kludge around socket.ssl's lack of 
readline(). 

----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-20 17:45

Message:
Logged In: YES 
user_id=196212

PS: could you also state which imaplib class you are using -
there may be a difference between the socket.socket and
socket.ssl behaviours.


----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-20 17:37

Message:
Logged In: YES 
user_id=196212

I'm very surprised by this. According to the Python library
manual for the read method:

read([size])
 Read at most size bytes from the file (less if the read
hits EOF before obtaining size bytes). If the size argument
is negative or omitted, read all data until EOF is reached.
The bytes are returned as a string object. An empty string
is returned when EOF is encountered immediately. (For
certain files, like ttys, it makes sense to continue reading
after an EOF is hit.) Note that this method may call the
underlying C function fread() more than once in an effort to
acquire as close to size bytes as possible.

So read(size) should return size bytes unless EOF is found.
(And as imaplib has been in use for several years, I take it
the manual is factual :-)

Maybe this is an O/S-specific problem in the python interpreter?
What O/S (and version) is your Python 2.2.1 interpreter
running on?


----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 2002-06-20 09:01

Message:
Logged In: YES 
user_id=491567

It turns out that it is a bug in read() in the imaplib.  It does not 
obey the principle that the read() call will return UP TO the 
amount of bytes specified.  The below diff fixes it for me.  I 
have not yet tried append(), but I suspect that the write calls 
will have the same problem. 
 
--- imaplib.py  18 Jun 2002 15:36:03 -0000      1.1 
+++ imaplib.py  20 Jun 2002 04:02:49 -0000      1.2 
@@ -222,8 +222,10 @@ 
 
     def read(self, size): 
         """Read 'size' bytes from remote.""" 
-        return self.file.read(size) 
- 
+        retval = '' 
+        while len(retval) < size: 
+            retval += self.file.read(size - len(retval)) 
+        return retval 
 
     def readline(self): 
         """Read line from remote.""" 
@@ -1056,7 +1059,10 @@ 
 
     def read(self, size): 
         """Read 'size' bytes from remote.""" 
-        return self.sslobj.read(size) 
+        retval = '' 
+        while len(retval) < size: 
+            retval += self.sslobj.read(size - len(retval)) 
+        return retval 
 
 
     def readline(self): 
 

----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-20 03:46

Message:
Logged In: YES 
user_id=196212

I can't duplicate this.

The test code at the end of imaplib.py includes a FETCH
command which is returned as a literal by my imap server.

Perhaps you could run that test on your server and cut
and paste the response.

Run the test like this:
  python2.2 imaplib.py -d5 <imap_server_host_name>

>From which I get the following:
	...
 43:26.15 > KDP19 UID FETCH 19570 (FLAGS INTERNALDATE
RFC822.SIZE RFC822.HEADER RFC822.TEXT)
  43:26.46 < * 83 FETCH (UID 19570 FLAGS (\Seen)
INTERNALDATE "20-Jun-2002 18:36:51 +1000" RFC822.SIZE 55
RFC822.HEADER {46}
  43:26.46      matched r'\* (?P<data>\d+)
(?P<type>[A-Z-]+)( (?P<data2>.*))?' => ('83', 'FETCH', '
(UID 19570 FLAGS (\Seen) INTERNALDATE "20-Jun-2002 18:36:51
+1000" RFC822.SIZE 55 RFC822.HEADER {46}', '(UID 19570 FLAGS
(\Seen) INTERNALDATE "20-Jun-2002 18:36:51 +1000"
RFC822.SIZE 55 RFC822.HEADER {46}')
  43:26.46      matched r'.*{(?P<size>\d+)}$' => ('46',)
  43:26.47 read literal size 46
	...
and so on.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571334&group_id=5470



From noreply@sourceforge.net  Fri Jun 21 13:48:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 21 Jun 2002 05:48:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-572059 ] Config test for case-insensitive filesys
Message-ID: <E17LNqT-0004cX-00@usw-sf-web1.sourceforge.net>

Bugs item #572059, was opened at 2002-06-21 14:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=572059&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Config test for case-insensitive filesys

Initial Comment:
The configure test for case-insensitive file systems (so it nows to add ".exe" after the Python executable in the build directory) fails if you do the configure in a separate build directory. Actually: it fails the first time, a second time the local Python subdirectory is already created and the test works fine.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=572059&group_id=5470



From noreply@sourceforge.net  Fri Jun 21 16:07:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 21 Jun 2002 08:07:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-572059 ] Config test for case-insensitive filesys
Message-ID: <E17LQ0h-0007Et-00@usw-sf-web1.sourceforge.net>

Bugs item #572059, was opened at 2002-06-21 14:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=572059&group_id=5470

Category: Build
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Config test for case-insensitive filesys

Initial Comment:
The configure test for case-insensitive file systems (so it nows to add ".exe" after the Python executable in the build directory) fails if you do the configure in a separate build directory. Actually: it fails the first time, a second time the local Python subdirectory is already created and the test works fine.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-06-21 17:07

Message:
Logged In: YES 
user_id=45365

Turns out Tony Lownds path #557719 also fixed this.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=572059&group_id=5470



From noreply@sourceforge.net  Fri Jun 21 17:18:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 21 Jun 2002 09:18:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-511737 ] ConfigParser bug/limitation
Message-ID: <E17LR7U-0000Nh-00@usw-sf-web1.sourceforge.net>

Bugs item #511737, was opened at 2002-02-01 10:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=511737&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Loïc Lefort (loicl)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: ConfigParser bug/limitation

Initial Comment:
It is not possible to use '%' character in config
options in combination with $() substitution.
Example: Given this configuration file:

[DEFAULT]
option1=xxx
option2=%(option1)s/xxx

ok=%(option1)s/%%s
not_ok=%(option2)s/%%s

config.get('DEFAULT', 'ok') returns xxx/%s
but config.get('DEFAULT', 'not_ok') fails with an
exception because the '%' needs to be escaped multiple
times depending on the evaluation depth:

%(option2)s/%%s -> %(option1)s/xxx/%s -> exception

what I would like it to do is:
%(option2)s/%%s -> %(option1)s/xxx/%%s -> xxx/xxx/%s

Attached to this bug report is a simple patch to work
around this limitation (not very elegant, but it works)



----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-21 12:18

Message:
Logged In: YES 
user_id=3066

Re-arranged summary so all ConfigParser reports can be
sorted together.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-17 11:19

Message:
Logged In: YES 
user_id=3066

I'm afraid getting this "right" is going to be much more
tedious that the proposed patch.  It's unclear to me at the
moment whether this should be a documented limitation or if
we should really fix it.  The ConfigParser module is
generally in bad shape, unfortunately.  ;-(

----------------------------------------------------------------------

Comment By: Loïc Lefort (loicl)
Date: 2002-02-01 10:38

Message:
Logged In: YES 
user_id=78862

Forgot the python version: this problem is present in both
python 2.1.2 and python 2.2

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=511737&group_id=5470



From noreply@sourceforge.net  Fri Jun 21 17:43:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 21 Jun 2002 09:43:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-546434 ] buffer slice type inconsistant
Message-ID: <E17LRVB-0000Dy-00@usw-sf-web4.sourceforge.net>

Bugs item #546434, was opened at 2002-04-20 02:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546434&group_id=5470

Category: Python Interpreter Core
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Donald Wallace Rouse II (dwr2)
Assigned to: Guido van Rossum (gvanrossum)
Summary: buffer slice type inconsistant

Initial Comment:
The type of a buffer slice is either 'buffer' 
or 'str', depending on the slice parameters.
If the slice encompasses the entire buffer, the buffer 
itself is returned.
Otherwise, a string is returned.
Here is a sample session:
--------------------------
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
IDLE 0.8 -- press F1 for help
>>> a="0123456789"
>>> b = buffer(a, 1, 8)
>>> b
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[:]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[:8]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[2:4]
'34'
>>> b[5]
'6'
>>> c = buffer(a, 4, 1)
>>> c
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C8, size 
1 at 0x00AAA370>
>>> c[0]
'4'
>>> c[0:1]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C8, size 
1 at 0x00AAA370>
--------------------------
Either b[:] should produce a string, or, more 
preferably, b[x:y] should be equivalent to buffer(b, 
x, y), and c[0] should be equivalent to buffer(c, 0, 
1).
The reason that the types should be similar is because 
if a buffer is passed to a function that's checking 
for strings, the function should always fail or always 
succeed.

This is especially important because types.BufferType 
isn't in the types.StringTypes list, so the 
expression "type(b) in types.StringTypes" will also 
behave inconsistantly.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-21 11:43

Message:
Logged In: YES 
user_id=80475

I can make a fix as you specified by nullifying the 
sq_repeat slot and having the slice routines always return 
a new buffer object.

Still, I'm not sure that that is right thing to do.  All other 
sequence behaviors are defined, so it seems weird to zap 
repetition (though I can't see a use case for it).

Also, I original opted to return strings instead of buffers for 
several reasons.  My reading of the OP was that either way 
was fine as long as it was consistent.  Also, I think it is 
more likely that existing code relies on returning a string 
instead of a buffer (impossible to verify though; I rarely 
see buffer used) as in: print mybuf[2:8].  Buffer appears to 
be designed to be as stringlike as possible so that it can 
be easily substituted in code originally designed for strings.

If you still think returning a buffer is the way to go, I'm 
happy to do it.  One other thought, currently mybuf[:] 
returns self but I think it should return a copy of self to be 
consistent with the idiom:  
   b = a[:]
   assert id(a) != id(b)

Do you want someone else to review this while your out or 
for me to just take care of it?



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-20 13:00

Message:
Logged In: YES 
user_id=6380

Hm, shoudldn't slicing a buffer always return a buffer
object? That's what the OP requested and seems to be the
most consistent. (On the other hand getting a single item
with b[i] should return a character.)

I think that repetition on a buffer object should be an error.

This would be a semantic change that can't be backported to 2.2.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-20 02:35

Message:
Logged In: YES 
user_id=80475

Added Py2.3 patch to make slicing and repetition always 
return a string.  Unsure if it is a 2.2 backport candidate.



----------------------------------------------------------------------

Comment By: Donald Wallace Rouse II (dwr2)
Date: 2002-04-20 02:36

Message:
Logged In: YES 
user_id=111611

Sorry about the formatting; the form wrapped the lines.
A slight correction:
  "b[x:y] should be equivalent to buffer(b, x, y)"
should be
"b[x:y] should be equivalent to buffer(b, x1, y1 - x1), 
where x1 == x if x is positive and len(b) + x if x is 
negative, and similarly for y and y1".

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546434&group_id=5470



From noreply@sourceforge.net  Fri Jun 21 17:57:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 21 Jun 2002 09:57:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-546434 ] buffer slice type inconsistant
Message-ID: <E17LRjN-0000YF-00@usw-sf-web4.sourceforge.net>

Bugs item #546434, was opened at 2002-04-20 03:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546434&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Donald Wallace Rouse II (dwr2)
Assigned to: Guido van Rossum (gvanrossum)
Summary: buffer slice type inconsistant

Initial Comment:
The type of a buffer slice is either 'buffer' 
or 'str', depending on the slice parameters.
If the slice encompasses the entire buffer, the buffer 
itself is returned.
Otherwise, a string is returned.
Here is a sample session:
--------------------------
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
IDLE 0.8 -- press F1 for help
>>> a="0123456789"
>>> b = buffer(a, 1, 8)
>>> b
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[:]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[:8]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[2:4]
'34'
>>> b[5]
'6'
>>> c = buffer(a, 4, 1)
>>> c
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C8, size 
1 at 0x00AAA370>
>>> c[0]
'4'
>>> c[0:1]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C8, size 
1 at 0x00AAA370>
--------------------------
Either b[:] should produce a string, or, more 
preferably, b[x:y] should be equivalent to buffer(b, 
x, y), and c[0] should be equivalent to buffer(c, 0, 
1).
The reason that the types should be similar is because 
if a buffer is passed to a function that's checking 
for strings, the function should always fail or always 
succeed.

This is especially important because types.BufferType 
isn't in the types.StringTypes list, so the 
expression "type(b) in types.StringTypes" will also 
behave inconsistantly.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-21 12:57

Message:
Logged In: YES 
user_id=6380

I think it's best to ask python-dev's opinion on this,
especially as I'm on vacation. :-)

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-21 12:43

Message:
Logged In: YES 
user_id=80475

I can make a fix as you specified by nullifying the 
sq_repeat slot and having the slice routines always return 
a new buffer object.

Still, I'm not sure that that is right thing to do.  All other 
sequence behaviors are defined, so it seems weird to zap 
repetition (though I can't see a use case for it).

Also, I original opted to return strings instead of buffers for 
several reasons.  My reading of the OP was that either way 
was fine as long as it was consistent.  Also, I think it is 
more likely that existing code relies on returning a string 
instead of a buffer (impossible to verify though; I rarely 
see buffer used) as in: print mybuf[2:8].  Buffer appears to 
be designed to be as stringlike as possible so that it can 
be easily substituted in code originally designed for strings.

If you still think returning a buffer is the way to go, I'm 
happy to do it.  One other thought, currently mybuf[:] 
returns self but I think it should return a copy of self to be 
consistent with the idiom:  
   b = a[:]
   assert id(a) != id(b)

Do you want someone else to review this while your out or 
for me to just take care of it?



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-20 14:00

Message:
Logged In: YES 
user_id=6380

Hm, shoudldn't slicing a buffer always return a buffer
object? That's what the OP requested and seems to be the
most consistent. (On the other hand getting a single item
with b[i] should return a character.)

I think that repetition on a buffer object should be an error.

This would be a semantic change that can't be backported to 2.2.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-20 03:35

Message:
Logged In: YES 
user_id=80475

Added Py2.3 patch to make slicing and repetition always 
return a string.  Unsure if it is a 2.2 backport candidate.



----------------------------------------------------------------------

Comment By: Donald Wallace Rouse II (dwr2)
Date: 2002-04-20 03:36

Message:
Logged In: YES 
user_id=111611

Sorry about the formatting; the form wrapped the lines.
A slight correction:
  "b[x:y] should be equivalent to buffer(b, x, y)"
should be
"b[x:y] should be equivalent to buffer(b, x1, y1 - x1), 
where x1 == x if x is positive and len(b) + x if x is 
negative, and similarly for y and y1".

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546434&group_id=5470



From noreply@sourceforge.net  Fri Jun 21 17:58:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 21 Jun 2002 09:58:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-546434 ] buffer slice type inconsistant
Message-ID: <E17LRjb-0001FM-00@usw-sf-web2.sourceforge.net>

Bugs item #546434, was opened at 2002-04-20 03:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546434&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Donald Wallace Rouse II (dwr2)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: buffer slice type inconsistant

Initial Comment:
The type of a buffer slice is either 'buffer' 
or 'str', depending on the slice parameters.
If the slice encompasses the entire buffer, the buffer 
itself is returned.
Otherwise, a string is returned.
Here is a sample session:
--------------------------
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
IDLE 0.8 -- press F1 for help
>>> a="0123456789"
>>> b = buffer(a, 1, 8)
>>> b
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[:]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[:8]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[2:4]
'34'
>>> b[5]
'6'
>>> c = buffer(a, 4, 1)
>>> c
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C8, size 
1 at 0x00AAA370>
>>> c[0]
'4'
>>> c[0:1]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C8, size 
1 at 0x00AAA370>
--------------------------
Either b[:] should produce a string, or, more 
preferably, b[x:y] should be equivalent to buffer(b, 
x, y), and c[0] should be equivalent to buffer(c, 0, 
1).
The reason that the types should be similar is because 
if a buffer is passed to a function that's checking 
for strings, the function should always fail or always 
succeed.

This is especially important because types.BufferType 
isn't in the types.StringTypes list, so the 
expression "type(b) in types.StringTypes" will also 
behave inconsistantly.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-21 12:57

Message:
Logged In: YES 
user_id=6380

I think it's best to ask python-dev's opinion on this,
especially as I'm on vacation. :-)

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-21 12:43

Message:
Logged In: YES 
user_id=80475

I can make a fix as you specified by nullifying the 
sq_repeat slot and having the slice routines always return 
a new buffer object.

Still, I'm not sure that that is right thing to do.  All other 
sequence behaviors are defined, so it seems weird to zap 
repetition (though I can't see a use case for it).

Also, I original opted to return strings instead of buffers for 
several reasons.  My reading of the OP was that either way 
was fine as long as it was consistent.  Also, I think it is 
more likely that existing code relies on returning a string 
instead of a buffer (impossible to verify though; I rarely 
see buffer used) as in: print mybuf[2:8].  Buffer appears to 
be designed to be as stringlike as possible so that it can 
be easily substituted in code originally designed for strings.

If you still think returning a buffer is the way to go, I'm 
happy to do it.  One other thought, currently mybuf[:] 
returns self but I think it should return a copy of self to be 
consistent with the idiom:  
   b = a[:]
   assert id(a) != id(b)

Do you want someone else to review this while your out or 
for me to just take care of it?



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-20 14:00

Message:
Logged In: YES 
user_id=6380

Hm, shoudldn't slicing a buffer always return a buffer
object? That's what the OP requested and seems to be the
most consistent. (On the other hand getting a single item
with b[i] should return a character.)

I think that repetition on a buffer object should be an error.

This would be a semantic change that can't be backported to 2.2.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-20 03:35

Message:
Logged In: YES 
user_id=80475

Added Py2.3 patch to make slicing and repetition always 
return a string.  Unsure if it is a 2.2 backport candidate.



----------------------------------------------------------------------

Comment By: Donald Wallace Rouse II (dwr2)
Date: 2002-04-20 03:36

Message:
Logged In: YES 
user_id=111611

Sorry about the formatting; the form wrapped the lines.
A slight correction:
  "b[x:y] should be equivalent to buffer(b, x, y)"
should be
"b[x:y] should be equivalent to buffer(b, x1, y1 - x1), 
where x1 == x if x is positive and len(b) + x if x is 
negative, and similarly for y and y1".

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546434&group_id=5470



From noreply@sourceforge.net  Fri Jun 21 18:22:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 21 Jun 2002 10:22:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-572169 ] Incorrect example in 4.2.6
Message-ID: <E17LS74-0001cm-00@usw-sf-web1.sourceforge.net>

Bugs item #572169, was opened at 2002-06-21 10:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=572169&group_id=5470

Category: Documentation
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Chamberlain (echamberlain)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Incorrect example in 4.2.6

Initial Comment:
The RE equivalent for the %x %X scanf function is 
incorrect.  The RE pattern should be
 0[xX][\dA-Fa-f]+

It is the trailing "+" that is missing.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=572169&group_id=5470



From noreply@sourceforge.net  Sat Jun 22 00:14:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 21 Jun 2002 16:14:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-572341 ] IM parses code in docstrings
Message-ID: <E17LXbN-0008Hc-00@usw-sf-web1.sourceforge.net>

Bugs item #572341, was opened at 2002-06-22 09:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=572341&group_id=5470

Category: Demos and Tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Adrian van den Dries (cantanker)
Assigned to: Nobody/Anonymous (nobody)
Summary: IM parses code in docstrings

Initial Comment:
When reading a file with code examples, the IM menu
parses the code in the docstrings and ignores the real
code!

For  a real example, see Twisted's twisted.usage.py, or
try this example:

# module life

"""
for the meaning of life, try this:
    class MyMeaning(life.Meaning):
        def __init__(self, foo):
            self.foo = foo
"""

# real code follows

class Meaning:
    def ferfoo(self):
        if self.foo:
            return self.foo
        else:
            return None


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=572341&group_id=5470



From noreply@sourceforge.net  Sat Jun 22 00:22:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 21 Jun 2002 16:22:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-572341 ] python-mode IM parses code in docstrings
Message-ID: <E17LXjf-00007K-00@usw-sf-web1.sourceforge.net>

Bugs item #572341, was opened at 2002-06-22 09:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=572341&group_id=5470

Category: Demos and Tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Adrian van den Dries (cantanker)
Assigned to: Nobody/Anonymous (nobody)
>Summary: python-mode IM parses code in docstrings

Initial Comment:
When reading a file with code examples, the IM menu
parses the code in the docstrings and ignores the real
code!

For  a real example, see Twisted's twisted.usage.py, or
try this example:

# module life

"""
for the meaning of life, try this:
    class MyMeaning(life.Meaning):
        def __init__(self, foo):
            self.foo = foo
"""

# real code follows

class Meaning:
    def ferfoo(self):
        if self.foo:
            return self.foo
        else:
            return None


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=572341&group_id=5470



From noreply@sourceforge.net  Sat Jun 22 02:08:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 21 Jun 2002 18:08:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-572169 ] Incorrect example in 4.2.6
Message-ID: <E17LZO9-0004NN-00@usw-sf-web5.sourceforge.net>

Bugs item #572169, was opened at 2002-06-21 13:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=572169&group_id=5470

Category: Documentation
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Eric Chamberlain (echamberlain)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Incorrect example in 4.2.6

Initial Comment:
The RE equivalent for the %x %X scanf function is 
incorrect.  The RE pattern should be
 0[xX][\dA-Fa-f]+

It is the trailing "+" that is missing.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-21 21:08

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/lib/libre.tex revisions 1.84 and 1.73.6.7.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=572169&group_id=5470



From noreply@sourceforge.net  Sat Jun 22 02:38:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 21 Jun 2002 18:38:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-545096 ] ConfigParser code cleanup
Message-ID: <E17LZrX-0002SX-00@usw-sf-web1.sourceforge.net>

Bugs item #545096, was opened at 2002-04-17 06:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545096&group_id=5470

>Category: None
>Group: None
>Status: Open
Resolution: None
Priority: 5
Submitted By: Gustavo Niemeyer (niemeyer)
>Assigned to: Nobody/Anonymous (nobody)
Summary: ConfigParser code cleanup

Initial Comment:
The first patch fixes a bug, implements some speed 
improvements, some memory consumption improvements, 
enforces the usage of the already available global 
variables, and extends the allowed chars in option 
names to be very permissive. 
 
The second one, if used, is supposed to be applied 
over the first one, and implements a walk() 
generator method for walking trough the options of a 
section. 

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-21 21:38

Message:
Logged In: YES 
user_id=3066

Changed to a "bug" report even though it's a patch, so that
all the ConfigParser reports can show up together.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-21 13:22

Message:
Logged In: YES 
user_id=3066

I'd like to accept a variation on this patch.

Specifically, I'd like "section in self.sections()" tests to
become "sections in self.__sections" consistently; your
proposed patch is better than the original, but as long as
we're not supporting subclassing in this way, let's go ahead
and use the better-performing solution.

I'll accept the use of MAX_INTERPOLATION_DEPTH and your
changes to the interpolation loop, but the loop itself will
probably be re-written later, in response to SF bug #511737.

The walk() method will need documentation.

Can you prepare a new patch for this?

Thanks!

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-21 12:20

Message:
Logged In: YES 
user_id=3066

Ken appears non-responsive, re-assigning to me.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-12 21:42

Message:
Logged In: YES 
user_id=3066

Ken, can you recall our thinking on the use of the constant
for MAX_INTERPOLATION_DEPTH when this was first written?  I
think you were more involved in this than the rest of us at
the time.

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2002-06-03 17:45

Message:
Logged In: YES 
user_id=7887

Hello Fred! 
 
- About has_section(), I thought about the possibility of subclassing it. But, 
besides agreeing with you on the messy code matter, other functions 
weren't (and still aren't) considering this possibility, so I doubt some one will 
be able to subclass it anyways. Anyway, I may change the patch to use 
whatever you suggest. 
 
- About MAX_INTERPOLATION_DEPTH, I understand your position of 
wanting "a safety net", but my intention of using it in the code was not to 
let the user change it, but to clarify and give consistence to the code. I think 
using literal constants in the code is not a good measure at all. If this was 
adopted, many modules would have to be changed (in a bad way) for 
consistence. With a quick look at the library, I was able to find smtpd.py, 
base64.py, binhex.py, cgi.py, cmd.py, and many others using similar purpose 
constants. You'll probably agree with me if you think about this more 
extensively. 
 

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-30 12:11

Message:
Logged In: YES 
user_id=3066

I should clarify:  By "retain the use of the constant" I
mean the constant numeric literal, not MAX_INTERPOLATION_DEPTH.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-30 12:06

Message:
Logged In: YES 
user_id=3066

Two comments:

- "section in self.__sections.keys()" can be written
  (still more efficiently) as "section in self.__sections",
  *but* the use of the sections() method is done to be
  subclass-friendly.  I'm not sure how important this is
  since I can't imagine anyone actually subclassing
  from such a mass of messy code.  Perhaps these
  could be modified to use the has_section() method,
  which is relatively new.

- MAX_INTERPOLATION_DEPTH was not "honored"
  in the code since it's really a safety net; there's no
  intention that client code be able to change it.  (The
  sanity of the value is not checked before use.)  I'm
  inclined to retain the use of the constant in the
  interpolation code, and add a comment above the
  constant the it exists for informational purposes only.

Otherwise, I'm fine with the patch.  ;-)
Sorry for the delay in responding to this.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 13:55

Message:
Logged In: YES 
user_id=6380

I'm assigning this to Fred Drake, who has some opinions on
ConfigParser.

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2002-04-18 13:07

Message:
Logged In: YES 
user_id=7887

I'd rather explain here the patch that changes behavior, 
since it's pretty small. This line in the regular 
expression OPTCRE: 
 
r'(?P<option>[]\-[\w_.*,(){}]+)' 
 
was replaced by: 
 
r'(?P<option>[^:=\s]+)' 
 
So that instead of giving a range of characters which may 
be part of the option name, it just looks for the 
separator chars and spaces. This behavior is already used 
in the headers, and I haven't found any good reason to 
deny usage of other characters as option names. 
 
In the same regular expression, I've also replaced 
'[ \t]' by '\s', but this shouln't change the current 
behavior at all. 
 
About the walk patch, I have no idea why it isn't 
attached. I remember to have checked the ticked, and it 
was there. Anyway, I'm attaching it again. 

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-18 02:04

Message:
Logged In: YES 
user_id=21627

I'd like to see this split into even more parts: a patch
that supposedly has *no* semantic change (ie. the speed
improvements, memory consumption improvements, use of global
variables); a patch that changes behavior (please explain in
which ways); and the patch that implements walk (which
appears to be missing currently).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545096&group_id=5470



From noreply@sourceforge.net  Sat Jun 22 02:44:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 21 Jun 2002 18:44:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-545096 ] ConfigParser code cleanup
Message-ID: <E17LZwg-0005Cz-00@usw-sf-web4.sourceforge.net>

Bugs item #545096, was opened at 2002-04-17 06:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545096&group_id=5470

>Category: Python Library
Group: None
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Gustavo Niemeyer (niemeyer)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: ConfigParser code cleanup

Initial Comment:
The first patch fixes a bug, implements some speed 
improvements, some memory consumption improvements, 
enforces the usage of the already available global 
variables, and extends the allowed chars in option 
names to be very permissive. 
 
The second one, if used, is supposed to be applied 
over the first one, and implements a walk() 
generator method for walking trough the options of a 
section. 

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-21 21:38

Message:
Logged In: YES 
user_id=3066

Changed to a "bug" report even though it's a patch, so that
all the ConfigParser reports can show up together.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-21 13:22

Message:
Logged In: YES 
user_id=3066

I'd like to accept a variation on this patch.

Specifically, I'd like "section in self.sections()" tests to
become "sections in self.__sections" consistently; your
proposed patch is better than the original, but as long as
we're not supporting subclassing in this way, let's go ahead
and use the better-performing solution.

I'll accept the use of MAX_INTERPOLATION_DEPTH and your
changes to the interpolation loop, but the loop itself will
probably be re-written later, in response to SF bug #511737.

The walk() method will need documentation.

Can you prepare a new patch for this?

Thanks!

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-21 12:20

Message:
Logged In: YES 
user_id=3066

Ken appears non-responsive, re-assigning to me.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-12 21:42

Message:
Logged In: YES 
user_id=3066

Ken, can you recall our thinking on the use of the constant
for MAX_INTERPOLATION_DEPTH when this was first written?  I
think you were more involved in this than the rest of us at
the time.

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2002-06-03 17:45

Message:
Logged In: YES 
user_id=7887

Hello Fred! 
 
- About has_section(), I thought about the possibility of subclassing it. But, 
besides agreeing with you on the messy code matter, other functions 
weren't (and still aren't) considering this possibility, so I doubt some one will 
be able to subclass it anyways. Anyway, I may change the patch to use 
whatever you suggest. 
 
- About MAX_INTERPOLATION_DEPTH, I understand your position of 
wanting "a safety net", but my intention of using it in the code was not to 
let the user change it, but to clarify and give consistence to the code. I think 
using literal constants in the code is not a good measure at all. If this was 
adopted, many modules would have to be changed (in a bad way) for 
consistence. With a quick look at the library, I was able to find smtpd.py, 
base64.py, binhex.py, cgi.py, cmd.py, and many others using similar purpose 
constants. You'll probably agree with me if you think about this more 
extensively. 
 

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-30 12:11

Message:
Logged In: YES 
user_id=3066

I should clarify:  By "retain the use of the constant" I
mean the constant numeric literal, not MAX_INTERPOLATION_DEPTH.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-30 12:06

Message:
Logged In: YES 
user_id=3066

Two comments:

- "section in self.__sections.keys()" can be written
  (still more efficiently) as "section in self.__sections",
  *but* the use of the sections() method is done to be
  subclass-friendly.  I'm not sure how important this is
  since I can't imagine anyone actually subclassing
  from such a mass of messy code.  Perhaps these
  could be modified to use the has_section() method,
  which is relatively new.

- MAX_INTERPOLATION_DEPTH was not "honored"
  in the code since it's really a safety net; there's no
  intention that client code be able to change it.  (The
  sanity of the value is not checked before use.)  I'm
  inclined to retain the use of the constant in the
  interpolation code, and add a comment above the
  constant the it exists for informational purposes only.

Otherwise, I'm fine with the patch.  ;-)
Sorry for the delay in responding to this.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 13:55

Message:
Logged In: YES 
user_id=6380

I'm assigning this to Fred Drake, who has some opinions on
ConfigParser.

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2002-04-18 13:07

Message:
Logged In: YES 
user_id=7887

I'd rather explain here the patch that changes behavior, 
since it's pretty small. This line in the regular 
expression OPTCRE: 
 
r'(?P<option>[]\-[\w_.*,(){}]+)' 
 
was replaced by: 
 
r'(?P<option>[^:=\s]+)' 
 
So that instead of giving a range of characters which may 
be part of the option name, it just looks for the 
separator chars and spaces. This behavior is already used 
in the headers, and I haven't found any good reason to 
deny usage of other characters as option names. 
 
In the same regular expression, I've also replaced 
'[ \t]' by '\s', but this shouln't change the current 
behavior at all. 
 
About the walk patch, I have no idea why it isn't 
attached. I remember to have checked the ticked, and it 
was there. Anyway, I'm attaching it again. 

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-18 02:04

Message:
Logged In: YES 
user_id=21627

I'd like to see this split into even more parts: a patch
that supposedly has *no* semantic change (ie. the speed
improvements, memory consumption improvements, use of global
variables); a patch that changes behavior (please explain in
which ways); and the patch that implements walk (which
appears to be missing currently).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545096&group_id=5470



From noreply@sourceforge.net  Sat Jun 22 03:14:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 21 Jun 2002 19:14:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-545096 ] ConfigParser code cleanup
Message-ID: <E17LaPh-0002uY-00@usw-sf-web1.sourceforge.net>

Bugs item #545096, was opened at 2002-04-17 10:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545096&group_id=5470

Category: Python Library
Group: None
>Status: Open
Resolution: None
Priority: 5
Submitted By: Gustavo Niemeyer (niemeyer)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: ConfigParser code cleanup

Initial Comment:
The first patch fixes a bug, implements some speed 
improvements, some memory consumption improvements, 
enforces the usage of the already available global 
variables, and extends the allowed chars in option 
names to be very permissive. 
 
The second one, if used, is supposed to be applied 
over the first one, and implements a walk() 
generator method for walking trough the options of a 
section. 

----------------------------------------------------------------------

>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2002-06-22 02:14

Message:
Logged In: YES 
user_id=7887

Thanks for your review Fred!  
  
I'll fix the patch as suggested, and work on a solution for the referred bug 
as well.   

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-22 01:38

Message:
Logged In: YES 
user_id=3066

Changed to a "bug" report even though it's a patch, so that
all the ConfigParser reports can show up together.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-21 17:22

Message:
Logged In: YES 
user_id=3066

I'd like to accept a variation on this patch.

Specifically, I'd like "section in self.sections()" tests to
become "sections in self.__sections" consistently; your
proposed patch is better than the original, but as long as
we're not supporting subclassing in this way, let's go ahead
and use the better-performing solution.

I'll accept the use of MAX_INTERPOLATION_DEPTH and your
changes to the interpolation loop, but the loop itself will
probably be re-written later, in response to SF bug #511737.

The walk() method will need documentation.

Can you prepare a new patch for this?

Thanks!

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-21 16:20

Message:
Logged In: YES 
user_id=3066

Ken appears non-responsive, re-assigning to me.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-13 01:42

Message:
Logged In: YES 
user_id=3066

Ken, can you recall our thinking on the use of the constant
for MAX_INTERPOLATION_DEPTH when this was first written?  I
think you were more involved in this than the rest of us at
the time.

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2002-06-03 21:45

Message:
Logged In: YES 
user_id=7887

Hello Fred! 
 
- About has_section(), I thought about the possibility of subclassing it. But, 
besides agreeing with you on the messy code matter, other functions 
weren't (and still aren't) considering this possibility, so I doubt some one will 
be able to subclass it anyways. Anyway, I may change the patch to use 
whatever you suggest. 
 
- About MAX_INTERPOLATION_DEPTH, I understand your position of 
wanting "a safety net", but my intention of using it in the code was not to 
let the user change it, but to clarify and give consistence to the code. I think 
using literal constants in the code is not a good measure at all. If this was 
adopted, many modules would have to be changed (in a bad way) for 
consistence. With a quick look at the library, I was able to find smtpd.py, 
base64.py, binhex.py, cgi.py, cmd.py, and many others using similar purpose 
constants. You'll probably agree with me if you think about this more 
extensively. 
 

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-30 16:11

Message:
Logged In: YES 
user_id=3066

I should clarify:  By "retain the use of the constant" I
mean the constant numeric literal, not MAX_INTERPOLATION_DEPTH.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-30 16:06

Message:
Logged In: YES 
user_id=3066

Two comments:

- "section in self.__sections.keys()" can be written
  (still more efficiently) as "section in self.__sections",
  *but* the use of the sections() method is done to be
  subclass-friendly.  I'm not sure how important this is
  since I can't imagine anyone actually subclassing
  from such a mass of messy code.  Perhaps these
  could be modified to use the has_section() method,
  which is relatively new.

- MAX_INTERPOLATION_DEPTH was not "honored"
  in the code since it's really a safety net; there's no
  intention that client code be able to change it.  (The
  sanity of the value is not checked before use.)  I'm
  inclined to retain the use of the constant in the
  interpolation code, and add a comment above the
  constant the it exists for informational purposes only.

Otherwise, I'm fine with the patch.  ;-)
Sorry for the delay in responding to this.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 17:55

Message:
Logged In: YES 
user_id=6380

I'm assigning this to Fred Drake, who has some opinions on
ConfigParser.

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2002-04-18 17:07

Message:
Logged In: YES 
user_id=7887

I'd rather explain here the patch that changes behavior, 
since it's pretty small. This line in the regular 
expression OPTCRE: 
 
r'(?P<option>[]\-[\w_.*,(){}]+)' 
 
was replaced by: 
 
r'(?P<option>[^:=\s]+)' 
 
So that instead of giving a range of characters which may 
be part of the option name, it just looks for the 
separator chars and spaces. This behavior is already used 
in the headers, and I haven't found any good reason to 
deny usage of other characters as option names. 
 
In the same regular expression, I've also replaced 
'[ \t]' by '\s', but this shouln't change the current 
behavior at all. 
 
About the walk patch, I have no idea why it isn't 
attached. I remember to have checked the ticked, and it 
was there. Anyway, I'm attaching it again. 

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-18 06:04

Message:
Logged In: YES 
user_id=21627

I'd like to see this split into even more parts: a patch
that supposedly has *no* semantic change (ie. the speed
improvements, memory consumption improvements, use of global
variables); a patch that changes behavior (please explain in
which ways); and the patch that implements walk (which
appears to be missing currently).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545096&group_id=5470



From noreply@sourceforge.net  Sat Jun 22 03:16:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 21 Jun 2002 19:16:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-545096 ] ConfigParser code cleanup
Message-ID: <E17LaS1-0002vm-00@usw-sf-web1.sourceforge.net>

Bugs item #545096, was opened at 2002-04-17 06:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545096&group_id=5470

Category: Python Library
Group: None
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Gustavo Niemeyer (niemeyer)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: ConfigParser code cleanup

Initial Comment:
The first patch fixes a bug, implements some speed 
improvements, some memory consumption improvements, 
enforces the usage of the already available global 
variables, and extends the allowed chars in option 
names to be very permissive. 
 
The second one, if used, is supposed to be applied 
over the first one, and implements a walk() 
generator method for walking trough the options of a 
section. 

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-21 22:16

Message:
Logged In: YES 
user_id=3066

Thanks!  I can take care of the referred bug; I already know
how I want to solve that one.  Thanks!

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2002-06-21 22:14

Message:
Logged In: YES 
user_id=7887

Thanks for your review Fred!  
  
I'll fix the patch as suggested, and work on a solution for the referred bug 
as well.   

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-21 21:38

Message:
Logged In: YES 
user_id=3066

Changed to a "bug" report even though it's a patch, so that
all the ConfigParser reports can show up together.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-21 13:22

Message:
Logged In: YES 
user_id=3066

I'd like to accept a variation on this patch.

Specifically, I'd like "section in self.sections()" tests to
become "sections in self.__sections" consistently; your
proposed patch is better than the original, but as long as
we're not supporting subclassing in this way, let's go ahead
and use the better-performing solution.

I'll accept the use of MAX_INTERPOLATION_DEPTH and your
changes to the interpolation loop, but the loop itself will
probably be re-written later, in response to SF bug #511737.

The walk() method will need documentation.

Can you prepare a new patch for this?

Thanks!

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-21 12:20

Message:
Logged In: YES 
user_id=3066

Ken appears non-responsive, re-assigning to me.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-12 21:42

Message:
Logged In: YES 
user_id=3066

Ken, can you recall our thinking on the use of the constant
for MAX_INTERPOLATION_DEPTH when this was first written?  I
think you were more involved in this than the rest of us at
the time.

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2002-06-03 17:45

Message:
Logged In: YES 
user_id=7887

Hello Fred! 
 
- About has_section(), I thought about the possibility of subclassing it. But, 
besides agreeing with you on the messy code matter, other functions 
weren't (and still aren't) considering this possibility, so I doubt some one will 
be able to subclass it anyways. Anyway, I may change the patch to use 
whatever you suggest. 
 
- About MAX_INTERPOLATION_DEPTH, I understand your position of 
wanting "a safety net", but my intention of using it in the code was not to 
let the user change it, but to clarify and give consistence to the code. I think 
using literal constants in the code is not a good measure at all. If this was 
adopted, many modules would have to be changed (in a bad way) for 
consistence. With a quick look at the library, I was able to find smtpd.py, 
base64.py, binhex.py, cgi.py, cmd.py, and many others using similar purpose 
constants. You'll probably agree with me if you think about this more 
extensively. 
 

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-30 12:11

Message:
Logged In: YES 
user_id=3066

I should clarify:  By "retain the use of the constant" I
mean the constant numeric literal, not MAX_INTERPOLATION_DEPTH.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-30 12:06

Message:
Logged In: YES 
user_id=3066

Two comments:

- "section in self.__sections.keys()" can be written
  (still more efficiently) as "section in self.__sections",
  *but* the use of the sections() method is done to be
  subclass-friendly.  I'm not sure how important this is
  since I can't imagine anyone actually subclassing
  from such a mass of messy code.  Perhaps these
  could be modified to use the has_section() method,
  which is relatively new.

- MAX_INTERPOLATION_DEPTH was not "honored"
  in the code since it's really a safety net; there's no
  intention that client code be able to change it.  (The
  sanity of the value is not checked before use.)  I'm
  inclined to retain the use of the constant in the
  interpolation code, and add a comment above the
  constant the it exists for informational purposes only.

Otherwise, I'm fine with the patch.  ;-)
Sorry for the delay in responding to this.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 13:55

Message:
Logged In: YES 
user_id=6380

I'm assigning this to Fred Drake, who has some opinions on
ConfigParser.

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2002-04-18 13:07

Message:
Logged In: YES 
user_id=7887

I'd rather explain here the patch that changes behavior, 
since it's pretty small. This line in the regular 
expression OPTCRE: 
 
r'(?P<option>[]\-[\w_.*,(){}]+)' 
 
was replaced by: 
 
r'(?P<option>[^:=\s]+)' 
 
So that instead of giving a range of characters which may 
be part of the option name, it just looks for the 
separator chars and spaces. This behavior is already used 
in the headers, and I haven't found any good reason to 
deny usage of other characters as option names. 
 
In the same regular expression, I've also replaced 
'[ \t]' by '\s', but this shouln't change the current 
behavior at all. 
 
About the walk patch, I have no idea why it isn't 
attached. I remember to have checked the ticked, and it 
was there. Anyway, I'm attaching it again. 

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-18 02:04

Message:
Logged In: YES 
user_id=21627

I'd like to see this split into even more parts: a patch
that supposedly has *no* semantic change (ie. the speed
improvements, memory consumption improvements, use of global
variables); a patch that changes behavior (please explain in
which ways); and the patch that implements walk (which
appears to be missing currently).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545096&group_id=5470



From noreply@sourceforge.net  Sat Jun 22 05:09:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 21 Jun 2002 21:09:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-545096 ] ConfigParser code cleanup
Message-ID: <E17LcDY-0006ki-00@usw-sf-web4.sourceforge.net>

Bugs item #545096, was opened at 2002-04-17 10:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545096&group_id=5470

Category: Python Library
Group: None
>Status: Open
Resolution: None
Priority: 5
Submitted By: Gustavo Niemeyer (niemeyer)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: ConfigParser code cleanup

Initial Comment:
The first patch fixes a bug, implements some speed 
improvements, some memory consumption improvements, 
enforces the usage of the already available global 
variables, and extends the allowed chars in option 
names to be very permissive. 
 
The second one, if used, is supposed to be applied 
over the first one, and implements a walk() 
generator method for walking trough the options of a 
section. 

----------------------------------------------------------------------

>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2002-06-22 04:09

Message:
Logged In: YES 
user_id=7887

Deal!! ;-) 
 
Here is the updated patch. 
 
Thanks! 

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-22 02:16

Message:
Logged In: YES 
user_id=3066

Thanks!  I can take care of the referred bug; I already know
how I want to solve that one.  Thanks!

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2002-06-22 02:14

Message:
Logged In: YES 
user_id=7887

Thanks for your review Fred!  
  
I'll fix the patch as suggested, and work on a solution for the referred bug 
as well.   

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-22 01:38

Message:
Logged In: YES 
user_id=3066

Changed to a "bug" report even though it's a patch, so that
all the ConfigParser reports can show up together.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-21 17:22

Message:
Logged In: YES 
user_id=3066

I'd like to accept a variation on this patch.

Specifically, I'd like "section in self.sections()" tests to
become "sections in self.__sections" consistently; your
proposed patch is better than the original, but as long as
we're not supporting subclassing in this way, let's go ahead
and use the better-performing solution.

I'll accept the use of MAX_INTERPOLATION_DEPTH and your
changes to the interpolation loop, but the loop itself will
probably be re-written later, in response to SF bug #511737.

The walk() method will need documentation.

Can you prepare a new patch for this?

Thanks!

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-21 16:20

Message:
Logged In: YES 
user_id=3066

Ken appears non-responsive, re-assigning to me.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-13 01:42

Message:
Logged In: YES 
user_id=3066

Ken, can you recall our thinking on the use of the constant
for MAX_INTERPOLATION_DEPTH when this was first written?  I
think you were more involved in this than the rest of us at
the time.

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2002-06-03 21:45

Message:
Logged In: YES 
user_id=7887

Hello Fred! 
 
- About has_section(), I thought about the possibility of subclassing it. But, 
besides agreeing with you on the messy code matter, other functions 
weren't (and still aren't) considering this possibility, so I doubt some one will 
be able to subclass it anyways. Anyway, I may change the patch to use 
whatever you suggest. 
 
- About MAX_INTERPOLATION_DEPTH, I understand your position of 
wanting "a safety net", but my intention of using it in the code was not to 
let the user change it, but to clarify and give consistence to the code. I think 
using literal constants in the code is not a good measure at all. If this was 
adopted, many modules would have to be changed (in a bad way) for 
consistence. With a quick look at the library, I was able to find smtpd.py, 
base64.py, binhex.py, cgi.py, cmd.py, and many others using similar purpose 
constants. You'll probably agree with me if you think about this more 
extensively. 
 

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-30 16:11

Message:
Logged In: YES 
user_id=3066

I should clarify:  By "retain the use of the constant" I
mean the constant numeric literal, not MAX_INTERPOLATION_DEPTH.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-30 16:06

Message:
Logged In: YES 
user_id=3066

Two comments:

- "section in self.__sections.keys()" can be written
  (still more efficiently) as "section in self.__sections",
  *but* the use of the sections() method is done to be
  subclass-friendly.  I'm not sure how important this is
  since I can't imagine anyone actually subclassing
  from such a mass of messy code.  Perhaps these
  could be modified to use the has_section() method,
  which is relatively new.

- MAX_INTERPOLATION_DEPTH was not "honored"
  in the code since it's really a safety net; there's no
  intention that client code be able to change it.  (The
  sanity of the value is not checked before use.)  I'm
  inclined to retain the use of the constant in the
  interpolation code, and add a comment above the
  constant the it exists for informational purposes only.

Otherwise, I'm fine with the patch.  ;-)
Sorry for the delay in responding to this.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 17:55

Message:
Logged In: YES 
user_id=6380

I'm assigning this to Fred Drake, who has some opinions on
ConfigParser.

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2002-04-18 17:07

Message:
Logged In: YES 
user_id=7887

I'd rather explain here the patch that changes behavior, 
since it's pretty small. This line in the regular 
expression OPTCRE: 
 
r'(?P<option>[]\-[\w_.*,(){}]+)' 
 
was replaced by: 
 
r'(?P<option>[^:=\s]+)' 
 
So that instead of giving a range of characters which may 
be part of the option name, it just looks for the 
separator chars and spaces. This behavior is already used 
in the headers, and I haven't found any good reason to 
deny usage of other characters as option names. 
 
In the same regular expression, I've also replaced 
'[ \t]' by '\s', but this shouln't change the current 
behavior at all. 
 
About the walk patch, I have no idea why it isn't 
attached. I remember to have checked the ticked, and it 
was there. Anyway, I'm attaching it again. 

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-18 06:04

Message:
Logged In: YES 
user_id=21627

I'd like to see this split into even more parts: a patch
that supposedly has *no* semantic change (ie. the speed
improvements, memory consumption improvements, use of global
variables); a patch that changes behavior (please explain in
which ways); and the patch that implements walk (which
appears to be missing currently).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545096&group_id=5470



From noreply@sourceforge.net  Sat Jun 22 15:58:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 22 Jun 2002 07:58:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-572341 ] python-mode IM parses code in docstrings
Message-ID: <E17LmL2-0006SF-00@usw-sf-web4.sourceforge.net>

Bugs item #572341, was opened at 2002-06-21 19:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=572341&group_id=5470

Category: Demos and Tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Adrian van den Dries (cantanker)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: python-mode IM parses code in docstrings

Initial Comment:
When reading a file with code examples, the IM menu
parses the code in the docstrings and ignores the real
code!

For  a real example, see Twisted's twisted.usage.py, or
try this example:

# module life

"""
for the meaning of life, try this:
    class MyMeaning(life.Meaning):
        def __init__(self, foo):
            self.foo = foo
"""

# real code follows

class Meaning:
    def ferfoo(self):
        if self.foo:
            return self.foo
        else:
            return None


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=572341&group_id=5470



From noreply@sourceforge.net  Sat Jun 22 20:17:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 22 Jun 2002 12:17:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-572567 ] Memory leak in object comparison
Message-ID: <E17LqNx-0001RT-00@usw-sf-web4.sourceforge.net>

Bugs item #572567, was opened at 2002-06-22 14:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=572567&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Jacobs (jacobs99)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory leak in object comparison

Initial Comment:
There is a rather obscure memory leak caused
by a missing Py_DECREF one of the comparison
function wrappers in typeobject.c.  It is obscure only 
because it inflates the reference count on methods,
which is why it has gone unnoticed since its inital
checkin on 8/15/2001.  Unfortunately, one of my
meta-class experiments triggers this code on
many ephemoral class instances, and thus leaks 
heaping chunks of memory (or a heaping number of 
little chunks, if you like).

I've attached the simple one line fix, which should
be applied to the next 2.2.x release, and certainly
to the 2.3 CVS tree.  To make myself really useful, 
I've also audited the rest of typeobject.c to make sure 
that all users of 'lookup_method', the source of the 
leaked reference, properly handle its results.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=572567&group_id=5470



From noreply@sourceforge.net  Sat Jun 22 21:41:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 22 Jun 2002 13:41:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-571334 ] imaplib fetch is broken
Message-ID: <E17Lrhh-0001Q9-00@usw-sf-web3.sourceforge.net>

Bugs item #571334, was opened at 2002-06-20 07:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571334&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Goerzen (jgoerzen)
Assigned to: Piers Lauder (pierslauder)
Summary: imaplib fetch is broken

Initial Comment:
This bug is 100% reproducible in Python 2.2.1 and the 
imaplib.py from Python's CVS tree. 
 
They'll send the message body in this form: 
{100} 
Headers here, body here, (100 characters worth) 
 
This is specified in RFC2060 secion 4.3.  imaplib's fetch 
chokes on 
"unexpected data" in the response. 
 
imaplib should receive this prefix-quoted string properly 
and return it in a 
non-quoted fashion. 
 
As it is, it is totally impossible to read messages from 
most imap servers. 
 

----------------------------------------------------------------------

>Comment By: Piers Lauder (pierslauder)
Date: 2002-06-23 06:41

Message:
Logged In: YES 
user_id=196212

I've checked in a new version of imaplib with the IMAP4_SSL
read and send methods modified to deal with short data
results from the sslobj methods.

Let me know if it work for you and I'll mark this bug fixed.


----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 2002-06-21 09:45

Message:
Logged In: YES 
user_id=491567

Note, though, that AFAIK there is no canonical code for 
"read" in python like there is in C.  File objects have a read(), 
socket objects have a read, StringIO has a read, and in this 
case, SSL sockets have a read. 
 
I suspect that it could be an issue unique to SSL sockets. 
 
I'm using Python 2.2.1 with the imaplib.py pulled from the 
development tree's CVS as of two days ago.  Sorry, I don't 
know the exact version number.  I needed that one for the SSL 
support. 
 
It is possible that this could be considered a bug in the SSL 
socket support.  I find it highly annoying that, among other 
things, imaplib.py has to kludge around socket.ssl's lack of 
readline(). 

----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-21 08:45

Message:
Logged In: YES 
user_id=196212

PS: could you also state which imaplib class you are using -
there may be a difference between the socket.socket and
socket.ssl behaviours.


----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-21 08:37

Message:
Logged In: YES 
user_id=196212

I'm very surprised by this. According to the Python library
manual for the read method:

read([size])
 Read at most size bytes from the file (less if the read
hits EOF before obtaining size bytes). If the size argument
is negative or omitted, read all data until EOF is reached.
The bytes are returned as a string object. An empty string
is returned when EOF is encountered immediately. (For
certain files, like ttys, it makes sense to continue reading
after an EOF is hit.) Note that this method may call the
underlying C function fread() more than once in an effort to
acquire as close to size bytes as possible.

So read(size) should return size bytes unless EOF is found.
(And as imaplib has been in use for several years, I take it
the manual is factual :-)

Maybe this is an O/S-specific problem in the python interpreter?
What O/S (and version) is your Python 2.2.1 interpreter
running on?


----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 2002-06-21 00:01

Message:
Logged In: YES 
user_id=491567

It turns out that it is a bug in read() in the imaplib.  It does not 
obey the principle that the read() call will return UP TO the 
amount of bytes specified.  The below diff fixes it for me.  I 
have not yet tried append(), but I suspect that the write calls 
will have the same problem. 
 
--- imaplib.py  18 Jun 2002 15:36:03 -0000      1.1 
+++ imaplib.py  20 Jun 2002 04:02:49 -0000      1.2 
@@ -222,8 +222,10 @@ 
 
     def read(self, size): 
         """Read 'size' bytes from remote.""" 
-        return self.file.read(size) 
- 
+        retval = '' 
+        while len(retval) < size: 
+            retval += self.file.read(size - len(retval)) 
+        return retval 
 
     def readline(self): 
         """Read line from remote.""" 
@@ -1056,7 +1059,10 @@ 
 
     def read(self, size): 
         """Read 'size' bytes from remote.""" 
-        return self.sslobj.read(size) 
+        retval = '' 
+        while len(retval) < size: 
+            retval += self.sslobj.read(size - len(retval)) 
+        return retval 
 
 
     def readline(self): 
 

----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-20 18:46

Message:
Logged In: YES 
user_id=196212

I can't duplicate this.

The test code at the end of imaplib.py includes a FETCH
command which is returned as a literal by my imap server.

Perhaps you could run that test on your server and cut
and paste the response.

Run the test like this:
  python2.2 imaplib.py -d5 <imap_server_host_name>

>From which I get the following:
	...
 43:26.15 > KDP19 UID FETCH 19570 (FLAGS INTERNALDATE
RFC822.SIZE RFC822.HEADER RFC822.TEXT)
  43:26.46 < * 83 FETCH (UID 19570 FLAGS (\Seen)
INTERNALDATE "20-Jun-2002 18:36:51 +1000" RFC822.SIZE 55
RFC822.HEADER {46}
  43:26.46      matched r'\* (?P<data>\d+)
(?P<type>[A-Z-]+)( (?P<data2>.*))?' => ('83', 'FETCH', '
(UID 19570 FLAGS (\Seen) INTERNALDATE "20-Jun-2002 18:36:51
+1000" RFC822.SIZE 55 RFC822.HEADER {46}', '(UID 19570 FLAGS
(\Seen) INTERNALDATE "20-Jun-2002 18:36:51 +1000"
RFC822.SIZE 55 RFC822.HEADER {46}')
  43:26.46      matched r'.*{(?P<size>\d+)}$' => ('46',)
  43:26.47 read literal size 46
	...
and so on.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571334&group_id=5470



From noreply@sourceforge.net  Sat Jun 22 22:09:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 22 Jun 2002 14:09:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-571334 ] imaplib fetch is broken
Message-ID: <E17Ls8Z-00008k-00@usw-sf-web2.sourceforge.net>

Bugs item #571334, was opened at 2002-06-20 07:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571334&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Goerzen (jgoerzen)
Assigned to: Piers Lauder (pierslauder)
Summary: imaplib fetch is broken

Initial Comment:
This bug is 100% reproducible in Python 2.2.1 and the 
imaplib.py from Python's CVS tree. 
 
They'll send the message body in this form: 
{100} 
Headers here, body here, (100 characters worth) 
 
This is specified in RFC2060 secion 4.3.  imaplib's fetch 
chokes on 
"unexpected data" in the response. 
 
imaplib should receive this prefix-quoted string properly 
and return it in a 
non-quoted fashion. 
 
As it is, it is totally impossible to read messages from 
most imap servers. 
 

----------------------------------------------------------------------

>Comment By: Piers Lauder (pierslauder)
Date: 2002-06-23 07:09

Message:
Logged In: YES 
user_id=196212

My cvs checkin failed, perhaps because sourceforge is too
busy,  so the update is postponed for the time being...

----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-23 06:41

Message:
Logged In: YES 
user_id=196212

I've checked in a new version of imaplib with the IMAP4_SSL
read and send methods modified to deal with short data
results from the sslobj methods.

Let me know if it work for you and I'll mark this bug fixed.


----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 2002-06-21 09:45

Message:
Logged In: YES 
user_id=491567

Note, though, that AFAIK there is no canonical code for 
"read" in python like there is in C.  File objects have a read(), 
socket objects have a read, StringIO has a read, and in this 
case, SSL sockets have a read. 
 
I suspect that it could be an issue unique to SSL sockets. 
 
I'm using Python 2.2.1 with the imaplib.py pulled from the 
development tree's CVS as of two days ago.  Sorry, I don't 
know the exact version number.  I needed that one for the SSL 
support. 
 
It is possible that this could be considered a bug in the SSL 
socket support.  I find it highly annoying that, among other 
things, imaplib.py has to kludge around socket.ssl's lack of 
readline(). 

----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-21 08:45

Message:
Logged In: YES 
user_id=196212

PS: could you also state which imaplib class you are using -
there may be a difference between the socket.socket and
socket.ssl behaviours.


----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-21 08:37

Message:
Logged In: YES 
user_id=196212

I'm very surprised by this. According to the Python library
manual for the read method:

read([size])
 Read at most size bytes from the file (less if the read
hits EOF before obtaining size bytes). If the size argument
is negative or omitted, read all data until EOF is reached.
The bytes are returned as a string object. An empty string
is returned when EOF is encountered immediately. (For
certain files, like ttys, it makes sense to continue reading
after an EOF is hit.) Note that this method may call the
underlying C function fread() more than once in an effort to
acquire as close to size bytes as possible.

So read(size) should return size bytes unless EOF is found.
(And as imaplib has been in use for several years, I take it
the manual is factual :-)

Maybe this is an O/S-specific problem in the python interpreter?
What O/S (and version) is your Python 2.2.1 interpreter
running on?


----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 2002-06-21 00:01

Message:
Logged In: YES 
user_id=491567

It turns out that it is a bug in read() in the imaplib.  It does not 
obey the principle that the read() call will return UP TO the 
amount of bytes specified.  The below diff fixes it for me.  I 
have not yet tried append(), but I suspect that the write calls 
will have the same problem. 
 
--- imaplib.py  18 Jun 2002 15:36:03 -0000      1.1 
+++ imaplib.py  20 Jun 2002 04:02:49 -0000      1.2 
@@ -222,8 +222,10 @@ 
 
     def read(self, size): 
         """Read 'size' bytes from remote.""" 
-        return self.file.read(size) 
- 
+        retval = '' 
+        while len(retval) < size: 
+            retval += self.file.read(size - len(retval)) 
+        return retval 
 
     def readline(self): 
         """Read line from remote.""" 
@@ -1056,7 +1059,10 @@ 
 
     def read(self, size): 
         """Read 'size' bytes from remote.""" 
-        return self.sslobj.read(size) 
+        retval = '' 
+        while len(retval) < size: 
+            retval += self.sslobj.read(size - len(retval)) 
+        return retval 
 
 
     def readline(self): 
 

----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-20 18:46

Message:
Logged In: YES 
user_id=196212

I can't duplicate this.

The test code at the end of imaplib.py includes a FETCH
command which is returned as a literal by my imap server.

Perhaps you could run that test on your server and cut
and paste the response.

Run the test like this:
  python2.2 imaplib.py -d5 <imap_server_host_name>

>From which I get the following:
	...
 43:26.15 > KDP19 UID FETCH 19570 (FLAGS INTERNALDATE
RFC822.SIZE RFC822.HEADER RFC822.TEXT)
  43:26.46 < * 83 FETCH (UID 19570 FLAGS (\Seen)
INTERNALDATE "20-Jun-2002 18:36:51 +1000" RFC822.SIZE 55
RFC822.HEADER {46}
  43:26.46      matched r'\* (?P<data>\d+)
(?P<type>[A-Z-]+)( (?P<data2>.*))?' => ('83', 'FETCH', '
(UID 19570 FLAGS (\Seen) INTERNALDATE "20-Jun-2002 18:36:51
+1000" RFC822.SIZE 55 RFC822.HEADER {46}', '(UID 19570 FLAGS
(\Seen) INTERNALDATE "20-Jun-2002 18:36:51 +1000"
RFC822.SIZE 55 RFC822.HEADER {46}')
  43:26.46      matched r'.*{(?P<size>\d+)}$' => ('46',)
  43:26.47 read literal size 46
	...
and so on.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571334&group_id=5470



From noreply@sourceforge.net  Sun Jun 23 11:51:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 23 Jun 2002 03:51:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-571334 ] imaplib fetch is broken
Message-ID: <E17M4xl-0002v2-00@usw-sf-web4.sourceforge.net>

Bugs item #571334, was opened at 2002-06-20 07:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571334&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Goerzen (jgoerzen)
Assigned to: Piers Lauder (pierslauder)
Summary: imaplib fetch is broken

Initial Comment:
This bug is 100% reproducible in Python 2.2.1 and the 
imaplib.py from Python's CVS tree. 
 
They'll send the message body in this form: 
{100} 
Headers here, body here, (100 characters worth) 
 
This is specified in RFC2060 secion 4.3.  imaplib's fetch 
chokes on 
"unexpected data" in the response. 
 
imaplib should receive this prefix-quoted string properly 
and return it in a 
non-quoted fashion. 
 
As it is, it is totally impossible to read messages from 
most imap servers. 
 

----------------------------------------------------------------------

>Comment By: Piers Lauder (pierslauder)
Date: 2002-06-23 20:51

Message:
Logged In: YES 
user_id=196212

Changes now checked in - please try them out.


----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-23 07:09

Message:
Logged In: YES 
user_id=196212

My cvs checkin failed, perhaps because sourceforge is too
busy,  so the update is postponed for the time being...

----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-23 06:41

Message:
Logged In: YES 
user_id=196212

I've checked in a new version of imaplib with the IMAP4_SSL
read and send methods modified to deal with short data
results from the sslobj methods.

Let me know if it work for you and I'll mark this bug fixed.


----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 2002-06-21 09:45

Message:
Logged In: YES 
user_id=491567

Note, though, that AFAIK there is no canonical code for 
"read" in python like there is in C.  File objects have a read(), 
socket objects have a read, StringIO has a read, and in this 
case, SSL sockets have a read. 
 
I suspect that it could be an issue unique to SSL sockets. 
 
I'm using Python 2.2.1 with the imaplib.py pulled from the 
development tree's CVS as of two days ago.  Sorry, I don't 
know the exact version number.  I needed that one for the SSL 
support. 
 
It is possible that this could be considered a bug in the SSL 
socket support.  I find it highly annoying that, among other 
things, imaplib.py has to kludge around socket.ssl's lack of 
readline(). 

----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-21 08:45

Message:
Logged In: YES 
user_id=196212

PS: could you also state which imaplib class you are using -
there may be a difference between the socket.socket and
socket.ssl behaviours.


----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-21 08:37

Message:
Logged In: YES 
user_id=196212

I'm very surprised by this. According to the Python library
manual for the read method:

read([size])
 Read at most size bytes from the file (less if the read
hits EOF before obtaining size bytes). If the size argument
is negative or omitted, read all data until EOF is reached.
The bytes are returned as a string object. An empty string
is returned when EOF is encountered immediately. (For
certain files, like ttys, it makes sense to continue reading
after an EOF is hit.) Note that this method may call the
underlying C function fread() more than once in an effort to
acquire as close to size bytes as possible.

So read(size) should return size bytes unless EOF is found.
(And as imaplib has been in use for several years, I take it
the manual is factual :-)

Maybe this is an O/S-specific problem in the python interpreter?
What O/S (and version) is your Python 2.2.1 interpreter
running on?


----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 2002-06-21 00:01

Message:
Logged In: YES 
user_id=491567

It turns out that it is a bug in read() in the imaplib.  It does not 
obey the principle that the read() call will return UP TO the 
amount of bytes specified.  The below diff fixes it for me.  I 
have not yet tried append(), but I suspect that the write calls 
will have the same problem. 
 
--- imaplib.py  18 Jun 2002 15:36:03 -0000      1.1 
+++ imaplib.py  20 Jun 2002 04:02:49 -0000      1.2 
@@ -222,8 +222,10 @@ 
 
     def read(self, size): 
         """Read 'size' bytes from remote.""" 
-        return self.file.read(size) 
- 
+        retval = '' 
+        while len(retval) < size: 
+            retval += self.file.read(size - len(retval)) 
+        return retval 
 
     def readline(self): 
         """Read line from remote.""" 
@@ -1056,7 +1059,10 @@ 
 
     def read(self, size): 
         """Read 'size' bytes from remote.""" 
-        return self.sslobj.read(size) 
+        retval = '' 
+        while len(retval) < size: 
+            retval += self.sslobj.read(size - len(retval)) 
+        return retval 
 
 
     def readline(self): 
 

----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-20 18:46

Message:
Logged In: YES 
user_id=196212

I can't duplicate this.

The test code at the end of imaplib.py includes a FETCH
command which is returned as a literal by my imap server.

Perhaps you could run that test on your server and cut
and paste the response.

Run the test like this:
  python2.2 imaplib.py -d5 <imap_server_host_name>

>From which I get the following:
	...
 43:26.15 > KDP19 UID FETCH 19570 (FLAGS INTERNALDATE
RFC822.SIZE RFC822.HEADER RFC822.TEXT)
  43:26.46 < * 83 FETCH (UID 19570 FLAGS (\Seen)
INTERNALDATE "20-Jun-2002 18:36:51 +1000" RFC822.SIZE 55
RFC822.HEADER {46}
  43:26.46      matched r'\* (?P<data>\d+)
(?P<type>[A-Z-]+)( (?P<data2>.*))?' => ('83', 'FETCH', '
(UID 19570 FLAGS (\Seen) INTERNALDATE "20-Jun-2002 18:36:51
+1000" RFC822.SIZE 55 RFC822.HEADER {46}', '(UID 19570 FLAGS
(\Seen) INTERNALDATE "20-Jun-2002 18:36:51 +1000"
RFC822.SIZE 55 RFC822.HEADER {46}')
  43:26.46      matched r'.*{(?P<size>\d+)}$' => ('46',)
  43:26.47 read literal size 46
	...
and so on.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571334&group_id=5470



From noreply@sourceforge.net  Sun Jun 23 20:06:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 23 Jun 2002 12:06:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-572567 ] Memory leak in object comparison
Message-ID: <E17MCgg-0005gk-00@usw-sf-web5.sourceforge.net>

Bugs item #572567, was opened at 2002-06-22 14:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=572567&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Jacobs (jacobs99)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Memory leak in object comparison

Initial Comment:
There is a rather obscure memory leak caused
by a missing Py_DECREF one of the comparison
function wrappers in typeobject.c.  It is obscure only 
because it inflates the reference count on methods,
which is why it has gone unnoticed since its inital
checkin on 8/15/2001.  Unfortunately, one of my
meta-class experiments triggers this code on
many ephemoral class instances, and thus leaks 
heaping chunks of memory (or a heaping number of 
little chunks, if you like).

I've attached the simple one line fix, which should
be applied to the next 2.2.x release, and certainly
to the 2.3 CVS tree.  To make myself really useful, 
I've also audited the rest of typeobject.c to make sure 
that all users of 'lookup_method', the source of the 
leaked reference, properly handle its results.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=572567&group_id=5470



From noreply@sourceforge.net  Sun Jun 23 20:23:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 23 Jun 2002 12:23:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect
Message-ID: <E17MCwy-0005va-00@usw-sf-web5.sourceforge.net>

Bugs item #549151, was opened at 2002-04-26 17:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Jeremy Hylton (jhylton)
Summary: urllib2 POSTs on redirect

Initial Comment:

urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the 
POST method on redirect, contrary to RFC1945 section 9.3:

> 9.3  Redirection 3xx
> 
>    This class of status code indicates that further action needs to be
>    taken by the user agent in order to fulfill the request. The action
>    required may be carried out by the user agent without interaction
>    with the user if and only if the method used in the subsequent
>    request is GET or HEAD. A user agent should never automatically
>    redirect a request more than 5 times, since such redirections usually
>    indicate an infinite loop.

Can be fixed in HTTPRedirectHandler.http_error_302 by replacing
        new = Request(newurl, req.get_data())

with
        new = Request(newurl)

so that GET is done on redirect instead of POST.

I suppose the limit of 10 in the same function should be changed to 5, also.


----------------------------------------------------------------------

>Comment By: John J Lee (jjlee)
Date: 2002-06-23 20:23

Message:
Logged In: YES 
user_id=261020

First, can I underline the fact that there are two issues
here:

  1. What method should POST be redirected as for a
     particular 30x response?

  2. Should the user be asked to confirm the redirection
     (which presumably maps onto raising an HTTPError in
     urllib2)?

I think current client implementations go against the RFCs
on both these points for 302.  Contrastingly, RFC 2616's
note on 301 responses (section 10.3.2) implies that only a
subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs
(1945, 2068, 2616) on point 1 for 301 responses, and I know
of no clients that violate the RFCs on point 2 for 301
responses (but I haven't tested).  Also, I guess the
original intent (for both 301 and 302) was that POSTs
represent an action, so it's dangerous in general to
redirect them without asking the user: I presume this is why
307 was brought in: 307 POSTs on redirected POST, so the
user must be asked:

10.3 Redirection 3xx
[...]
   The action required MAY be carried out by the user agent
   without interaction with the user if and only if the
   method used in the second request is GET or HEAD.

(and 303 is just meant to have the 'erroneous' 302
behaviour: GET on redirected POST, don't ask the user)

So, I agree with Guido that 302 should probably now be
treated the way most clients treat it: GET on redirected
POST, don't ask the user.  As for 301, if it *is* true that
only a few HTTP/1.0 clients have misinterpreted the RFCs on
301, we should stick to the safe behaviour indicated by the
RFC.

As for Guido's first question: A 307 should indeed be
redirected as a POST, but it should ask the user first (see
10.3 quote, above).  That's what my patch does (the 'return
None' in the else clause in redirect_request causes an
exception to be raised eventually -- maybe it should just
raise it itself).

I've attached a revised patch that deals with 302 (and 303)
in the 'erroneous' way (again: GET on redirected POST, don't
ask the user).

I suppose the comment about HTTPRedirectHandler also needs
to state that 301 and 307 POST requests are not
automatically redirected -- HTTPError is raised in that
case.


John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-20 01:57

Message:
Logged In: YES 
user_id=6380

Hm, I thought that 307 should be treated differently than
303. In particular, a 307 response to POST should cause the
POST to be redirected. And I'm not sure about what a 301
response to POST should do.

(In the mean time I have been convinced that changing POST
to GET on 302 is the best thing to do given that most
browsers do that. The old urllib.py should be fixed too.)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-19 22:57

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-19 22:56

Message:
Logged In: YES 
user_id=261020

I've attached a patch -- was simpler than I thought.

I think this is in compliance with RFC 2616.  It's also
simple for clients to inherit from HTTPRedirectHandler and
override redirect_request if, for example, they know they
want all 302 POSTs to be redirected as a GET, which removes
the need for mixing redirection code with normal client code
even when the server doesn't follow the RFC (if the server
expects a 302 POST to be redirected as a GET, for example).
Note that I had to add a method, named 'method', to the
Request class, for maintainability (it's possible that
urllib2 may be able to do methods other than GET and POST in
future).

Possibly redirect_request should take fewer parameters.

John


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-06-06 22:25

Message:
Logged In: YES 
user_id=261020

Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I
check, I see that even RFC 1945 (HTTP/1.0) has a whole set of
restrictions on 30x for particular values of x which I missed
completely.

I guess it should do what Guido suggested -- report an error if a
POST is redirected -- until somebody gets time to do it properly.
I won't have time for a couple of months, but if nobody has done
it by then I'll upload a patch.


John


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-06 16:09

Message:
Logged In: YES 
user_id=31392

I think you need to review the current HTTP spec -- RFC 2616
-- and look at the section on redirection (10.3).  I think
urllib2 could improve its handling of redirection, but the
behavior you describe from lynx sounds incorrect.  I'd be
happy to review a patch the implemented the current spec.

Also, RFC 2616 removes the recommendation of a 5 redirect limit.




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 19:10

Message:
Logged In: YES 
user_id=6380

Fair enough. I'll leve it to Jeremy to review the proposed
fix. (Note that he's busy though.)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-29 17:29

Message:
Logged In: YES 
user_id=261020

I don't see why it shouldn't substitue a GET.  That certainly seems to be
the standard practice (well, at least that's what lynx does), and in the case
of the only site where I've encountered redirects on POST, the redirect URL
contains urlencoded stuff, so it clearly expects the user-agent to do a GET.
The site would break if this didn't happen, so I guess Netscape and IE must
do the same thing.

Clearly the RFC *does* allow this, though it doesn't require it (or specify
what should happen here in any way other than to say that a POST is not
allowed, in fact).  Since it's standard practice and allowed by the RFC, I
don't think it should be an error.

John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 01:53

Message:
Logged In: YES 
user_id=6380

Hm, the way I interpret the text you quote, if the original
request is  a POST, it should probably not substitute a GET
but report the error.

Assigning to Jeremy since it's his module.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-28 17:21

Message:
Logged In: YES 
user_id=261020

1. Bug is also in 2.2 branch

2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers:

new = Request(newurl, headers=req.headers)

3. I guess 10 should be replaced with 4, not 5.


John


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470



From noreply@sourceforge.net  Sun Jun 23 23:59:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 23 Jun 2002 15:59:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-481284 ] GetFileSecurity returns wrong SID
Message-ID: <E17MGKR-0005lJ-00@usw-sf-web3.sourceforge.net>

Bugs item #481284, was opened at 2001-11-13 05:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=481284&group_id=5470

Category: Windows
Group: Platform-specific
Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: Ruben Marquez (rrm1)
Assigned to: Mark Hammond (mhammond)
Summary: GetFileSecurity returns wrong SID

Initial Comment:
The following code printes PySID:S-1-0x008014000000 for
every file on any machine, independent of the real 
ower of the file:

for f in glob.glob("d:/*.*"):
    try:
        o =
win32security.GetFileSecurity
(f,win32security.OWNER_SECURITY_INFORMATION)
        s = win32security.SID(o)
        print str(s),
    except:
        print "n/a",
    print "   ",f

----------
Interestingly,

def prsid(name):
    import string
    print string.rjust(name,20),
    try:
        sid,box,what=win32security.LookupAccountName
(None,name)
        print str(sid),box,what
    except:
        print "oops"

Works well, so it doesn't seem to be a problem with 
PySIDs.

Thanks for your help in resolving this.

P.S.: (Discussed in http://groups.google.com/groups?
hl=en&th=b808d773d7ba0fee)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-23 15:59

Message:
Logged In: NO 

Hi Mark,

  I've had a read through all of the information that I could on 
this, and the problem resolution that you've outlined here 
doesn't seem to be valid.  That is, if I use:
fileSecurity = win32security.GetFileSecurity
('c:/winnt',win32security.OWNER_SECURITY_INFORMATION)

and then watch fileSecurity in a debugger like Komodo, I find 
that there are only three object methods available, 
fileSecurity.Initialize()
fileSecurity.SetDacl()
fileSecuiryt.SetSecurityDescriptorDacl()

I haven't yet gotten desperate enough to use a tool that 
allows the inspection of the contents of RAM to find out 
what's in the fileSecurity object, but I'm getting close to it... ;-)

To be completely explicit, if I use:
import win32security
fileSecurity = win32security.GetFileSecurity
('c:/winnt',win32security.OWNER_SECURITY_INFORMATION)
secInfo = fileSecurity.GetSecurityDescriptorOwner()

Python errors and the traceback looks like this:
Traceback (most recent call last):
  File "getfilesecurity.py", line 17, in ?
    secInfo = fileSecurity.GetSecurityDesc
AttributeError: GetSecurityDescriptorOwner

I love Python and would dearly like to use this API to do 
some work...  I found a white paper written by someone that 
talked about the possibility of extending a Python module 
with SWIG to use the GetNamedSecurityInfo() API, but I don't 
have a C compiler ATM to knock the code up with :-(
Oh, and just as background, basically, I'm writing a class 
library to allow someone to list each unique NT account that 
has rights to a file/directory and what those (cumulative) 
rights are.  I already have a basic class that will enumerate 
individual user accounts in local groups for me, now I just 
need to extend it to point at groups in ACLs...

Please please please assist;
Cheers,
Darryl Dixon

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-03-27 19:37

Message:
Logged In: YES 
user_id=14198

This is not a bug.  The SID() function does not take a
SECURITY_DESCRIPTOR.  The fact it *seems* to is an artifact
of a SECURITY_DESCRIPTOR implementing the buffer protocol,
and the fact that SID() can be constructed with a buffer
assumed to be valid SID bits.  Thus, your code is attempting
to create a SID from the bits in the SECURITY_DESCRIPTOR.

The code should change to:
    o =
win32security.GetFileSecurity(f,win32security.OWNER_SECURITY_INFORMATION)
    s = o.GetSecurityDescriptorOwner()

s is not the SID of the owner of the file.  There is also
GetSecurityDescriptorGroup(), etc.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-11-13 08:00

Message:
Logged In: YES 
user_id=31435

Reassigned to MarkH, as this is in the Win32 extensions.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=481284&group_id=5470



From noreply@sourceforge.net  Mon Jun 24 00:15:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 23 Jun 2002 16:15:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-481284 ] GetFileSecurity returns wrong SID
Message-ID: <E17MGZn-0000Ok-00@usw-sf-web5.sourceforge.net>

Bugs item #481284, was opened at 2001-11-14 00:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=481284&group_id=5470

Category: Windows
Group: Platform-specific
Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: Ruben Marquez (rrm1)
Assigned to: Mark Hammond (mhammond)
Summary: GetFileSecurity returns wrong SID

Initial Comment:
The following code printes PySID:S-1-0x008014000000 for
every file on any machine, independent of the real 
ower of the file:

for f in glob.glob("d:/*.*"):
    try:
        o =
win32security.GetFileSecurity
(f,win32security.OWNER_SECURITY_INFORMATION)
        s = win32security.SID(o)
        print str(s),
    except:
        print "n/a",
    print "   ",f

----------
Interestingly,

def prsid(name):
    import string
    print string.rjust(name,20),
    try:
        sid,box,what=win32security.LookupAccountName
(None,name)
        print str(sid),box,what
    except:
        print "oops"

Works well, so it doesn't seem to be a problem with 
PySIDs.

Thanks for your help in resolving this.

P.S.: (Discussed in http://groups.google.com/groups?
hl=en&th=b808d773d7ba0fee)

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-06-24 09:15

Message:
Logged In: YES 
user_id=14198

What OS are you on, and what version of win32all.  It works
fine for me.

>>> import win32security
>>> fileSecurity =
win32security.GetFileSecurity('f:/windows',win32security.OWNER_SECURITY_INFORMATION)
>>> secInfo = fileSecurity.GetSecurityDescriptorOwner()
>>> secInfo
<PySID object at 0x00D18CD8>
>>> 

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-24 08:59

Message:
Logged In: NO 

Hi Mark,

  I've had a read through all of the information that I could on 
this, and the problem resolution that you've outlined here 
doesn't seem to be valid.  That is, if I use:
fileSecurity = win32security.GetFileSecurity
('c:/winnt',win32security.OWNER_SECURITY_INFORMATION)

and then watch fileSecurity in a debugger like Komodo, I find 
that there are only three object methods available, 
fileSecurity.Initialize()
fileSecurity.SetDacl()
fileSecuiryt.SetSecurityDescriptorDacl()

I haven't yet gotten desperate enough to use a tool that 
allows the inspection of the contents of RAM to find out 
what's in the fileSecurity object, but I'm getting close to it... ;-)

To be completely explicit, if I use:
import win32security
fileSecurity = win32security.GetFileSecurity
('c:/winnt',win32security.OWNER_SECURITY_INFORMATION)
secInfo = fileSecurity.GetSecurityDescriptorOwner()

Python errors and the traceback looks like this:
Traceback (most recent call last):
  File "getfilesecurity.py", line 17, in ?
    secInfo = fileSecurity.GetSecurityDesc
AttributeError: GetSecurityDescriptorOwner

I love Python and would dearly like to use this API to do 
some work...  I found a white paper written by someone that 
talked about the possibility of extending a Python module 
with SWIG to use the GetNamedSecurityInfo() API, but I don't 
have a C compiler ATM to knock the code up with :-(
Oh, and just as background, basically, I'm writing a class 
library to allow someone to list each unique NT account that 
has rights to a file/directory and what those (cumulative) 
rights are.  I already have a basic class that will enumerate 
individual user accounts in local groups for me, now I just 
need to extend it to point at groups in ACLs...

Please please please assist;
Cheers,
Darryl Dixon

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-03-28 14:37

Message:
Logged In: YES 
user_id=14198

This is not a bug.  The SID() function does not take a
SECURITY_DESCRIPTOR.  The fact it *seems* to is an artifact
of a SECURITY_DESCRIPTOR implementing the buffer protocol,
and the fact that SID() can be constructed with a buffer
assumed to be valid SID bits.  Thus, your code is attempting
to create a SID from the bits in the SECURITY_DESCRIPTOR.

The code should change to:
    o =
win32security.GetFileSecurity(f,win32security.OWNER_SECURITY_INFORMATION)
    s = o.GetSecurityDescriptorOwner()

s is not the SID of the owner of the file.  There is also
GetSecurityDescriptorGroup(), etc.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-11-14 03:00

Message:
Logged In: YES 
user_id=31435

Reassigned to MarkH, as this is in the Win32 extensions.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=481284&group_id=5470



From noreply@sourceforge.net  Mon Jun 24 01:21:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 23 Jun 2002 17:21:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-481284 ] GetFileSecurity returns wrong SID
Message-ID: <E17MHc8-0006yZ-00@usw-sf-web4.sourceforge.net>

Bugs item #481284, was opened at 2001-11-14 02:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=481284&group_id=5470

Category: Windows
Group: Platform-specific
Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: Ruben Marquez (rrm1)
Assigned to: Mark Hammond (mhammond)
Summary: GetFileSecurity returns wrong SID

Initial Comment:
The following code printes PySID:S-1-0x008014000000 for
every file on any machine, independent of the real 
ower of the file:

for f in glob.glob("d:/*.*"):
    try:
        o =
win32security.GetFileSecurity
(f,win32security.OWNER_SECURITY_INFORMATION)
        s = win32security.SID(o)
        print str(s),
    except:
        print "n/a",
    print "   ",f

----------
Interestingly,

def prsid(name):
    import string
    print string.rjust(name,20),
    try:
        sid,box,what=win32security.LookupAccountName
(None,name)
        print str(sid),box,what
    except:
        print "oops"

Works well, so it doesn't seem to be a problem with 
PySIDs.

Thanks for your help in resolving this.

P.S.: (Discussed in http://groups.google.com/groups?
hl=en&th=b808d773d7ba0fee)

----------------------------------------------------------------------

Comment By: Darryl Dixon (esrever_otua)
Date: 2002-06-24 12:21

Message:
Logged In: YES 
user_id=567623

Hi Mark,

  Thanks for getting back to me and giving me the chance to 
explore this one.  I'm using ActiveState ActivePython 2.1.1 
build 212.  The Release notes say that this includes your 
Win32 extensions build 135.  I'm on Windows 2000 
Professional Service Pack 2, and am logged in as an 
administrator-level account (so permissions shouldn't be an 
issue).  
I had a look at the RAM where the fileSecurity object was 
referenced at, and first line of memory looks like this:
unsigned char data[16] = {
	0x01, 0x00, 0x00, 0x00, 0x28, 0xB9, 0x60, 0x1E, 
0xD0, 0x94, 0x8A, 0x00, 0x00, 0x00, 0x00, 0x00
};
Dunno if that's really relevant at all, as I haven't yet 
familiarised myself with how this type of object is structured, 
but if it's any use to you, great :-)

Any other information I can supply or things that I can do for 
you on this I am happy to go through, I'd love to get this 
working,

Thanks heaps,
Darryl Dixon
exec("def\040me(list=
[97,117,116,111,95,114,101,118,101,114,115,101]):\n\tretstr=''
\n\tfor\040i\040in\040range(0,len(list)):\n\t\tretstr+='chr('+str
(list.pop())+')+'\n\treturn\040retstr[:-1]\nprint\040eval(me())")

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-06-24 11:15

Message:
Logged In: YES 
user_id=14198

What OS are you on, and what version of win32all.  It works
fine for me.

>>> import win32security
>>> fileSecurity =
win32security.GetFileSecurity('f:/windows',win32security.OWNER_SECURITY_INFORMATION)
>>> secInfo = fileSecurity.GetSecurityDescriptorOwner()
>>> secInfo
<PySID object at 0x00D18CD8>
>>> 

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-24 10:59

Message:
Logged In: NO 

Hi Mark,

  I've had a read through all of the information that I could on 
this, and the problem resolution that you've outlined here 
doesn't seem to be valid.  That is, if I use:
fileSecurity = win32security.GetFileSecurity
('c:/winnt',win32security.OWNER_SECURITY_INFORMATION)

and then watch fileSecurity in a debugger like Komodo, I find 
that there are only three object methods available, 
fileSecurity.Initialize()
fileSecurity.SetDacl()
fileSecuiryt.SetSecurityDescriptorDacl()

I haven't yet gotten desperate enough to use a tool that 
allows the inspection of the contents of RAM to find out 
what's in the fileSecurity object, but I'm getting close to it... ;-)

To be completely explicit, if I use:
import win32security
fileSecurity = win32security.GetFileSecurity
('c:/winnt',win32security.OWNER_SECURITY_INFORMATION)
secInfo = fileSecurity.GetSecurityDescriptorOwner()

Python errors and the traceback looks like this:
Traceback (most recent call last):
  File "getfilesecurity.py", line 17, in ?
    secInfo = fileSecurity.GetSecurityDesc
AttributeError: GetSecurityDescriptorOwner

I love Python and would dearly like to use this API to do 
some work...  I found a white paper written by someone that 
talked about the possibility of extending a Python module 
with SWIG to use the GetNamedSecurityInfo() API, but I don't 
have a C compiler ATM to knock the code up with :-(
Oh, and just as background, basically, I'm writing a class 
library to allow someone to list each unique NT account that 
has rights to a file/directory and what those (cumulative) 
rights are.  I already have a basic class that will enumerate 
individual user accounts in local groups for me, now I just 
need to extend it to point at groups in ACLs...

Please please please assist;
Cheers,
Darryl Dixon

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-03-28 15:37

Message:
Logged In: YES 
user_id=14198

This is not a bug.  The SID() function does not take a
SECURITY_DESCRIPTOR.  The fact it *seems* to is an artifact
of a SECURITY_DESCRIPTOR implementing the buffer protocol,
and the fact that SID() can be constructed with a buffer
assumed to be valid SID bits.  Thus, your code is attempting
to create a SID from the bits in the SECURITY_DESCRIPTOR.

The code should change to:
    o =
win32security.GetFileSecurity(f,win32security.OWNER_SECURITY_INFORMATION)
    s = o.GetSecurityDescriptorOwner()

s is not the SID of the owner of the file.  There is also
GetSecurityDescriptorGroup(), etc.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-11-14 05:00

Message:
Logged In: YES 
user_id=31435

Reassigned to MarkH, as this is in the Win32 extensions.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=481284&group_id=5470



From noreply@sourceforge.net  Mon Jun 24 01:25:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 23 Jun 2002 17:25:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-481284 ] GetFileSecurity returns wrong SID
Message-ID: <E17MHfg-0005qB-00@usw-sf-web2.sourceforge.net>

Bugs item #481284, was opened at 2001-11-14 00:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=481284&group_id=5470

Category: Windows
Group: Platform-specific
Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: Ruben Marquez (rrm1)
Assigned to: Mark Hammond (mhammond)
Summary: GetFileSecurity returns wrong SID

Initial Comment:
The following code printes PySID:S-1-0x008014000000 for
every file on any machine, independent of the real 
ower of the file:

for f in glob.glob("d:/*.*"):
    try:
        o =
win32security.GetFileSecurity
(f,win32security.OWNER_SECURITY_INFORMATION)
        s = win32security.SID(o)
        print str(s),
    except:
        print "n/a",
    print "   ",f

----------
Interestingly,

def prsid(name):
    import string
    print string.rjust(name,20),
    try:
        sid,box,what=win32security.LookupAccountName
(None,name)
        print str(sid),box,what
    except:
        print "oops"

Works well, so it doesn't seem to be a problem with 
PySIDs.

Thanks for your help in resolving this.

P.S.: (Discussed in http://groups.google.com/groups?
hl=en&th=b808d773d7ba0fee)

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-06-24 10:25

Message:
Logged In: YES 
user_id=14198

It appears the new functions arrived in win32all-141 and
later.  You can either try upgrading ActivePython, or
downloading Python from python.org and win32all from my
starship pages.

----------------------------------------------------------------------

Comment By: Darryl Dixon (esrever_otua)
Date: 2002-06-24 10:21

Message:
Logged In: YES 
user_id=567623

Hi Mark,

  Thanks for getting back to me and giving me the chance to 
explore this one.  I'm using ActiveState ActivePython 2.1.1 
build 212.  The Release notes say that this includes your 
Win32 extensions build 135.  I'm on Windows 2000 
Professional Service Pack 2, and am logged in as an 
administrator-level account (so permissions shouldn't be an 
issue).  
I had a look at the RAM where the fileSecurity object was 
referenced at, and first line of memory looks like this:
unsigned char data[16] = {
	0x01, 0x00, 0x00, 0x00, 0x28, 0xB9, 0x60, 0x1E, 
0xD0, 0x94, 0x8A, 0x00, 0x00, 0x00, 0x00, 0x00
};
Dunno if that's really relevant at all, as I haven't yet 
familiarised myself with how this type of object is structured, 
but if it's any use to you, great :-)

Any other information I can supply or things that I can do for 
you on this I am happy to go through, I'd love to get this 
working,

Thanks heaps,
Darryl Dixon
exec("def\040me(list=
[97,117,116,111,95,114,101,118,101,114,115,101]):\n\tretstr=''
\n\tfor\040i\040in\040range(0,len(list)):\n\t\tretstr+='chr('+str
(list.pop())+')+'\n\treturn\040retstr[:-1]\nprint\040eval(me())")

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-06-24 09:15

Message:
Logged In: YES 
user_id=14198

What OS are you on, and what version of win32all.  It works
fine for me.

>>> import win32security
>>> fileSecurity =
win32security.GetFileSecurity('f:/windows',win32security.OWNER_SECURITY_INFORMATION)
>>> secInfo = fileSecurity.GetSecurityDescriptorOwner()
>>> secInfo
<PySID object at 0x00D18CD8>
>>> 

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-24 08:59

Message:
Logged In: NO 

Hi Mark,

  I've had a read through all of the information that I could on 
this, and the problem resolution that you've outlined here 
doesn't seem to be valid.  That is, if I use:
fileSecurity = win32security.GetFileSecurity
('c:/winnt',win32security.OWNER_SECURITY_INFORMATION)

and then watch fileSecurity in a debugger like Komodo, I find 
that there are only three object methods available, 
fileSecurity.Initialize()
fileSecurity.SetDacl()
fileSecuiryt.SetSecurityDescriptorDacl()

I haven't yet gotten desperate enough to use a tool that 
allows the inspection of the contents of RAM to find out 
what's in the fileSecurity object, but I'm getting close to it... ;-)

To be completely explicit, if I use:
import win32security
fileSecurity = win32security.GetFileSecurity
('c:/winnt',win32security.OWNER_SECURITY_INFORMATION)
secInfo = fileSecurity.GetSecurityDescriptorOwner()

Python errors and the traceback looks like this:
Traceback (most recent call last):
  File "getfilesecurity.py", line 17, in ?
    secInfo = fileSecurity.GetSecurityDesc
AttributeError: GetSecurityDescriptorOwner

I love Python and would dearly like to use this API to do 
some work...  I found a white paper written by someone that 
talked about the possibility of extending a Python module 
with SWIG to use the GetNamedSecurityInfo() API, but I don't 
have a C compiler ATM to knock the code up with :-(
Oh, and just as background, basically, I'm writing a class 
library to allow someone to list each unique NT account that 
has rights to a file/directory and what those (cumulative) 
rights are.  I already have a basic class that will enumerate 
individual user accounts in local groups for me, now I just 
need to extend it to point at groups in ACLs...

Please please please assist;
Cheers,
Darryl Dixon

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-03-28 14:37

Message:
Logged In: YES 
user_id=14198

This is not a bug.  The SID() function does not take a
SECURITY_DESCRIPTOR.  The fact it *seems* to is an artifact
of a SECURITY_DESCRIPTOR implementing the buffer protocol,
and the fact that SID() can be constructed with a buffer
assumed to be valid SID bits.  Thus, your code is attempting
to create a SID from the bits in the SECURITY_DESCRIPTOR.

The code should change to:
    o =
win32security.GetFileSecurity(f,win32security.OWNER_SECURITY_INFORMATION)
    s = o.GetSecurityDescriptorOwner()

s is not the SID of the owner of the file.  There is also
GetSecurityDescriptorGroup(), etc.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-11-14 03:00

Message:
Logged In: YES 
user_id=31435

Reassigned to MarkH, as this is in the Win32 extensions.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=481284&group_id=5470



From noreply@sourceforge.net  Mon Jun 24 01:56:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 23 Jun 2002 17:56:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-481284 ] GetFileSecurity returns wrong SID
Message-ID: <E17MI9W-00066s-00@usw-sf-web2.sourceforge.net>

Bugs item #481284, was opened at 2001-11-14 02:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=481284&group_id=5470

Category: Windows
Group: Platform-specific
Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: Ruben Marquez (rrm1)
Assigned to: Mark Hammond (mhammond)
Summary: GetFileSecurity returns wrong SID

Initial Comment:
The following code printes PySID:S-1-0x008014000000 for
every file on any machine, independent of the real 
ower of the file:

for f in glob.glob("d:/*.*"):
    try:
        o =
win32security.GetFileSecurity
(f,win32security.OWNER_SECURITY_INFORMATION)
        s = win32security.SID(o)
        print str(s),
    except:
        print "n/a",
    print "   ",f

----------
Interestingly,

def prsid(name):
    import string
    print string.rjust(name,20),
    try:
        sid,box,what=win32security.LookupAccountName
(None,name)
        print str(sid),box,what
    except:
        print "oops"

Works well, so it doesn't seem to be a problem with 
PySIDs.

Thanks for your help in resolving this.

P.S.: (Discussed in http://groups.google.com/groups?
hl=en&th=b808d773d7ba0fee)

----------------------------------------------------------------------

Comment By: Darryl Dixon (esrever_otua)
Date: 2002-06-24 12:56

Message:
Logged In: YES 
user_id=567623

Hi Mark,

  Thanks heaps for the pointer - ActiveState's last distribution 
of Python 2.1 (2.1.3 build 214) includes your Win32all build 
145... And, sure enough, when I dir(fileSecurity) I can now 
see three new useful methods :-D  yah!.  I knew Python was 
the right tool for the job ;-)
Just as a side note, I have to take this opportunity (as 
probably the only one I'll get) to say thanks for your awesome 
contribution of the win32all libraries - they must surely be 
responsible for most of the adoption of Python on the Win* 
platform.  Awesome stuff.

Cheers,
Darryl Dixon

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-06-24 12:25

Message:
Logged In: YES 
user_id=14198

It appears the new functions arrived in win32all-141 and
later.  You can either try upgrading ActivePython, or
downloading Python from python.org and win32all from my
starship pages.

----------------------------------------------------------------------

Comment By: Darryl Dixon (esrever_otua)
Date: 2002-06-24 12:21

Message:
Logged In: YES 
user_id=567623

Hi Mark,

  Thanks for getting back to me and giving me the chance to 
explore this one.  I'm using ActiveState ActivePython 2.1.1 
build 212.  The Release notes say that this includes your 
Win32 extensions build 135.  I'm on Windows 2000 
Professional Service Pack 2, and am logged in as an 
administrator-level account (so permissions shouldn't be an 
issue).  
I had a look at the RAM where the fileSecurity object was 
referenced at, and first line of memory looks like this:
unsigned char data[16] = {
	0x01, 0x00, 0x00, 0x00, 0x28, 0xB9, 0x60, 0x1E, 
0xD0, 0x94, 0x8A, 0x00, 0x00, 0x00, 0x00, 0x00
};
Dunno if that's really relevant at all, as I haven't yet 
familiarised myself with how this type of object is structured, 
but if it's any use to you, great :-)

Any other information I can supply or things that I can do for 
you on this I am happy to go through, I'd love to get this 
working,

Thanks heaps,
Darryl Dixon
exec("def\040me(list=
[97,117,116,111,95,114,101,118,101,114,115,101]):\n\tretstr=''
\n\tfor\040i\040in\040range(0,len(list)):\n\t\tretstr+='chr('+str
(list.pop())+')+'\n\treturn\040retstr[:-1]\nprint\040eval(me())")

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-06-24 11:15

Message:
Logged In: YES 
user_id=14198

What OS are you on, and what version of win32all.  It works
fine for me.

>>> import win32security
>>> fileSecurity =
win32security.GetFileSecurity('f:/windows',win32security.OWNER_SECURITY_INFORMATION)
>>> secInfo = fileSecurity.GetSecurityDescriptorOwner()
>>> secInfo
<PySID object at 0x00D18CD8>
>>> 

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-24 10:59

Message:
Logged In: NO 

Hi Mark,

  I've had a read through all of the information that I could on 
this, and the problem resolution that you've outlined here 
doesn't seem to be valid.  That is, if I use:
fileSecurity = win32security.GetFileSecurity
('c:/winnt',win32security.OWNER_SECURITY_INFORMATION)

and then watch fileSecurity in a debugger like Komodo, I find 
that there are only three object methods available, 
fileSecurity.Initialize()
fileSecurity.SetDacl()
fileSecuiryt.SetSecurityDescriptorDacl()

I haven't yet gotten desperate enough to use a tool that 
allows the inspection of the contents of RAM to find out 
what's in the fileSecurity object, but I'm getting close to it... ;-)

To be completely explicit, if I use:
import win32security
fileSecurity = win32security.GetFileSecurity
('c:/winnt',win32security.OWNER_SECURITY_INFORMATION)
secInfo = fileSecurity.GetSecurityDescriptorOwner()

Python errors and the traceback looks like this:
Traceback (most recent call last):
  File "getfilesecurity.py", line 17, in ?
    secInfo = fileSecurity.GetSecurityDesc
AttributeError: GetSecurityDescriptorOwner

I love Python and would dearly like to use this API to do 
some work...  I found a white paper written by someone that 
talked about the possibility of extending a Python module 
with SWIG to use the GetNamedSecurityInfo() API, but I don't 
have a C compiler ATM to knock the code up with :-(
Oh, and just as background, basically, I'm writing a class 
library to allow someone to list each unique NT account that 
has rights to a file/directory and what those (cumulative) 
rights are.  I already have a basic class that will enumerate 
individual user accounts in local groups for me, now I just 
need to extend it to point at groups in ACLs...

Please please please assist;
Cheers,
Darryl Dixon

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-03-28 15:37

Message:
Logged In: YES 
user_id=14198

This is not a bug.  The SID() function does not take a
SECURITY_DESCRIPTOR.  The fact it *seems* to is an artifact
of a SECURITY_DESCRIPTOR implementing the buffer protocol,
and the fact that SID() can be constructed with a buffer
assumed to be valid SID bits.  Thus, your code is attempting
to create a SID from the bits in the SECURITY_DESCRIPTOR.

The code should change to:
    o =
win32security.GetFileSecurity(f,win32security.OWNER_SECURITY_INFORMATION)
    s = o.GetSecurityDescriptorOwner()

s is not the SID of the owner of the file.  There is also
GetSecurityDescriptorGroup(), etc.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-11-14 05:00

Message:
Logged In: YES 
user_id=31435

Reassigned to MarkH, as this is in the Win32 extensions.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=481284&group_id=5470



From noreply@sourceforge.net  Mon Jun 24 03:18:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 23 Jun 2002 19:18:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-571382 ] Numeric Literal Anomoly
Message-ID: <E17MJR4-0002ia-00@usw-sf-web5.sourceforge.net>

Bugs item #571382, was opened at 2002-06-19 19:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571382&group_id=5470

Category: Python Interpreter Core
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Otto J. A. Smith (ottojas)
Assigned to: Tim Peters (tim_one)
Summary: Numeric Literal Anomoly

Initial Comment:
I hope I am not beating a dead horse.  This might have 
been dealt with in the past, although I failed to find any 
reference to it in a search.

A string representation of a numeric literal is evaluated
differently by "int" and "string.atoi" than by "eval".  The 
functions "int" and "string.atoi" treat the leading zero as
a leading zero in a decimal numeric literal, while "eval" 
treats it as an indication of the literal representing an octal 
value.

Consider the string "077"

>>> 0077
63
>>> eval('077')
63
>>> int('0077')
77
>>> string.atoi("0077")
77

It is probably not possible to change the behavior of "int"
or "string.atoi" due to historic reasons.  I would suggest 
adding a method to the string class that does conversions
from hex and octal string literals correctly.

This may seem like a minor problem but should be done for
the following reasons.

1.  Python is a remarkably regular language and my 
favorite for that reason among others.  The current 
behavior deviates from what one might rationally expect 
and is a blemish (although minor) on an otherwise beutiful 
language.

2.  The only quick way to evaluate a hex or octal numeric 
constant that comes from an outside source, such as the 
web, is with "eval".  This poses security risks.  The use of 
custom programs and/or safe-eval seems like overkill and 
one would expect a builti n safe way to convert from any 
string representing a numeric literal to the internal 
representation.

One would expect the functions "oct" and "int" to allow 
conversions back and forth.   Here is what really happens.

>>> oct(77)
'0115'
>>> int(oct(77))
115
>>> oct(int(oct(77)))
'0163'
>>> int(oct(int(oct(77))))
163
>>> oct(int(oct(int(oct(77)))))
'0243'
>>> int(oct(int(oct(int(oct(77))))))
243
>>> oct(int(oct(int(oct(int(oct(77)))))))
'0363'

Although the above is intriguing, it is not really a 
language feature, nor does it generate errors as would
occur with the use of "hex" instead of "oct".

I would suggest the addition of a new method with a new 
name. (maybe "aint") to the string class., a method that 
would evaluate all the forms of integer numeric literals
with the same behavior as "eval".

Regards
Otto



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-06-23 22:18

Message:
Logged In: YES 
user_id=31435

Closed for lack of requested followup.  The int() and long() 
functions already do everything requested here, and more.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-19 20:12

Message:
Logged In: YES 
user_id=31435

Read the docs for the int() function.  Is there something you 
want that you can't already do by passing int an optional 
base argument of 0?:

>>> int('077', 0)
63
>>> int('0x77', 0)
119
>>> int('77', 0)
77
>>>

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571382&group_id=5470



From noreply@sourceforge.net  Mon Jun 24 03:43:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 23 Jun 2002 19:43:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-568269 ] Misleading string constant.
Message-ID: <E17MJpJ-00030b-00@usw-sf-web5.sourceforge.net>

Bugs item #568269, was opened at 2002-06-12 18:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568269&group_id=5470

Category: Documentation
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Bjorn Pettersen (bpettersen)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Misleading string constant.

Initial Comment:
In _winreg.ConnectRegistry() it says:

computer_name is the name of the remote computer, of 
the form "\computername". If None, the local computer 
is used. 

Could it be changed to use r"\computername"? (it just 
took me half an hour to figure out why it couldn't find the 
computer on the network, and I really should know 
better :-)

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-06-23 22:43

Message:
Logged In: YES 
user_id=31435

Ya, this is just the usual business of "how do you spell a 
string that's supposed to have two adjacent backslashes"?  
Using an r-string is indeed easiest.  Using a regular string 
literal with 4 adjacent backslashes would also work.  It's 
really got nothing to do with Windows, except that MS has 
this irritating convention of using backslashes in assorted 
network names.  Back to you, Fred -- happy to be of 
service <wink>.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-13 08:36

Message:
Logged In: YES 
user_id=3066

Tim, can you tell me what the right thing is?  I don't have
enough Windows Registry Zen to know.  Feel free to assign
back to me for action.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=568269&group_id=5470



From noreply@sourceforge.net  Mon Jun 24 04:24:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 23 Jun 2002 20:24:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-571885 ] Segmentation fault in Python 2.3
Message-ID: <E17MKSX-0005qC-00@usw-sf-web1.sourceforge.net>

Bugs item #571885, was opened at 2002-06-20 18:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571885&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Christophe Delord (cdelord)
Assigned to: Jeremy Hylton (jhylton)
Summary: Segmentation fault in Python 2.3

Initial Comment:
It seems there's a bug in python 2.3

The following script works with python 2.2, not with 2.3

def flatten(L):
	for i in L: 
		if type(i) == list: 
			for j in flatten(i):
				yield j
		else:
			yield i 

def mklist(n):
	if n:
		return [ str(n), mklist(n-1), str(n) ] 
	else:
		return []
 
L = mklist(6) 
print "".join(flatten(L))
 
flatten seems to work but join makes a segmentation fault. 
 
It works fine with print "".join(list(flatten(L)))
or when L = mklist(4)

I'm using Python 2.3 with Linux (Redhat)

Best regards,
Christophe Delord.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-23 23:24

Message:
Logged In: YES 
user_id=33168

It's the least I could do, since I introduced the bug.
Sorry about that.  The checkin made sense and fixes
Christophe's problem, so should the bug be closed.
Guido checked in a test too.

----------------------------------------------------------------------

Comment By: Christophe Delord (cdelord)
Date: 2002-06-20 19:42

Message:
Logged In: YES 
user_id=566423

I don't get the segmentation fault any more with this last
update.
Your reactivity is so impressive...
Thanks!

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-20 19:14

Message:
Logged In: YES 
user_id=31392

I think this is fixed in CVS now, but I'm waiting to close
the bug because I don't have a test case for it.  Thanks to
Neal for writing a good checkin message.  (Seriously.)


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-20 19:00

Message:
Logged In: YES 
user_id=31392

I was a bit hasty.  It doesn't dump core everytime, but it
does seem to dump core occasionally.  Here's a stack trace
from gdb:
#0  0x806ad98 in _PyTuple_Resize (pv=0xbffff5d8, newsize=12)
    at ../Objects/tupleobject.c:687
#1  0x80b746a in PySequence_Tuple (v=0x4019c72c) at
../Objects/abstract.c:1347
#2  0x80b94bf in PySequence_Fast (v=0x4019c72c, m=0x80d02dc "")
    at ../Objects/abstract.c:1444
#3  0x8065a71 in string_join (self=0x40148098, orig=0x4019c72c)
    at ../Objects/stringobject.c:1212
#4  0x8088166 in fast_cfunction (func=0x4018db0c,
pp_stack=0xbffff724, na=1)
    at ../Python/ceval.c:3108
#5  0x80868c6 in eval_frame (f=0x810afbc) at
../Python/ceval.c:1975
#6  0x80878b2 in PyEval_EvalCodeEx (co=0x4019b360,
globals=0x4015f2d4, 
    locals=0x4015f2d4, args=0x0, argcount=0, kws=0x0,
kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at ../Python/ceval.c:2553
#7  0x80898e0 in PyEval_EvalCode (co=0x4019b360,
globals=0x4015f2d4, 
    locals=0x4015f2d4) at ../Python/ceval.c:482
#8  0x80a42d1 in run_node (n=0x81402f8, filename=0xbffffb23
"/tmp/foo.py", 
    globals=0x4015f2d4, locals=0x4015f2d4, flags=0xbffff928)
    at ../Python/pythonrun.c:1088
#9  0x80a4282 in run_err_node (n=0x81402f8,
filename=0xbffffb23 "/tmp/foo.py", 
    globals=0x4015f2d4, locals=0x4015f2d4, flags=0xbffff928)
    at ../Python/pythonrun.c:1075
#10 0x80a3f01 in PyRun_FileExFlags (fp=0x8102cb0, 
    filename=0xbffffb23 "/tmp/foo.py", start=257,
globals=0x4015f2d4, 
    locals=0x4015f2d4, closeit=1, flags=0xbffff928)
    at ../Python/pythonrun.c:1066
#11 0x80a2af1 in PyRun_SimpleFileExFlags (fp=0x8102cb0, 
    filename=0xbffffb23 "/tmp/foo.py", closeit=1,
flags=0xbffff928)
    at ../Python/pythonrun.c:697
#12 0x80a3a63 in PyRun_AnyFileExFlags (fp=0x8102cb0, 
    filename=0xbffffb23 "/tmp/foo.py", closeit=1,
flags=0xbffff928)
    at ../Python/pythonrun.c:500
#13 0x805374d in Py_Main (argc=2, argv=0xbffff9b4) at
../Modules/main.c:368
#14 0x8052fea in main (argc=2, argv=0xbffff9b4) at
../Modules/python.c:10
#15 0x40077cbe in __libc_start_main () from /lib/libc.so.6


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-20 18:56

Message:
Logged In: YES 
user_id=31392

The latest CVS on the 2.2 maintenance branch also works
correctly.

I suspect you've hit a bug that is already fixed.  I'm
closing for now, but feel free to re-open if you can provoke
it with a current checkout from CVS.  If so, it would be
helpful if you could provide a stack trace from gdb.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-20 18:52

Message:
Logged In: YES 
user_id=31392

When I run the test script, python2.3 says:
654321123456

If I add a future statement to the script and run it with
2.2, I get a core dump.


----------------------------------------------------------------------

Comment By: Christophe Delord (cdelord)
Date: 2002-06-20 18:50

Message:
Logged In: YES 
user_id=566423

Of course, with a correct indentation, it is:

def flatten(L):
    for i in L:
        if type(i) == list:
            for j in flatten(i):
            yield j
        else:
            yield i

def mklist(n):
    if n:
        return [ str(n), mklist(n-1), str(n) ]
    else:
        return [] 

L = mklist(6)
print "".join(flatten(L))

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571885&group_id=5470



From noreply@sourceforge.net  Mon Jun 24 04:31:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 23 Jun 2002 20:31:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-572567 ] Memory leak in object comparison
Message-ID: <E17MKZS-0005uB-00@usw-sf-web1.sourceforge.net>

Bugs item #572567, was opened at 2002-06-22 15:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=572567&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Jacobs (jacobs99)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Memory leak in object comparison

Initial Comment:
There is a rather obscure memory leak caused
by a missing Py_DECREF one of the comparison
function wrappers in typeobject.c.  It is obscure only 
because it inflates the reference count on methods,
which is why it has gone unnoticed since its inital
checkin on 8/15/2001.  Unfortunately, one of my
meta-class experiments triggers this code on
many ephemoral class instances, and thus leaks 
heaping chunks of memory (or a heaping number of 
little chunks, if you like).

I've attached the simple one line fix, which should
be applied to the next 2.2.x release, and certainly
to the 2.3 CVS tree.  To make myself really useful, 
I've also audited the rest of typeobject.c to make sure 
that all users of 'lookup_method', the source of the 
leaked reference, properly handle its results.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-23 23:31

Message:
Logged In: YES 
user_id=33168

Your patch seems correct. There is an INCREF
in lookup_maybe() which is called by lookup_method().
Also, other places which call lookup_method() do the DECREF.

Could you please attach a test case which triggers this
bug?Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=572567&group_id=5470



From noreply@sourceforge.net  Mon Jun 24 05:31:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 23 Jun 2002 21:31:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-571382 ] Numeric Literal Anomoly
Message-ID: <E17MLVF-0006hh-00@usw-sf-web1.sourceforge.net>

Bugs item #571382, was opened at 2002-06-19 16:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571382&group_id=5470

Category: Python Interpreter Core
Group: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Otto J. A. Smith (ottojas)
Assigned to: Tim Peters (tim_one)
Summary: Numeric Literal Anomoly

Initial Comment:
I hope I am not beating a dead horse.  This might have 
been dealt with in the past, although I failed to find any 
reference to it in a search.

A string representation of a numeric literal is evaluated
differently by "int" and "string.atoi" than by "eval".  The 
functions "int" and "string.atoi" treat the leading zero as
a leading zero in a decimal numeric literal, while "eval" 
treats it as an indication of the literal representing an octal 
value.

Consider the string "077"

>>> 0077
63
>>> eval('077')
63
>>> int('0077')
77
>>> string.atoi("0077")
77

It is probably not possible to change the behavior of "int"
or "string.atoi" due to historic reasons.  I would suggest 
adding a method to the string class that does conversions
from hex and octal string literals correctly.

This may seem like a minor problem but should be done for
the following reasons.

1.  Python is a remarkably regular language and my 
favorite for that reason among others.  The current 
behavior deviates from what one might rationally expect 
and is a blemish (although minor) on an otherwise beutiful 
language.

2.  The only quick way to evaluate a hex or octal numeric 
constant that comes from an outside source, such as the 
web, is with "eval".  This poses security risks.  The use of 
custom programs and/or safe-eval seems like overkill and 
one would expect a builti n safe way to convert from any 
string representing a numeric literal to the internal 
representation.

One would expect the functions "oct" and "int" to allow 
conversions back and forth.   Here is what really happens.

>>> oct(77)
'0115'
>>> int(oct(77))
115
>>> oct(int(oct(77)))
'0163'
>>> int(oct(int(oct(77))))
163
>>> oct(int(oct(int(oct(77)))))
'0243'
>>> int(oct(int(oct(int(oct(77))))))
243
>>> oct(int(oct(int(oct(int(oct(77)))))))
'0363'

Although the above is intriguing, it is not really a 
language feature, nor does it generate errors as would
occur with the use of "hex" instead of "oct".

I would suggest the addition of a new method with a new 
name. (maybe "aint") to the string class., a method that 
would evaluate all the forms of integer numeric literals
with the same behavior as "eval".

Regards
Otto



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-23 21:31

Message:
Logged In: NO 

You are right.
Boy do I feel stupid right now.

Regards
Otto

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-23 19:18

Message:
Logged In: YES 
user_id=31435

Closed for lack of requested followup.  The int() and long() 
functions already do everything requested here, and more.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-19 17:12

Message:
Logged In: YES 
user_id=31435

Read the docs for the int() function.  Is there something you 
want that you can't already do by passing int an optional 
base argument of 0?:

>>> int('077', 0)
63
>>> int('0x77', 0)
119
>>> int('77', 0)
77
>>>

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=571382&group_id=5470



From noreply@sourceforge.net  Mon Jun 24 09:41:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 24 Jun 2002 01:41:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-572567 ] Memory leak in object comparison
Message-ID: <E17MPPA-0003bG-00@usw-sf-web2.sourceforge.net>

Bugs item #572567, was opened at 2002-06-22 14:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=572567&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Jacobs (jacobs99)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Memory leak in object comparison

Initial Comment:
There is a rather obscure memory leak caused
by a missing Py_DECREF one of the comparison
function wrappers in typeobject.c.  It is obscure only 
because it inflates the reference count on methods,
which is why it has gone unnoticed since its inital
checkin on 8/15/2001.  Unfortunately, one of my
meta-class experiments triggers this code on
many ephemoral class instances, and thus leaks 
heaping chunks of memory (or a heaping number of 
little chunks, if you like).

I've attached the simple one line fix, which should
be applied to the next 2.2.x release, and certainly
to the 2.3 CVS tree.  To make myself really useful, 
I've also audited the rest of typeobject.c to make sure 
that all users of 'lookup_method', the source of the 
leaked reference, properly handle its results.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-24 03:41

Message:
Logged In: YES 
user_id=80475

I concur.

And, yes, it would it great to have a unittest that fails 
before the patch and works afterward (perhaps using the 
GC module to demonstrate the leak).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-23 22:31

Message:
Logged In: YES 
user_id=33168

Your patch seems correct. There is an INCREF
in lookup_maybe() which is called by lookup_method().
Also, other places which call lookup_method() do the DECREF.

Could you please attach a test case which triggers this
bug?Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=572567&group_id=5470



From noreply@sourceforge.net  Mon Jun 24 12:21:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 24 Jun 2002 04:21:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-572567 ] Memory leak in object comparison
Message-ID: <E17MRuL-0001p9-00@usw-sf-web5.sourceforge.net>

Bugs item #572567, was opened at 2002-06-22 14:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=572567&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Jacobs (jacobs99)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Memory leak in object comparison

Initial Comment:
There is a rather obscure memory leak caused
by a missing Py_DECREF one of the comparison
function wrappers in typeobject.c.  It is obscure only 
because it inflates the reference count on methods,
which is why it has gone unnoticed since its inital
checkin on 8/15/2001.  Unfortunately, one of my
meta-class experiments triggers this code on
many ephemoral class instances, and thus leaks 
heaping chunks of memory (or a heaping number of 
little chunks, if you like).

I've attached the simple one line fix, which should
be applied to the next 2.2.x release, and certainly
to the 2.3 CVS tree.  To make myself really useful, 
I've also audited the rest of typeobject.c to make sure 
that all users of 'lookup_method', the source of the 
leaked reference, properly handle its results.


----------------------------------------------------------------------

>Comment By: Kevin Jacobs (jacobs99)
Date: 2002-06-24 06:21

Message:
Logged In: YES 
user_id=459565

I've attached a test case that demonstrates and
detects the leak.  There is also a stack trace and 
the code that generates the leaked objects included at the 
bottom of the test case.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-24 03:41

Message:
Logged In: YES 
user_id=80475

I concur.

And, yes, it would it great to have a unittest that fails 
before the patch and works afterward (perhaps using the 
GC module to demonstrate the leak).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-23 22:31

Message:
Logged In: YES 
user_id=33168

Your patch seems correct. There is an INCREF
in lookup_maybe() which is called by lookup_method().
Also, other places which call lookup_method() do the DECREF.

Could you please attach a test case which triggers this
bug?Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=572567&group_id=5470



From noreply@sourceforge.net  Mon Jun 24 14:26:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 24 Jun 2002 06:26:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-572567 ] Memory leak in object comparison
Message-ID: <E17MTrh-0000HZ-00@usw-sf-web1.sourceforge.net>

Bugs item #572567, was opened at 2002-06-22 14:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=572567&group_id=5470

Category: Python Interpreter Core
>Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Kevin Jacobs (jacobs99)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Memory leak in object comparison

Initial Comment:
There is a rather obscure memory leak caused
by a missing Py_DECREF one of the comparison
function wrappers in typeobject.c.  It is obscure only 
because it inflates the reference count on methods,
which is why it has gone unnoticed since its inital
checkin on 8/15/2001.  Unfortunately, one of my
meta-class experiments triggers this code on
many ephemoral class instances, and thus leaks 
heaping chunks of memory (or a heaping number of 
little chunks, if you like).

I've attached the simple one line fix, which should
be applied to the next 2.2.x release, and certainly
to the 2.3 CVS tree.  To make myself really useful, 
I've also audited the rest of typeobject.c to make sure 
that all users of 'lookup_method', the source of the 
leaked reference, properly handle its results.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-24 08:26

Message:
Logged In: YES 
user_id=80475

Committed patch as:
test_descr.py  1.144 and 1.113.4.19
typeobject.c 2.157 and 2.126.4.17

Closing bug.


----------------------------------------------------------------------

Comment By: Kevin Jacobs (jacobs99)
Date: 2002-06-24 06:21

Message:
Logged In: YES 
user_id=459565

I've attached a test case that demonstrates and
detects the leak.  There is also a stack trace and 
the code that generates the leaked objects included at the 
bottom of the test case.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-24 03:41

Message:
Logged In: YES 
user_id=80475

I concur.

And, yes, it would it great to have a unittest that fails 
before the patch and works afterward (perhaps using the 
GC module to demonstrate the leak).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-23 22:31

Message:
Logged In: YES 
user_id=33168

Your patch seems correct. There is an INCREF
in lookup_maybe() which is called by lookup_method().
Also, other places which call lookup_method() do the DECREF.

Could you please attach a test case which triggers this
bug?Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=572567&group_id=5470



From noreply@sourceforge.net  Mon Jun 24 16:40:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 24 Jun 2002 08:40:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-573174 ] OSX IDE behaviour (output to console)
Message-ID: <E17MVwq-00005N-00@usw-sf-web2.sourceforge.net>

Bugs item #573174, was opened at 2002-06-24 09:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=573174&group_id=5470

Category: IDLE
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Carl Hagelberg (chagel)
Assigned to: Nobody/Anonymous (nobody)
Summary: OSX IDE behaviour (output to console)

Initial Comment:

On woensdag, juni 5, 2002, at 05:15 , Carl Hagelberg wrote:

> Hi Jack,
>
> There's a difference between the result of the following 
> example when using
> the interactive window and a 'program window' using
the "Run 
> all" button
> (OSX):
>
> a, b = 0, 1
> while b < 1000:
>     print b,
>     a, b = b, a+b
>
>
> With out the "," after 'print b' they both work the
same. With 
> the comma
> only the interactive window works. Is there a syntax
issue in 
> the program
> window?

Carl,
this is a "known issue", but unfortunately one that is
difficult 
to fix. The IDE flushes output to the console window on 
end-of-line only. It has no knowledge of the print
statement, it 
just sees a stream of characters, and it can flush
either (a) at 
ever character or (b) at every end-of-line. The first
would make 
it horrendously inefficient, so it does the latter. Put
one 
"print" without the comma at the end and everything
will be 
printed.

But: this bug should be noted in the sourceforge bug
list. Could 
you please add it (category Macintosh, assign it to me
or Just 
(jvr))?
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your
revolution -- 
Emma Goldman -



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=573174&group_id=5470



From noreply@sourceforge.net  Mon Jun 24 20:39:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 24 Jun 2002 12:39:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-571334 ] imaplib fetch is broken
Message-ID: <E17MZg9-0007P5-00@usw-sf-web1.sourceforge.net>

Bugs item #571334, was opened at 2002-06-19 16:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=571334&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Goerzen (jgoerzen)
Assigned to: Piers Lauder (pierslauder)
Summary: imaplib fetch is broken

Initial Comment:
This bug is 100% reproducible in Python 2.2.1 and the 
imaplib.py from Python's CVS tree. 
 
They'll send the message body in this form: 
{100} 
Headers here, body here, (100 characters worth) 
 
This is specified in RFC2060 secion 4.3.  imaplib's fetch 
chokes on 
"unexpected data" in the response. 
 
imaplib should receive this prefix-quoted string properly 
and return it in a 
non-quoted fashion. 
 
As it is, it is totally impossible to read messages from 
most imap servers. 
 

----------------------------------------------------------------------

>Comment By: John Goerzen (jgoerzen)
Date: 2002-06-24 14:39

Message:
Logged In: YES 
user_id=491567

 This code is wrong: 
 
data += self.sslobj.read(len(data)-size) 
 
it should be size - len(data) 
 
I'm attaching a version that is known to work. 

----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-23 05:51

Message:
Logged In: YES 
user_id=196212

Changes now checked in - please try them out.


----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-22 16:09

Message:
Logged In: YES 
user_id=196212

My cvs checkin failed, perhaps because sourceforge is too
busy,  so the update is postponed for the time being...

----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-22 15:41

Message:
Logged In: YES 
user_id=196212

I've checked in a new version of imaplib with the IMAP4_SSL
read and send methods modified to deal with short data
results from the sslobj methods.

Let me know if it work for you and I'll mark this bug fixed.


----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 2002-06-20 18:45

Message:
Logged In: YES 
user_id=491567

Note, though, that AFAIK there is no canonical code for 
"read" in python like there is in C.  File objects have a read(), 
socket objects have a read, StringIO has a read, and in this 
case, SSL sockets have a read. 
 
I suspect that it could be an issue unique to SSL sockets. 
 
I'm using Python 2.2.1 with the imaplib.py pulled from the 
development tree's CVS as of two days ago.  Sorry, I don't 
know the exact version number.  I needed that one for the SSL 
support. 
 
It is possible that this could be considered a bug in the SSL 
socket support.  I find it highly annoying that, among other 
things, imaplib.py has to kludge around socket.ssl's lack of 
readline(). 

----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-20 17:45

Message:
Logged In: YES 
user_id=196212

PS: could you also state which imaplib class you are using -
there may be a difference between the socket.socket and
socket.ssl behaviours.


----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-20 17:37

Message:
Logged In: YES 
user_id=196212

I'm very surprised by this. According to the Python library
manual for the read method:

read([size])
 Read at most size bytes from the file (less if the read
hits EOF before obtaining size bytes). If the size argument
is negative or omitted, read all data until EOF is reached.
The bytes are returned as a string object. An empty string
is returned when EOF is encountered immediately. (For
certain files, like ttys, it makes sense to continue reading
after an EOF is hit.) Note that this method may call the
underlying C function fread() more than once in an effort to
acquire as close to size bytes as possible.

So read(size) should return size bytes unless EOF is found.
(And as imaplib has been in use for several years, I take it
the manual is factual :-)

Maybe this is an O/S-specific problem in the python interpreter?
What O/S (and version) is your Python 2.2.1 interpreter
running on?


----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 2002-06-20 09:01

Message:
Logged In: YES 
user_id=491567

It turns out that it is a bug in read() in the imaplib.  It does not 
obey the principle that the read() call will return UP TO the 
amount of bytes specified.  The below diff fixes it for me.  I 
have not yet tried append(), but I suspect that the write calls 
will have the same problem. 
 
--- imaplib.py  18 Jun 2002 15:36:03 -0000      1.1 
+++ imaplib.py  20 Jun 2002 04:02:49 -0000      1.2 
@@ -222,8 +222,10 @@ 
 
     def read(self, size): 
         """Read 'size' bytes from remote.""" 
-        return self.file.read(size) 
- 
+        retval = '' 
+        while len(retval) < size: 
+            retval += self.file.read(size - len(retval)) 
+        return retval 
 
     def readline(self): 
         """Read line from remote.""" 
@@ -1056,7 +1059,10 @@ 
 
     def read(self, size): 
         """Read 'size' bytes from remote.""" 
-        return self.sslobj.read(size) 
+        retval = '' 
+        while len(retval) < size: 
+            retval += self.sslobj.read(size - len(retval)) 
+        return retval 
 
 
     def readline(self): 
 

----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-20 03:46

Message:
Logged In: YES 
user_id=196212

I can't duplicate this.

The test code at the end of imaplib.py includes a FETCH
command which is returned as a literal by my imap server.

Perhaps you could run that test on your server and cut
and paste the response.

Run the test like this:
  python2.2 imaplib.py -d5 <imap_server_host_name>

>From which I get the following:
	...
 43:26.15 > KDP19 UID FETCH 19570 (FLAGS INTERNALDATE
RFC822.SIZE RFC822.HEADER RFC822.TEXT)
  43:26.46 < * 83 FETCH (UID 19570 FLAGS (\Seen)
INTERNALDATE "20-Jun-2002 18:36:51 +1000" RFC822.SIZE 55
RFC822.HEADER {46}
  43:26.46      matched r'\* (?P<data>\d+)
(?P<type>[A-Z-]+)( (?P<data2>.*))?' => ('83', 'FETCH', '
(UID 19570 FLAGS (\Seen) INTERNALDATE "20-Jun-2002 18:36:51
+1000" RFC822.SIZE 55 RFC822.HEADER {46}', '(UID 19570 FLAGS
(\Seen) INTERNALDATE "20-Jun-2002 18:36:51 +1000"
RFC822.SIZE 55 RFC822.HEADER {46}')
  43:26.46      matched r'.*{(?P<size>\d+)}$' => ('46',)
  43:26.47 read literal size 46
	...
and so on.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=571334&group_id=5470



From noreply@sourceforge.net  Tue Jun 25 01:30:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 24 Jun 2002 17:30:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-546434 ] buffer slice type inconsistant
Message-ID: <E17MeDb-0000Af-00@usw-sf-web2.sourceforge.net>

Bugs item #546434, was opened at 2002-04-20 02:21
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=546434&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Donald Wallace Rouse II (dwr2)
Assigned to: Raymond Hettinger (rhettinger)
Summary: buffer slice type inconsistant

Initial Comment:
The type of a buffer slice is either 'buffer' 
or 'str', depending on the slice parameters.
If the slice encompasses the entire buffer, the buffer 
itself is returned.
Otherwise, a string is returned.
Here is a sample session:
--------------------------
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
IDLE 0.8 -- press F1 for help
>>> a="0123456789"
>>> b = buffer(a, 1, 8)
>>> b
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[:]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[:8]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[2:4]
'34'
>>> b[5]
'6'
>>> c = buffer(a, 4, 1)
>>> c
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C8, size 
1 at 0x00AAA370>
>>> c[0]
'4'
>>> c[0:1]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C8, size 
1 at 0x00AAA370>
--------------------------
Either b[:] should produce a string, or, more 
preferably, b[x:y] should be equivalent to buffer(b, 
x, y), and c[0] should be equivalent to buffer(c, 0, 
1).
The reason that the types should be similar is because 
if a buffer is passed to a function that's checking 
for strings, the function should always fail or always 
succeed.

This is especially important because types.BufferType 
isn't in the types.StringTypes list, so the 
expression "type(b) in types.StringTypes" will also 
behave inconsistantly.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-24 19:30

Message:
Logged In: YES 
user_id=80475

I posted twice and got one reply from someone who has a 
deep interest in buffers.  We agreed that returning a string 
was the most useful behavior and that repetition should 
be left intact.  If anyone disagrees later, I will be happy to 
code some other behavior.

Committing the patch for Py2.3 only:  bufferobject.c 
1.434 and NEWS 2.19.  Closing the bug.  


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-21 11:57

Message:
Logged In: YES 
user_id=6380

I think it's best to ask python-dev's opinion on this,
especially as I'm on vacation. :-)

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-21 11:43

Message:
Logged In: YES 
user_id=80475

I can make a fix as you specified by nullifying the 
sq_repeat slot and having the slice routines always return 
a new buffer object.

Still, I'm not sure that that is right thing to do.  All other 
sequence behaviors are defined, so it seems weird to zap 
repetition (though I can't see a use case for it).

Also, I original opted to return strings instead of buffers for 
several reasons.  My reading of the OP was that either way 
was fine as long as it was consistent.  Also, I think it is 
more likely that existing code relies on returning a string 
instead of a buffer (impossible to verify though; I rarely 
see buffer used) as in: print mybuf[2:8].  Buffer appears to 
be designed to be as stringlike as possible so that it can 
be easily substituted in code originally designed for strings.

If you still think returning a buffer is the way to go, I'm 
happy to do it.  One other thought, currently mybuf[:] 
returns self but I think it should return a copy of self to be 
consistent with the idiom:  
   b = a[:]
   assert id(a) != id(b)

Do you want someone else to review this while your out or 
for me to just take care of it?



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-20 13:00

Message:
Logged In: YES 
user_id=6380

Hm, shoudldn't slicing a buffer always return a buffer
object? That's what the OP requested and seems to be the
most consistent. (On the other hand getting a single item
with b[i] should return a character.)

I think that repetition on a buffer object should be an error.

This would be a semantic change that can't be backported to 2.2.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-20 02:35

Message:
Logged In: YES 
user_id=80475

Added Py2.3 patch to make slicing and repetition always 
return a string.  Unsure if it is a 2.2 backport candidate.



----------------------------------------------------------------------

Comment By: Donald Wallace Rouse II (dwr2)
Date: 2002-04-20 02:36

Message:
Logged In: YES 
user_id=111611

Sorry about the formatting; the form wrapped the lines.
A slight correction:
  "b[x:y] should be equivalent to buffer(b, x, y)"
should be
"b[x:y] should be equivalent to buffer(b, x1, y1 - x1), 
where x1 == x if x is positive and len(b) + x if x is 
negative, and similarly for y and y1".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=546434&group_id=5470



From noreply@sourceforge.net  Tue Jun 25 01:39:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 24 Jun 2002 17:39:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-465045 ] base n integer to string conversion
Message-ID: <E17MeMa-0000IY-00@usw-sf-web2.sourceforge.net>

Bugs item #465045, was opened at 2001-09-25 20:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=465045&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: base n integer to string conversion

Initial Comment:
I see that the C files for int and long arithmetic 
already contain format() functions to format the
numbers in arbitrary bases.  The Python-exported
decimal and hex conversion routines simply call
the format function.

I have three suggestions/requests, in increasing order 
of controversy:

1) How about exporting the format routine to Python, 
so there's a builtin function for converting an 
integer object to an arbitrary base 2<=b<=36.
The code is already there--may as well let people
use it.  Something like format(n,base) would be
a simple interface.

2) Right now there's no simple way to convert an
integer to a raw byte string.  I end up doing
something like 
   a = binascii.unhexlify("%x"%n)
which is a kludge.  I'd like to propose that
as a special case, format(n,256) give the raw bytes.

3) Finally, if it's not too weird, format(n,128)
could possibly return the BER (base 128) encoded
representation of n, similar to pack("w",n) in perl.
Bit 8 (the high bit) is set in each byte except
the last.  That means you can read BER integers
byte by byte and know where they end.  They're used
in various security objects like X509 certificates.
If not here, then sooner or later this function
should appear in some library module.

Thanks
Paul


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-24 19:39

Message:
Logged In: YES 
user_id=80475

This is feature request appears to be suffering from lack of 
interest.  If no one speaks-up for it by 27 July 2002, I'll 
close it.

If it is needed, I would be happy to help implement it.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-10-12 09:27

Message:
Logged In: YES 
user_id=6380

OK, I believe you.  Can you submit a patch?

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2001-10-12 02:20

Message:
Logged In: YES 
user_id=72053

The struct module doesn't give any way of converting
arbitrary ints (meaning longs) to binary.  Really, it's
needed.  Some people do it with gmpy, but if Python is
going to support longs as a built-in type, one shouldn't
have to resort to 3rd-party modules to read and write
them in binary.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-10-05 21:09

Message:
Logged In: YES 
user_id=6380

Various forms of fixed-length int to binary conversion are 
provided by the struct module.

What's a "surprising deficiency" for you could simply be 
everybody else's lack of interest -- if nobody needs it, it 
won't be added to the language... :-)

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2001-10-05 18:05

Message:
Logged In: YES 
user_id=72053

Re which bases are useful: I want base 256 all the time and find the lack of
any clean way to convert ints to binary is a surprising deficiency in Python.
I'm not too concerned about what the interface should be, but I hope one is
added.

I agree, BER is a bit obscure, but if you feel it's ok to put it in the binascii
module, I might submit a patch.  How about if I put base-256 there too?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-09-26 11:00

Message:
Logged In: YES 
user_id=31435

1) Base 2 is semi-frequently requested.  Note that Greg 
Wilson has open patch 455076 to add %b format and bin() 
function.  No non-binary base has any fans.

2) I expect Paul means unbounded ints (based on previous 
requests).

3) Yup.  Jeremy's Pisces may already deal w/ this (found 
via Google search).

3') Pickle already represents ints < 256 in one byte, and 
less than 2**16 in 2 (plus a 1-byte type code, of course).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-26 08:38

Message:
Logged In: YES 
user_id=6380

1) Which bases besides 8, 10 and 16 do you plan to use? The
C code strikes me as more general than needed.

2) You can do this with the struct module. No need for
kludges.

3) BER seems pretty esoteric. The binascii module seems the
right place. Feel free to submit a patch!

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2001-09-25 20:45

Message:
Logged In: YES 
user_id=72053

One minor comment: besides representing longs, BER encoded
integers are also good for small integers.  Numbers < 128
are represented in one byte.  If short strings were
marshalled with a BER-encoded length instead of a 4-byte
length, that could save some space in .pyc files and
pickled objects.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=465045&group_id=5470



From noreply@sourceforge.net  Tue Jun 25 01:42:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 24 Jun 2002 17:42:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-480337 ] Tut: Dict used before dicts explained
Message-ID: <E17MeQ6-0000Mr-00@usw-sf-web2.sourceforge.net>

Bugs item #480337, was opened at 2001-11-10 06:21
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=480337&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Bennetts (spiv)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Tut: Dict used before dicts explained

Initial Comment:
This was pointed out to me by someone on #python, who
was rather confused by this...

In Section 5.1.4 of the Tutorial it has an example of a
list comprehension:
"""
>>> [{x: x**2} for x in vec]
[{2: 4}, {4: 16}, {6: 36}]
"""

But the "{x: x**2}" is confusing, because dictionaries
haven't been explained yet (that's Section 5.4).

This example either needs to be removed or modified. 
It is a good example of the sort of expression you can
use in a list comprehension, so I'd recommend adding an
comment referring the reader to Section 5.4, rather
than removing it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=480337&group_id=5470



From noreply@sourceforge.net  Tue Jun 25 04:41:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 24 Jun 2002 20:41:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-480337 ] Tut: Dict used before dicts explained
Message-ID: <E17MhD0-0006Lv-00@usw-sf-web1.sourceforge.net>

Bugs item #480337, was opened at 2001-11-10 06:21
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=480337&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: Andrew Bennetts (spiv)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Tut: Dict used before dicts explained

Initial Comment:
This was pointed out to me by someone on #python, who
was rather confused by this...

In Section 5.1.4 of the Tutorial it has an example of a
list comprehension:
"""
>>> [{x: x**2} for x in vec]
[{2: 4}, {4: 16}, {6: 36}]
"""

But the "{x: x**2}" is confusing, because dictionaries
haven't been explained yet (that's Section 5.4).

This example either needs to be removed or modified. 
It is a good example of the sort of expression you can
use in a list comprehension, so I'd recommend adding an
comment referring the reader to Section 5.4, rather
than removing it.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-24 22:41

Message:
Logged In: YES 
user_id=80475

I think the example should be removed (patch attached) 
not only because of the forward reference, but because 
suggests that it is normal of construct lists of dictionaries.  

Were the dict constructor being introduced, a useful 
example would be:

>>> dict([(x, x**2) for x in vec])
{2: 4, 4: 16, 6: 36}

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=480337&group_id=5470



From noreply@sourceforge.net  Tue Jun 25 05:02:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 24 Jun 2002 21:02:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-497109 ] 'lambda' documentation in strange place
Message-ID: <E17MhWv-0007i4-00@usw-sf-web3.sourceforge.net>

Bugs item #497109, was opened at 2001-12-27 14:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=497109&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: L. Peter Deutsch (lpd)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: 'lambda' documentation in strange place

Initial Comment:
The (Python 2.2) documentation for 'lambda' is in
section 5.10, "Boolean operations". This makes it hard
to find. I suggest putting it in an indexed section of
its own. I originally suggested a 5.3.x section under
"Primaries", but now I'm not so sure that is
appropriate.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-24 23:02

Message:
Logged In: YES 
user_id=80475

Already fixed by JHylton for Py2.3 in ref5.tex 1.58.
New section is 5.11 Lambdas.

Backporting change for Py2.2.  Committed as ref5.tex 
1.53.4.6

Closing bug.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=497109&group_id=5470



From noreply@sourceforge.net  Tue Jun 25 05:34:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 24 Jun 2002 21:34:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-417930 ] += not assigning to same var it reads
Message-ID: <E17Mi1j-00087Y-00@usw-sf-web3.sourceforge.net>

Bugs item #417930, was opened at 2001-04-21 18:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=417930&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: Edward Loper (edloper)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: += not assigning to same var it reads

Initial Comment:
My understanding of the augmented assignment 
statements is that they should always assign to the 
variable that they read from.  However, consider the 
following Python session:
  >>> class A: x = 1  
  ...  
  >>> a=A()
  >>> a.x += 1
  >>> a.x, A.x
  (2, 1)

Here, the expression "a.x += 1" read from a class 
variable, and wrote to an instance variable.  A 
similar effect can occur within a member function:
  >>> class A:
  ...     x = 1
  ...     def f(s): s.x += 1
  ... 
  >>> a = A()
  >>> a.f()
  >>> a.x, A.x
  (2, 1)

I have elicited this behavior in Python 2.0 and 2.1 
under Linux (Redhat 6.0), and Python 2.0 on sunos5.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-24 23:34

Message:
Logged In: YES 
user_id=80475

See attached documentation patch.

----------------------------------------------------------------------

Comment By: Chris Cogdon (chriscog)
Date: 2001-05-03 20:00

Message:
Logged In: YES 
user_id=67116

IMHO, this is not a bug. Assignments are always made to the 
class instance, not the class type. X+=1 should be 
equivalent to going X=X+1, and is just so in the above 
cases.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-21 21:46

Message:
Logged In: YES 
user_id=31435

Sorry, but your understanding is flawed.  Changed the 
category to Documentation and assigned to Fred, because I 
agree the Ref Man isn't clear enough here:  "The target is 
evaluated only once" is certainly how Guido *thinks* of it, 
but it really needs a by-cases explanation:

For an attributeref target, the primary expression in the 
reference is evaluated only once, but a getattr is done on 
the RHS and a setattr on the LHS.  That is,

    e1.attr op= e2

acts like

    temp1 = e1
    temp2 = e2
    temp1.attr = temp1.attr op temp2

Etc.  It's going to take some real work to write this up so 
they're comprehensible!  I recommend skipping most words 
and presenting "workalike" pseudo-code sequences instead.  
That will take some sessions with the disassembler to be 
sure the pseudo-code is 100% accurate.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=417930&group_id=5470



From noreply@sourceforge.net  Tue Jun 25 05:56:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 24 Jun 2002 21:56:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-568269 ] Misleading string constant.
Message-ID: <E17MiNE-0002Lb-00@usw-sf-web5.sourceforge.net>

Bugs item #568269, was opened at 2002-06-12 17:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=568269&group_id=5470

Category: Documentation
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Bjorn Pettersen (bpettersen)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Misleading string constant.

Initial Comment:
In _winreg.ConnectRegistry() it says:

computer_name is the name of the remote computer, of 
the form "\computername". If None, the local computer 
is used. 

Could it be changed to use r"\computername"? (it just 
took me half an hour to figure out why it couldn't find the 
computer on the network, and I really should know 
better :-)

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-24 23:56

Message:
Logged In: YES 
user_id=80475

Fixed.
See libwinreg.tex 1.8.and 1.7.18.1


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-23 21:43

Message:
Logged In: YES 
user_id=31435

Ya, this is just the usual business of "how do you spell a 
string that's supposed to have two adjacent backslashes"?  
Using an r-string is indeed easiest.  Using a regular string 
literal with 4 adjacent backslashes would also work.  It's 
really got nothing to do with Windows, except that MS has 
this irritating convention of using backslashes in assorted 
network names.  Back to you, Fred -- happy to be of 
service <wink>.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-13 07:36

Message:
Logged In: YES 
user_id=3066

Tim, can you tell me what the right thing is?  I don't have
enough Windows Registry Zen to know.  Feel free to assign
back to me for action.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=568269&group_id=5470



From noreply@sourceforge.net  Tue Jun 25 14:20:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 25 Jun 2002 06:20:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-480337 ] Tut: Dict used before dicts explained
Message-ID: <E17MqEn-0006z0-00@usw-sf-web1.sourceforge.net>

Bugs item #480337, was opened at 2001-11-10 06:21
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=480337&group_id=5470

Category: Documentation
Group: None
Status: Open
>Resolution: Accepted
Priority: 6
Submitted By: Andrew Bennetts (spiv)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Tut: Dict used before dicts explained

Initial Comment:
This was pointed out to me by someone on #python, who
was rather confused by this...

In Section 5.1.4 of the Tutorial it has an example of a
list comprehension:
"""
>>> [{x: x**2} for x in vec]
[{2: 4}, {4: 16}, {6: 36}]
"""

But the "{x: x**2}" is confusing, because dictionaries
haven't been explained yet (that's Section 5.4).

This example either needs to be removed or modified. 
It is a good example of the sort of expression you can
use in a list comprehension, so I'd recommend adding an
comment referring the reader to Section 5.4, rather
than removing it.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-25 09:20

Message:
Logged In: YES 
user_id=3066

Agreed; check in as patched.

Raymond, feel free to expand the introduction of
dictionaries to include the dict constructor.  ;-)  You're
on a roll!

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-24 23:41

Message:
Logged In: YES 
user_id=80475

I think the example should be removed (patch attached) 
not only because of the forward reference, but because 
suggests that it is normal of construct lists of dictionaries.  

Were the dict constructor being introduced, a useful 
example would be:

>>> dict([(x, x**2) for x in vec])
{2: 4, 4: 16, 6: 36}

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=480337&group_id=5470



From noreply@sourceforge.net  Tue Jun 25 14:23:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 25 Jun 2002 06:23:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-417930 ] += not assigning to same var it reads
Message-ID: <E17MqIJ-0007l8-00@usw-sf-web3.sourceforge.net>

Bugs item #417930, was opened at 2001-04-21 19:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=417930&group_id=5470

Category: Documentation
Group: None
Status: Open
>Resolution: Accepted
Priority: 6
Submitted By: Edward Loper (edloper)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: += not assigning to same var it reads

Initial Comment:
My understanding of the augmented assignment 
statements is that they should always assign to the 
variable that they read from.  However, consider the 
following Python session:
  >>> class A: x = 1  
  ...  
  >>> a=A()
  >>> a.x += 1
  >>> a.x, A.x
  (2, 1)

Here, the expression "a.x += 1" read from a class 
variable, and wrote to an instance variable.  A 
similar effect can occur within a member function:
  >>> class A:
  ...     x = 1
  ...     def f(s): s.x += 1
  ... 
  >>> a = A()
  >>> a.f()
  >>> a.x, A.x
  (2, 1)

I have elicited this behavior in Python 2.0 and 2.1 
under Linux (Redhat 6.0), and Python 2.0 on sunos5.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-25 09:23

Message:
Logged In: YES 
user_id=3066

Thanks!  Check in as patched.  Does the tutorial need
changes as well?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-25 00:34

Message:
Logged In: YES 
user_id=80475

See attached documentation patch.

----------------------------------------------------------------------

Comment By: Chris Cogdon (chriscog)
Date: 2001-05-03 21:00

Message:
Logged In: YES 
user_id=67116

IMHO, this is not a bug. Assignments are always made to the 
class instance, not the class type. X+=1 should be 
equivalent to going X=X+1, and is just so in the above 
cases.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-21 22:46

Message:
Logged In: YES 
user_id=31435

Sorry, but your understanding is flawed.  Changed the 
category to Documentation and assigned to Fred, because I 
agree the Ref Man isn't clear enough here:  "The target is 
evaluated only once" is certainly how Guido *thinks* of it, 
but it really needs a by-cases explanation:

For an attributeref target, the primary expression in the 
reference is evaluated only once, but a getattr is done on 
the RHS and a setattr on the LHS.  That is,

    e1.attr op= e2

acts like

    temp1 = e1
    temp2 = e2
    temp1.attr = temp1.attr op temp2

Etc.  It's going to take some real work to write this up so 
they're comprehensible!  I recommend skipping most words 
and presenting "workalike" pseudo-code sequences instead.  
That will take some sessions with the disassembler to be 
sure the pseudo-code is 100% accurate.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=417930&group_id=5470



From noreply@sourceforge.net  Tue Jun 25 14:40:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 25 Jun 2002 06:40:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-417930 ] += not assigning to same var it reads
Message-ID: <E17MqYV-00005M-00@usw-sf-web4.sourceforge.net>

Bugs item #417930, was opened at 2001-04-21 18:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=417930&group_id=5470

Category: Documentation
Group: None
>Status: Closed
Resolution: Accepted
Priority: 6
Submitted By: Edward Loper (edloper)
Assigned to: Raymond Hettinger (rhettinger)
Summary: += not assigning to same var it reads

Initial Comment:
My understanding of the augmented assignment 
statements is that they should always assign to the 
variable that they read from.  However, consider the 
following Python session:
  >>> class A: x = 1  
  ...  
  >>> a=A()
  >>> a.x += 1
  >>> a.x, A.x
  (2, 1)

Here, the expression "a.x += 1" read from a class 
variable, and wrote to an instance variable.  A 
similar effect can occur within a member function:
  >>> class A:
  ...     x = 1
  ...     def f(s): s.x += 1
  ... 
  >>> a = A()
  >>> a.f()
  >>> a.x, A.x
  (2, 1)

I have elicited this behavior in Python 2.0 and 2.1 
under Linux (Redhat 6.0), and Python 2.0 on sunos5.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-25 08:40

Message:
Logged In: YES 
user_id=80475

Committed as ref6.tex 1.55 and 1.47.4.2.
Closing bug.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-25 08:23

Message:
Logged In: YES 
user_id=3066

Thanks!  Check in as patched.  Does the tutorial need
changes as well?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-24 23:34

Message:
Logged In: YES 
user_id=80475

See attached documentation patch.

----------------------------------------------------------------------

Comment By: Chris Cogdon (chriscog)
Date: 2001-05-03 20:00

Message:
Logged In: YES 
user_id=67116

IMHO, this is not a bug. Assignments are always made to the 
class instance, not the class type. X+=1 should be 
equivalent to going X=X+1, and is just so in the above 
cases.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-21 21:46

Message:
Logged In: YES 
user_id=31435

Sorry, but your understanding is flawed.  Changed the 
category to Documentation and assigned to Fred, because I 
agree the Ref Man isn't clear enough here:  "The target is 
evaluated only once" is certainly how Guido *thinks* of it, 
but it really needs a by-cases explanation:

For an attributeref target, the primary expression in the 
reference is evaluated only once, but a getattr is done on 
the RHS and a setattr on the LHS.  That is,

    e1.attr op= e2

acts like

    temp1 = e1
    temp2 = e2
    temp1.attr = temp1.attr op temp2

Etc.  It's going to take some real work to write this up so 
they're comprehensible!  I recommend skipping most words 
and presenting "workalike" pseudo-code sequences instead.  
That will take some sessions with the disassembler to be 
sure the pseudo-code is 100% accurate.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=417930&group_id=5470



From noreply@sourceforge.net  Tue Jun 25 16:10:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 25 Jun 2002 08:10:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-573663 ] Type slice comparisons
Message-ID: <E17MrxV-0000I7-00@usw-sf-web1.sourceforge.net>

Bugs item #573663, was opened at 2002-06-25 12:10
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=573663&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas J. Duck (tomduck)
Assigned to: Nobody/Anonymous (nobody)
Summary: Type slice comparisons

Initial Comment:
There seems to be a problem in identifing an object of
type 'slice'.  For example, the type of an integer
can be found:

     >>> type(1)
     <type 'int'>

and comparisons are correctly made:

     >>> type(1)==int
     1

However, although the type of a slice can be found:

     >>> type(slice(0,0,0))
     <type 'slice'>

comparisons don't work properly:

     >>> type(slice(0,0,0))==slice
     0

Strangely, the following operation does work:

     >>> type(slice(0,0,0))==type(slice(1,1,1))
     1

So, the behaviour for type 'slice' is at least inconsistent
with other types such as 'int'.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=573663&group_id=5470



From noreply@sourceforge.net  Tue Jun 25 16:14:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 25 Jun 2002 08:14:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-480337 ] Tut: Dict used before dicts explained
Message-ID: <E17Ms1A-0001OL-00@usw-sf-web3.sourceforge.net>

Bugs item #480337, was opened at 2001-11-10 06:21
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=480337&group_id=5470

Category: Documentation
Group: None
>Status: Closed
Resolution: Accepted
Priority: 6
Submitted By: Andrew Bennetts (spiv)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Tut: Dict used before dicts explained

Initial Comment:
This was pointed out to me by someone on #python, who
was rather confused by this...

In Section 5.1.4 of the Tutorial it has an example of a
list comprehension:
"""
>>> [{x: x**2} for x in vec]
[{2: 4}, {4: 16}, {6: 36}]
"""

But the "{x: x**2}" is confusing, because dictionaries
haven't been explained yet (that's Section 5.4).

This example either needs to be removed or modified. 
It is a good example of the sort of expression you can
use in a list comprehension, so I'd recommend adding an
comment referring the reader to Section 5.4, rather
than removing it.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-25 10:14

Message:
Logged In: YES 
user_id=80475

Added dict() constructor introduction.

Committed as tut.tex  1.165 and 1.156.4.1.2.4

Closing bug.


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-25 08:20

Message:
Logged In: YES 
user_id=3066

Agreed; check in as patched.

Raymond, feel free to expand the introduction of
dictionaries to include the dict constructor.  ;-)  You're
on a roll!

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-24 22:41

Message:
Logged In: YES 
user_id=80475

I think the example should be removed (patch attached) 
not only because of the forward reference, but because 
suggests that it is normal of construct lists of dictionaries.  

Were the dict constructor being introduced, a useful 
example would be:

>>> dict([(x, x**2) for x in vec])
{2: 4, 4: 16, 6: 36}

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=480337&group_id=5470



From noreply@sourceforge.net  Tue Jun 25 18:20:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 25 Jun 2002 10:20:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-484603 ] SAX Attribute/AttributesNS class missing
Message-ID: <E17Mtzq-0007OG-00@usw-sf-web5.sourceforge.net>

Bugs item #484603, was opened at 2001-11-22 11:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=484603&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Alexandre Fayolle (afayolle)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: SAX Attribute/AttributesNS class missing

Initial Comment:
In the SAX ContentHandler documentation
(html-doc/lib/content-handler-objects.html), references
are made to classes that are not described elsewhere,
Attributes and AttributesNS. 

Alexandre



----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-25 13:20

Message:
Logged In: YES 
user_id=3066

This was more a matter of discoverability than of omission.
 These interfaces were already documented under the names of
their implementation classes.  The documentation has been
changed to refer only to interface names, and hyperlinks
have been added in strategic locations.

Fixed in Doc/lib/xmlsaxreader.tex revisions 1.4, 1.3.8.1,
and Doc/lib/xmlsaxhandler.tex 1.9, 1.8.6.1.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-12-12 00:55

Message:
Logged In: YES 
user_id=3066

Bumping priority slightly since this is more important than
many of the current omissions, but not so much that it
should block the release.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=484603&group_id=5470



From noreply@sourceforge.net  Tue Jun 25 19:07:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 25 Jun 2002 11:07:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-573663 ] Type slice comparisons
Message-ID: <E17MujI-0003PX-00@usw-sf-web1.sourceforge.net>

Bugs item #573663, was opened at 2002-06-25 10:10
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=573663&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Thomas J. Duck (tomduck)
Assigned to: Nobody/Anonymous (nobody)
Summary: Type slice comparisons

Initial Comment:
There seems to be a problem in identifing an object of
type 'slice'.  For example, the type of an integer
can be found:

     >>> type(1)
     <type 'int'>

and comparisons are correctly made:

     >>> type(1)==int
     1

However, although the type of a slice can be found:

     >>> type(slice(0,0,0))
     <type 'slice'>

comparisons don't work properly:

     >>> type(slice(0,0,0))==slice
     0

Strangely, the following operation does work:

     >>> type(slice(0,0,0))==type(slice(1,1,1))
     1

So, the behaviour for type 'slice' is at least inconsistent
with other types such as 'int'.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-25 13:07

Message:
Logged In: YES 
user_id=80475

You're a little before your time ;)

In Python 2.2, slice() is a builtin function, which is, of 
course, not equal to a slice object.  What does work is:  
type(slice(0,0,0)) == types.SliceType

In Python 2.3, slice() is now its own type constructor and 
your comparision will work fine.

This is the documented behavior and not a bug.  
Hopefully, the upgrade to Py2.3 will make more and more 
intuitive behaviors work right out of the box :-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=573663&group_id=5470



From noreply@sourceforge.net  Tue Jun 25 19:25:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 25 Jun 2002 11:25:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-573663 ] Type slice comparisons
Message-ID: <E17Mv0P-0000W2-00@usw-sf-web2.sourceforge.net>

Bugs item #573663, was opened at 2002-06-25 12:10
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=573663&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Thomas J. Duck (tomduck)
Assigned to: Nobody/Anonymous (nobody)
Summary: Type slice comparisons

Initial Comment:
There seems to be a problem in identifing an object of
type 'slice'.  For example, the type of an integer
can be found:

     >>> type(1)
     <type 'int'>

and comparisons are correctly made:

     >>> type(1)==int
     1

However, although the type of a slice can be found:

     >>> type(slice(0,0,0))
     <type 'slice'>

comparisons don't work properly:

     >>> type(slice(0,0,0))==slice
     0

Strangely, the following operation does work:

     >>> type(slice(0,0,0))==type(slice(1,1,1))
     1

So, the behaviour for type 'slice' is at least inconsistent
with other types such as 'int'.


----------------------------------------------------------------------

>Comment By: Thomas J. Duck (tomduck)
Date: 2002-06-25 15:25

Message:
Logged In: YES 
user_id=568469

Thanks for clearing this up for me, Raymond.

Cheers, Tom


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-25 15:07

Message:
Logged In: YES 
user_id=80475

You're a little before your time ;)

In Python 2.2, slice() is a builtin function, which is, of 
course, not equal to a slice object.  What does work is:  
type(slice(0,0,0)) == types.SliceType

In Python 2.3, slice() is now its own type constructor and 
your comparision will work fine.

This is the documented behavior and not a bug.  
Hopefully, the upgrade to Py2.3 will make more and more 
intuitive behaviors work right out of the box :-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=573663&group_id=5470



From noreply@sourceforge.net  Tue Jun 25 20:16:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 25 Jun 2002 12:16:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-571885 ] Segmentation fault in Python 2.3
Message-ID: <E17MvnI-0004Ve-00@usw-sf-web1.sourceforge.net>

Bugs item #571885, was opened at 2002-06-20 22:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=571885&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Christophe Delord (cdelord)
Assigned to: Jeremy Hylton (jhylton)
Summary: Segmentation fault in Python 2.3

Initial Comment:
It seems there's a bug in python 2.3

The following script works with python 2.2, not with 2.3

def flatten(L):
	for i in L: 
		if type(i) == list: 
			for j in flatten(i):
				yield j
		else:
			yield i 

def mklist(n):
	if n:
		return [ str(n), mklist(n-1), str(n) ] 
	else:
		return []
 
L = mklist(6) 
print "".join(flatten(L))
 
flatten seems to work but join makes a segmentation fault. 
 
It works fine with print "".join(list(flatten(L)))
or when L = mklist(4)

I'm using Python 2.3 with Linux (Redhat)

Best regards,
Christophe Delord.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-24 03:24

Message:
Logged In: YES 
user_id=33168

It's the least I could do, since I introduced the bug.
Sorry about that.  The checkin made sense and fixes
Christophe's problem, so should the bug be closed.
Guido checked in a test too.

----------------------------------------------------------------------

Comment By: Christophe Delord (cdelord)
Date: 2002-06-20 23:42

Message:
Logged In: YES 
user_id=566423

I don't get the segmentation fault any more with this last
update.
Your reactivity is so impressive...
Thanks!

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-20 23:14

Message:
Logged In: YES 
user_id=31392

I think this is fixed in CVS now, but I'm waiting to close
the bug because I don't have a test case for it.  Thanks to
Neal for writing a good checkin message.  (Seriously.)


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-20 23:00

Message:
Logged In: YES 
user_id=31392

I was a bit hasty.  It doesn't dump core everytime, but it
does seem to dump core occasionally.  Here's a stack trace
from gdb:
#0  0x806ad98 in _PyTuple_Resize (pv=0xbffff5d8, newsize=12)
    at ../Objects/tupleobject.c:687
#1  0x80b746a in PySequence_Tuple (v=0x4019c72c) at
../Objects/abstract.c:1347
#2  0x80b94bf in PySequence_Fast (v=0x4019c72c, m=0x80d02dc "")
    at ../Objects/abstract.c:1444
#3  0x8065a71 in string_join (self=0x40148098, orig=0x4019c72c)
    at ../Objects/stringobject.c:1212
#4  0x8088166 in fast_cfunction (func=0x4018db0c,
pp_stack=0xbffff724, na=1)
    at ../Python/ceval.c:3108
#5  0x80868c6 in eval_frame (f=0x810afbc) at
../Python/ceval.c:1975
#6  0x80878b2 in PyEval_EvalCodeEx (co=0x4019b360,
globals=0x4015f2d4, 
    locals=0x4015f2d4, args=0x0, argcount=0, kws=0x0,
kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at ../Python/ceval.c:2553
#7  0x80898e0 in PyEval_EvalCode (co=0x4019b360,
globals=0x4015f2d4, 
    locals=0x4015f2d4) at ../Python/ceval.c:482
#8  0x80a42d1 in run_node (n=0x81402f8, filename=0xbffffb23
"/tmp/foo.py", 
    globals=0x4015f2d4, locals=0x4015f2d4, flags=0xbffff928)
    at ../Python/pythonrun.c:1088
#9  0x80a4282 in run_err_node (n=0x81402f8,
filename=0xbffffb23 "/tmp/foo.py", 
    globals=0x4015f2d4, locals=0x4015f2d4, flags=0xbffff928)
    at ../Python/pythonrun.c:1075
#10 0x80a3f01 in PyRun_FileExFlags (fp=0x8102cb0, 
    filename=0xbffffb23 "/tmp/foo.py", start=257,
globals=0x4015f2d4, 
    locals=0x4015f2d4, closeit=1, flags=0xbffff928)
    at ../Python/pythonrun.c:1066
#11 0x80a2af1 in PyRun_SimpleFileExFlags (fp=0x8102cb0, 
    filename=0xbffffb23 "/tmp/foo.py", closeit=1,
flags=0xbffff928)
    at ../Python/pythonrun.c:697
#12 0x80a3a63 in PyRun_AnyFileExFlags (fp=0x8102cb0, 
    filename=0xbffffb23 "/tmp/foo.py", closeit=1,
flags=0xbffff928)
    at ../Python/pythonrun.c:500
#13 0x805374d in Py_Main (argc=2, argv=0xbffff9b4) at
../Modules/main.c:368
#14 0x8052fea in main (argc=2, argv=0xbffff9b4) at
../Modules/python.c:10
#15 0x40077cbe in __libc_start_main () from /lib/libc.so.6


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-20 22:56

Message:
Logged In: YES 
user_id=31392

The latest CVS on the 2.2 maintenance branch also works
correctly.

I suspect you've hit a bug that is already fixed.  I'm
closing for now, but feel free to re-open if you can provoke
it with a current checkout from CVS.  If so, it would be
helpful if you could provide a stack trace from gdb.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-20 22:52

Message:
Logged In: YES 
user_id=31392

When I run the test script, python2.3 says:
654321123456

If I add a future statement to the script and run it with
2.2, I get a core dump.


----------------------------------------------------------------------

Comment By: Christophe Delord (cdelord)
Date: 2002-06-20 22:50

Message:
Logged In: YES 
user_id=566423

Of course, with a correct indentation, it is:

def flatten(L):
    for i in L:
        if type(i) == list:
            for j in flatten(i):
            yield j
        else:
            yield i

def mklist(n):
    if n:
        return [ str(n), mklist(n-1), str(n) ]
    else:
        return [] 

L = mklist(6)
print "".join(flatten(L))

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=571885&group_id=5470



From noreply@sourceforge.net  Wed Jun 26 05:56:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 25 Jun 2002 21:56:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-573948 ] Py_Initialize in MFC causes memroy leaks
Message-ID: <E17N4qd-00045l-00@usw-sf-web1.sourceforge.net>

Bugs item #573948, was opened at 2002-06-26 12:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=573948&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: rhinology (rhinology)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_Initialize in MFC causes memroy leaks

Initial Comment:
My Developing Environment is MS Visual Studio.NET.

First I make a python static library (create a Win32 
static library project and copy all pythoncore files to the 
project and build it). Then I create a Win32 console 
application project and put Py_Initialize and Py_Finalize 
in the main function. Everything is OK.

Now I create a MFC application, put Py_Initialize in 
CMyApp::InitInstance and  Py_Finalize in 
CMyApp:ExitInstance. After the program exits (Debug 
Mode), VC++ detects many memory leaks. I try to put 
Py_Finalize in InitInstance, just after the Py_Initialize, 
but the problem still exists.

Python, being a static library, can't be built with MFC 
appplications?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=573948&group_id=5470



From noreply@sourceforge.net  Wed Jun 26 06:03:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 25 Jun 2002 22:03:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-573949 ] ActiveX Script Support Error
Message-ID: <E17N4xg-0005Kc-00@usw-sf-web4.sourceforge.net>

Bugs item #573949, was opened at 2002-06-26 13:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=573949&group_id=5470

Category: Windows
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: rhinology (rhinology)
Assigned to: Tim Peters (tim_one)
Summary: ActiveX Script Support Error

Initial Comment:
CRT (a popular telnet terminal software) supports 
ActiveX Script. Both VBScript and JScript work well with 
CRT. When I use M. Hammond's Python ActiveX Script 
module, Python can only recognize CRT objects the first 
time after CRT is started. If another script (VBScript or 
JScript or even Python itself) is executed, Python won't 
recognize CRT objects any longer.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=573949&group_id=5470



From noreply@sourceforge.net  Wed Jun 26 06:11:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 25 Jun 2002 22:11:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-573949 ] ActiveX Script Support Error
Message-ID: <E17N55o-0005II-00@usw-sf-web3.sourceforge.net>

Bugs item #573949, was opened at 2002-06-26 01:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=573949&group_id=5470

Category: Windows
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: rhinology (rhinology)
>Assigned to: Mark Hammond (mhammond)
Summary: ActiveX Script Support Error

Initial Comment:
CRT (a popular telnet terminal software) supports 
ActiveX Script. Both VBScript and JScript work well with 
CRT. When I use M. Hammond's Python ActiveX Script 
module, Python can only recognize CRT objects the first 
time after CRT is started. If another script (VBScript or 
JScript or even Python itself) is executed, Python won't 
recognize CRT objects any longer.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-06-26 01:11

Message:
Logged In: YES 
user_id=31435

Assigned to Mark for the obvious reason.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=573949&group_id=5470



From noreply@sourceforge.net  Wed Jun 26 08:11:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jun 2002 00:11:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-549038 ] cgitb variable dumps a little flaky
Message-ID: <E17N6xC-0002zv-00@usw-sf-web5.sourceforge.net>

Bugs item #549038, was opened at 2002-04-26 05:11
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549038&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
>Resolution: Works For Me
Priority: 5
Submitted By: Jon Ribbens (jribbens)
Assigned to: Ka-Ping Yee (ping)
Summary: cgitb variable dumps a little flaky

Initial Comment:
First off, easy problem: lookup() should look in 
frame.f_globals["__builtins__"] also. Along the same 
lines, I am not sure if lookup works properly with 
nested scopes, but since I don't use nested scopes in 
any of my code this is not a problem for me ;-)

Secondly, the parsing in scanvars() is somewhat hacky. 
For example, given the following line:

  foo(open(filename).read())

it will think the following variables exist:

  foo
  open
  filename
  ).read

Obviously this last one is incorrect. I am not sure if 
this is easy to fix or not.


----------------------------------------------------------------------

>Comment By: Ka-Ping Yee (ping)
Date: 2002-06-26 00:11

Message:
Logged In: YES 
user_id=45338

The lookup function looks in frame.f_locals, which does the right thing 
with respect to nested scopes as far as i can tell.

I tested the parser and wasn't able to reproduce the problem you described. 

Thanks for the bug report.  I have committed a change that adds the 
lookup in __builtins__.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-28 17:50

Message:
Logged In: YES 
user_id=6380

Nobody except Ka-Ping Ping understands the code in cgitb.py,
so I suggest that you track him down and get him to look at
this bug report. In the past I've performed this service
myself but I'm getting tired of it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549038&group_id=5470



From noreply@sourceforge.net  Wed Jun 26 08:11:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jun 2002 00:11:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-549038 ] cgitb variable dumps a little flaky
Message-ID: <E17N6xm-00030b-00@usw-sf-web5.sourceforge.net>

Bugs item #549038, was opened at 2002-04-26 05:11
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549038&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: Jon Ribbens (jribbens)
Assigned to: Ka-Ping Yee (ping)
Summary: cgitb variable dumps a little flaky

Initial Comment:
First off, easy problem: lookup() should look in 
frame.f_globals["__builtins__"] also. Along the same 
lines, I am not sure if lookup works properly with 
nested scopes, but since I don't use nested scopes in 
any of my code this is not a problem for me ;-)

Secondly, the parsing in scanvars() is somewhat hacky. 
For example, given the following line:

  foo(open(filename).read())

it will think the following variables exist:

  foo
  open
  filename
  ).read

Obviously this last one is incorrect. I am not sure if 
this is easy to fix or not.


----------------------------------------------------------------------

Comment By: Ka-Ping Yee (ping)
Date: 2002-06-26 00:11

Message:
Logged In: YES 
user_id=45338

The lookup function looks in frame.f_locals, which does the right thing 
with respect to nested scopes as far as i can tell.

I tested the parser and wasn't able to reproduce the problem you described. 

Thanks for the bug report.  I have committed a change that adds the 
lookup in __builtins__.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-28 17:50

Message:
Logged In: YES 
user_id=6380

Nobody except Ka-Ping Ping understands the code in cgitb.py,
so I suggest that you track him down and get him to look at
this bug report. In the past I've performed this service
myself but I'm getting tired of it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549038&group_id=5470



From noreply@sourceforge.net  Wed Jun 26 08:27:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jun 2002 00:27:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-573949 ] ActiveX Script Support Error
Message-ID: <E17N7DX-0007Yy-00@usw-sf-web4.sourceforge.net>

Bugs item #573949, was opened at 2002-06-26 15:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=573949&group_id=5470

Category: Windows
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: rhinology (rhinology)
Assigned to: Mark Hammond (mhammond)
Summary: ActiveX Script Support Error

Initial Comment:
CRT (a popular telnet terminal software) supports 
ActiveX Script. Both VBScript and JScript work well with 
CRT. When I use M. Hammond's Python ActiveX Script 
module, Python can only recognize CRT objects the first 
time after CRT is started. If another script (VBScript or 
JScript or even Python itself) is executed, Python won't 
recognize CRT objects any longer.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-06-26 17:27

Message:
Logged In: YES 
user_id=14198

what version of win32all was this?  There was a similar 
problem with ASP which has been fixed in the 147 and 148 
builds.  Can you please try them.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-26 15:11

Message:
Logged In: YES 
user_id=31435

Assigned to Mark for the obvious reason.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=573949&group_id=5470



From noreply@sourceforge.net  Wed Jun 26 11:28:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jun 2002 03:28:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-549038 ] cgitb variable dumps a little flaky
Message-ID: <E17NA2l-0006cY-00@usw-sf-web5.sourceforge.net>

Bugs item #549038, was opened at 2002-04-26 13:11
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549038&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Open
Resolution: Works For Me
Priority: 5
Submitted By: Jon Ribbens (jribbens)
Assigned to: Ka-Ping Yee (ping)
Summary: cgitb variable dumps a little flaky

Initial Comment:
First off, easy problem: lookup() should look in 
frame.f_globals["__builtins__"] also. Along the same 
lines, I am not sure if lookup works properly with 
nested scopes, but since I don't use nested scopes in 
any of my code this is not a problem for me ;-)

Secondly, the parsing in scanvars() is somewhat hacky. 
For example, given the following line:

  foo(open(filename).read())

it will think the following variables exist:

  foo
  open
  filename
  ).read

Obviously this last one is incorrect. I am not sure if 
this is easy to fix or not.


----------------------------------------------------------------------

>Comment By: Jon Ribbens (jribbens)
Date: 2002-06-26 11:28

Message:
Logged In: YES 
user_id=76089

I'm not quite sure why you were unable to reproduce 
the ").read" bit. Try the following code:

import cgitb; cgitb.enable()
filename = "foo"
foo(open(filename).read())

The output includes:

foo undefined, open undefined, filename = 'foo', ).read 
undefined

Do you get something different?

----------------------------------------------------------------------

Comment By: Ka-Ping Yee (ping)
Date: 2002-06-26 08:11

Message:
Logged In: YES 
user_id=45338

The lookup function looks in frame.f_locals, which does the right thing 
with respect to nested scopes as far as i can tell.

I tested the parser and wasn't able to reproduce the problem you described. 

Thanks for the bug report.  I have committed a change that adds the 
lookup in __builtins__.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 01:50

Message:
Logged In: YES 
user_id=6380

Nobody except Ka-Ping Ping understands the code in cgitb.py,
so I suggest that you track him down and get him to look at
this bug report. In the past I've performed this service
myself but I'm getting tired of it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549038&group_id=5470



From noreply@sourceforge.net  Wed Jun 26 11:30:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jun 2002 03:30:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-571334 ] imaplib fetch is broken
Message-ID: <E17NA3r-0001tE-00@usw-sf-web3.sourceforge.net>

Bugs item #571334, was opened at 2002-06-20 07:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=571334&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: John Goerzen (jgoerzen)
Assigned to: Piers Lauder (pierslauder)
Summary: imaplib fetch is broken

Initial Comment:
This bug is 100% reproducible in Python 2.2.1 and the 
imaplib.py from Python's CVS tree. 
 
They'll send the message body in this form: 
{100} 
Headers here, body here, (100 characters worth) 
 
This is specified in RFC2060 secion 4.3.  imaplib's fetch 
chokes on 
"unexpected data" in the response. 
 
imaplib should receive this prefix-quoted string properly 
and return it in a 
non-quoted fashion. 
 
As it is, it is totally impossible to read messages from 
most imap servers. 
 

----------------------------------------------------------------------

>Comment By: Piers Lauder (pierslauder)
Date: 2002-06-26 20:30

Message:
Logged In: YES 
user_id=196212

Thanks for debugging! Fixed.

Tino Lange confirms the new version also works for him on
both linux and windows.

I'm marking this bug fixed.


----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 2002-06-25 05:39

Message:
Logged In: YES 
user_id=491567

 This code is wrong: 
 
data += self.sslobj.read(len(data)-size) 
 
it should be size - len(data) 
 
I'm attaching a version that is known to work. 

----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-23 20:51

Message:
Logged In: YES 
user_id=196212

Changes now checked in - please try them out.


----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-23 07:09

Message:
Logged In: YES 
user_id=196212

My cvs checkin failed, perhaps because sourceforge is too
busy,  so the update is postponed for the time being...

----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-23 06:41

Message:
Logged In: YES 
user_id=196212

I've checked in a new version of imaplib with the IMAP4_SSL
read and send methods modified to deal with short data
results from the sslobj methods.

Let me know if it work for you and I'll mark this bug fixed.


----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 2002-06-21 09:45

Message:
Logged In: YES 
user_id=491567

Note, though, that AFAIK there is no canonical code for 
"read" in python like there is in C.  File objects have a read(), 
socket objects have a read, StringIO has a read, and in this 
case, SSL sockets have a read. 
 
I suspect that it could be an issue unique to SSL sockets. 
 
I'm using Python 2.2.1 with the imaplib.py pulled from the 
development tree's CVS as of two days ago.  Sorry, I don't 
know the exact version number.  I needed that one for the SSL 
support. 
 
It is possible that this could be considered a bug in the SSL 
socket support.  I find it highly annoying that, among other 
things, imaplib.py has to kludge around socket.ssl's lack of 
readline(). 

----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-21 08:45

Message:
Logged In: YES 
user_id=196212

PS: could you also state which imaplib class you are using -
there may be a difference between the socket.socket and
socket.ssl behaviours.


----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-21 08:37

Message:
Logged In: YES 
user_id=196212

I'm very surprised by this. According to the Python library
manual for the read method:

read([size])
 Read at most size bytes from the file (less if the read
hits EOF before obtaining size bytes). If the size argument
is negative or omitted, read all data until EOF is reached.
The bytes are returned as a string object. An empty string
is returned when EOF is encountered immediately. (For
certain files, like ttys, it makes sense to continue reading
after an EOF is hit.) Note that this method may call the
underlying C function fread() more than once in an effort to
acquire as close to size bytes as possible.

So read(size) should return size bytes unless EOF is found.
(And as imaplib has been in use for several years, I take it
the manual is factual :-)

Maybe this is an O/S-specific problem in the python interpreter?
What O/S (and version) is your Python 2.2.1 interpreter
running on?


----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 2002-06-21 00:01

Message:
Logged In: YES 
user_id=491567

It turns out that it is a bug in read() in the imaplib.  It does not 
obey the principle that the read() call will return UP TO the 
amount of bytes specified.  The below diff fixes it for me.  I 
have not yet tried append(), but I suspect that the write calls 
will have the same problem. 
 
--- imaplib.py  18 Jun 2002 15:36:03 -0000      1.1 
+++ imaplib.py  20 Jun 2002 04:02:49 -0000      1.2 
@@ -222,8 +222,10 @@ 
 
     def read(self, size): 
         """Read 'size' bytes from remote.""" 
-        return self.file.read(size) 
- 
+        retval = '' 
+        while len(retval) < size: 
+            retval += self.file.read(size - len(retval)) 
+        return retval 
 
     def readline(self): 
         """Read line from remote.""" 
@@ -1056,7 +1059,10 @@ 
 
     def read(self, size): 
         """Read 'size' bytes from remote.""" 
-        return self.sslobj.read(size) 
+        retval = '' 
+        while len(retval) < size: 
+            retval += self.sslobj.read(size - len(retval)) 
+        return retval 
 
 
     def readline(self): 
 

----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-06-20 18:46

Message:
Logged In: YES 
user_id=196212

I can't duplicate this.

The test code at the end of imaplib.py includes a FETCH
command which is returned as a literal by my imap server.

Perhaps you could run that test on your server and cut
and paste the response.

Run the test like this:
  python2.2 imaplib.py -d5 <imap_server_host_name>

>From which I get the following:
	...
 43:26.15 > KDP19 UID FETCH 19570 (FLAGS INTERNALDATE
RFC822.SIZE RFC822.HEADER RFC822.TEXT)
  43:26.46 < * 83 FETCH (UID 19570 FLAGS (\Seen)
INTERNALDATE "20-Jun-2002 18:36:51 +1000" RFC822.SIZE 55
RFC822.HEADER {46}
  43:26.46      matched r'\* (?P<data>\d+)
(?P<type>[A-Z-]+)( (?P<data2>.*))?' => ('83', 'FETCH', '
(UID 19570 FLAGS (\Seen) INTERNALDATE "20-Jun-2002 18:36:51
+1000" RFC822.SIZE 55 RFC822.HEADER {46}', '(UID 19570 FLAGS
(\Seen) INTERNALDATE "20-Jun-2002 18:36:51 +1000"
RFC822.SIZE 55 RFC822.HEADER {46}')
  43:26.46      matched r'.*{(?P<size>\d+)}$' => ('46',)
  43:26.47 read literal size 46
	...
and so on.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=571334&group_id=5470



From noreply@sourceforge.net  Wed Jun 26 12:06:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jun 2002 04:06:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-574057 ] pydoc(.org) does not find file.flush()
Message-ID: <E17NAcb-0006LB-00@usw-sf-web2.sourceforge.net>

Bugs item #574057, was opened at 2002-06-26 13:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574057&group_id=5470

Category: Documentation
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Maryniak (maryniak)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: pydoc(.org) does not find file.flush()

Initial Comment:
Dear reader(s),

On http://pydoc.org/ a search for 'flush'
(of the builtin File object) does not find it
(I knew Python had to have a C-ish fflush()
 and of course I did find it in the end).

This is strange, because 'class __builtin__.file' does
occur in pydoc, e.g. search on 'open' and it finds:

  http://web.pydoc.org/2.2/__builtin__.html#file

And there flush() is also sitting there:

  http://web.pydoc.org/2.2/__builtin__.html#file-flush

A grateful pydoc(.org) user, kind regards,

Eric
-- 
Eric Maryniak <e.maryniak@pobox.com>
WWW homepage: http://pobox.com/~e.maryniak/


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574057&group_id=5470



From noreply@sourceforge.net  Wed Jun 26 15:32:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jun 2002 07:32:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-574057 ] pydoc(.org) does not find file.flush()
Message-ID: <E17NDqj-00045t-00@usw-sf-web1.sourceforge.net>

Bugs item #574057, was opened at 2002-06-26 07:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574057&group_id=5470

>Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Maryniak (maryniak)
>Assigned to: Tim Peters (tim_one)
Summary: pydoc(.org) does not find file.flush()

Initial Comment:
Dear reader(s),

On http://pydoc.org/ a search for 'flush'
(of the builtin File object) does not find it
(I knew Python had to have a C-ish fflush()
 and of course I did find it in the end).

This is strange, because 'class __builtin__.file' does
occur in pydoc, e.g. search on 'open' and it finds:

  http://web.pydoc.org/2.2/__builtin__.html#file

And there flush() is also sitting there:

  http://web.pydoc.org/2.2/__builtin__.html#file-flush

A grateful pydoc(.org) user, kind regards,

Eric
-- 
Eric Maryniak <e.maryniak@pobox.com>
WWW homepage: http://pobox.com/~e.maryniak/


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-26 10:32

Message:
Logged In: YES 
user_id=3066

pydoc is Tim's favorite module.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574057&group_id=5470



From noreply@sourceforge.net  Wed Jun 26 16:33:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jun 2002 08:33:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-574132 ] Major GC related performance regression
Message-ID: <E17NEnC-0001rH-00@usw-sf-web2.sourceforge.net>

Bugs item #574132, was opened at 2002-06-26 10:33
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574132&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Jacobs (jacobs99)
Assigned to: Nobody/Anonymous (nobody)
Summary: Major GC related performance regression

Initial Comment:
A change in the Python 2.3 CVS tree has resulted
in a major performance regression.  It shows up
when allocating large lists of objects, but only when
the garbage collector is enabled.  I've attached a simple
script that I use to measure the time it takes to
incrementally append a large number of objects into
a single Python list.   For previous versions of
Python (up to and including 2.2.1), the time scaled
linearly with the number of elements added to the
list (or close enough for the list sizes considered).  
However, with the Python 2.3 CVS version,
the time required to build the list scales quadratically.

Here is the core of my benchmark:
  rows = []
  start = time.time()
  for i in indices:
    rows.append( (1,) )

See the attached file for the full source as well
as timing results for several versions of Python
with and without garbage collection enabled.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574132&group_id=5470



From noreply@sourceforge.net  Wed Jun 26 16:46:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jun 2002 08:46:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-574140 ] Major GC related performance regression
Message-ID: <E17NF05-0005Vl-00@usw-sf-web1.sourceforge.net>

Bugs item #574140, was opened at 2002-06-26 10:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574140&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Jacobs (jacobs99)
Assigned to: Nobody/Anonymous (nobody)
Summary: Major GC related performance regression

Initial Comment:
A change in the Python 2.3 CVS tree has resulted
in a major performance regression.  It shows up
when allocating large lists of objects, but only when
the garbage collector is enabled.  I've attached a simple
script that I use to measure the time it takes to
incrementally append a large number of objects into
a single Python list.   For previous versions of
Python (up to and including 2.2.1), the time scaled
linearly with the number of elements added to the
list (or close enough for the list sizes considered).  
However, with the Python 2.3 CVS version,
the time required to build the list scales quadratically.

Here is the core of my benchmark:
  rows = []
  start = time.time()
  for i in indices:
    rows.append( (1,) )

See the attached file for the full source as well
as timing results for several versions of Python
with and without garbage collection enabled.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574140&group_id=5470



From noreply@sourceforge.net  Wed Jun 26 16:47:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jun 2002 08:47:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-574140 ] Major GC related performance regression
Message-ID: <E17NF0o-0004BH-00@usw-sf-web5.sourceforge.net>

Bugs item #574140, was opened at 2002-06-26 10:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574140&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Deleted
>Resolution: Duplicate
Priority: 5
Submitted By: Kevin Jacobs (jacobs99)
Assigned to: Nobody/Anonymous (nobody)
Summary: Major GC related performance regression

Initial Comment:
A change in the Python 2.3 CVS tree has resulted
in a major performance regression.  It shows up
when allocating large lists of objects, but only when
the garbage collector is enabled.  I've attached a simple
script that I use to measure the time it takes to
incrementally append a large number of objects into
a single Python list.   For previous versions of
Python (up to and including 2.2.1), the time scaled
linearly with the number of elements added to the
list (or close enough for the list sizes considered).  
However, with the Python 2.3 CVS version,
the time required to build the list scales quadratically.

Here is the core of my benchmark:
  rows = []
  start = time.time()
  for i in indices:
    rows.append( (1,) )

See the attached file for the full source as well
as timing results for several versions of Python
with and without garbage collection enabled.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574140&group_id=5470



From noreply@sourceforge.net  Wed Jun 26 18:40:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jun 2002 10:40:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows)
Message-ID: <E17NGmn-0006cY-00@usw-sf-web5.sourceforge.net>

Bugs item #216289, was opened at 2000-10-06 19:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: Later
Priority: 3
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: Programs using Tkinter sometimes can't shut down (Windows)

Initial Comment:
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


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-26 10:40

Message:
Logged In: NO 

According to http://tcl.activestate.com ActiveTcl 8.4.0 is now 
available for download.  It is new as of June 24.  I don't know 
whether this will solve our problems or not, but it's worth 
looking into.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-19 06:36

Message:
Logged In: NO 

I just downloaded Ruby 1.6.6 for Windows, which also uses 
Tcl/Tk 8.3 and I experience exactly the same problem there. 
So this is definitely a Tcl problem (but we know that already).

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-06-07 12:01

Message:
Logged In: YES 
user_id=143340

Hmmm. 
I run a Python Tcl/Tk application several times every day - 
the very application that prompted my bug-hunt.

I do use "pythonw.exe" to launch it, but it used to hang 
almost as badly as "python.exe".

Whilst developing this app I used "python.exe" and 
experienced no hang-ups.

The Tcl guys point out that this bug is only one of several 
possible causes of the hang-up, maybe you are just out of 
luck.

The patch has fixed the problem on three Win98 machines, 
all of which exhibited the problem before updating the DLLs.

One thought - are you sure there weren't multiple copies of 
the tcl83.dll and tk83.dll files? My (only) copies were 
in "D:\python20\DLLs"

good luck,
John.


----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-06-03 11:55

Message:
Logged In: YES 
user_id=72656

providing Tim with a fixed DLL exactly according to John 
Popplewell's patch did not fix the problem for him.  That 
makes it seem fishy that John really didn't see the problem 
any more.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-03 09:59

Message:
Logged In: YES 
user_id=31435

I tried replacing Python 2.2.1's tk83.dll and tcl83.dll (from 
Tcl/Tk 8.3.2) with newer matched sets from

A) PythonWare's py21 distribution (Tcl/Tk 8.3.3).

and again from

B) ActiveState's Tcl/Tk 8.3.4.

All the symptoms originally reported here persisted on 
Win98SE despite that.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-22 06:57

Message:
Logged In: NO 

I am new to Python and encountered this bug on my very first 
Tkinter application.  It persists in Python 2.2.1 under 
Windows Me. Needless to say, it makes a bad first 
impression.  Basically, this thread says that Tkinter has been 
broken for a year and a half on a popular platform at a time 
when Python is trying to expand its user base.  Hopefully, this 
bug will be corrected soon.

If Tcl/Tk 8.4 is not released shortly you might try repackaging 
Tkinter for Win32 with an earlier version of Tcl/Tk, such as 
8.0, that doesn't encounter this problem.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 19:36

Message:
Logged In: YES 
user_id=6380

The proper action is to wait until Tcl 8.3.5 is released,
and then shaming someone else in providing you with a set of
Windowsbinaries for Tcl. You may also ask Hobbs if there's a
Windows project file to build Tcl/Tk for Windows.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-03-11 18:31

Message:
Logged In: YES 
user_id=72656

I did end up back-porting this to the 8.3.4+ Tcl CVS on 
2002-02-25, which means it will be in an eventual 8.3.5.  
It is already in the release 8.4 alpha series.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 17:50

Message:
Logged In: YES 
user_id=31435

Back to Guido:  Do you think you know what the proper 
action is?  (You said that's why you reopened it, and 
there's been no new info here since then.)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 16:55

Message:
Logged In: YES 
user_id=143340

I knew I wasn't getting to the heart of it ....

Almost a one-liner!

It has been seriously spoiling my (otherwise crash free) 
Python experience on Win9x - hope it gets fixed soon.

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-25 15:39

Message:
Logged In: YES 
user_id=6380

Reopened until we know what the proper action is.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-02-25 15:32

Message:
Logged In: YES 
user_id=72656

This is mostly correct, and is fixed in the 8.4 Tcl sources 
already (I guess we can backport this).  This was mentioned 
in SF Tcl bug (account for chopped URL):

https://sourceforge.net/tracker/?
func=detail&aid=217982&group_id=10894&atid=110894

and the code comment is:

    /*
     * Only finalize the notifier if a notifier was 
installed in the
     * current thread; there is a route in which this is not
     * guaranteed to be true (when tclWin32Dll.c:DllMain() 
is called
     * with the flag DLL_PROCESS_DETACH by the OS, which 
could be
     * doing so from a thread that's never previously been 
involved
     * with Tcl, e.g. the task manager) so this check is 
important.
     *
     * Fixes Bug #217982 reported by Hugh Vu and Gene 
Leache.
     */
    if (tsdPtr == NULL) {
	return;
    }


----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 14:41

Message:
Logged In: YES 
user_id=143340

This one has been torturing me for a while.

Managed to track it down to a problem inside Tcl.
For the Tcl8.3.4 source distribution the problem is in
the file win/tclWinNotify.c 

void Tcl_FinalizeNotifier(ClientData clientData)
{
    ThreadSpecificData *tsdPtr = 
                         (ThreadSpecificData *) clientData;

    /* sometimes called with tsdPtr == NULL */
    if ( tsdPtr != NULL )
    {
        DeleteCriticalSection(&tsdPtr->crit);
        CloseHandle(tsdPtr->event);

        /*
         * Clean up the timer and messaging 
         * window for this thread.
         */

        if (tsdPtr->hwnd) {
	    KillTimer(tsdPtr->hwnd, INTERVAL_TIMER);
            DestroyWindow(tsdPtr->hwnd);
        }
    }

    /*
     * If this is the last thread to use the notifier, 
     * unregister the notifier window class.
     */

    Tcl_MutexLock(&notifierMutex);
    if ( notifierCount && !--notifierCount ) {
	UnregisterClassA( "TclNotifier", 
                          TclWinGetTclInstance());
    }
    Tcl_MutexUnlock(&notifierMutex);
}

This bodge doesn't address the underlying problem but has 
stopped me from tearing all my hair out,

cheers,
John Popplewell.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-24 15:27

Message:
Logged In: YES 
user_id=31435

FYI, you don't need an IDE to do this -- in Win9x, hit 
Ctrl+Alt+Del and kill the process directly.

A saner <wink> solution is to develop under Win2K, which 
doesn't appear to suffer this problem (the only reports 
I've seen, and experienced myself, came from Win9x boxes).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-24 01:52

Message:
Logged In: NO 

For those who are still trapped in this bug's hell, I will 
gladly share the one thing that saved my sanity:  
WingIDE's 'Kill' command will shut down the program with 
apparent 100% certainty and no fear of lockups.  WingIDE 
has its own issues, so its not a perfect solution, but if 
you are like me and Joe (above) who test in small 
iterations, then using 'Kill' to quit out of your app while 
testing is a workaround that may preserve your sanity.

Perhaps the python gods and the Wing guys can get together 
and tell us how to replicate 'kill' into our code.  For 
now, I'll use WingIDE to edit, and pythonw.exe for my final 
client's delivery.

----------------------------------------------------------------------

Comment By: Howard Lightstone (hlightstone)
Date: 2001-09-05 10:43

Message:
Logged In: YES 
user_id=66570

I sometimes get bunches of these....

A tool I use (Taskinfo2000) reports that (after killing 
winoldap):

python.exe is blocked on a mutex named OLESCELOCKMUTEX.
The reported state is "Console Terminating".  There appears 
to be only one (os) thread running.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-02 13:06

Message:
Logged In: YES 
user_id=31435

No sign of progress on this presumed Tk/Tcl Windows bug in 
over 3 months, so closing it for lack of hope.

----------------------------------------------------------------------

Comment By: Doug Henderson (djhender)
Date: 2001-02-05 21:13

Message:
This was a symptom I saw while tracking down the essence of the problem reported in #131207.  Using Win98SE, I would get an error dialog (GPF?) in the Kernel, and sometimes the dos prompt would not come back.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-12-12 18:00

Message:
Just reproduced w/ current CVS, but didn't hang until the 8th try.

http://dev.scriptics.com/software/tcltk/ says 8.3 is still the latest released version; don't know whether that URL still makes sense, though.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-12-12 12:58

Message:
Tim, can you still reproduce this with the current CVS version?

There's been one critical patch to _tkinter since the 2.0 release.

An alternative would be to try with a newer version of Tcl (isn't 8.4 out already?).


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-15 09:47

Message:
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>

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-13 07:40

Message:
Back to Tim since I have no clue what to do here.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-12 10:25

Message:
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.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-10-07 00:37

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470



From noreply@sourceforge.net  Wed Jun 26 19:35:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jun 2002 11:35:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-574207 ] Chained __slots__ dealloc segfault
Message-ID: <E17NHde-000225-00@usw-sf-web3.sourceforge.net>

Bugs item #574207, was opened at 2002-06-26 18:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574207&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan Hogg (jhogg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Chained __slots__ dealloc segfault

Initial Comment:
With the following script ('foo.py'):

-----
class foo1(object):
    def __init__(self, n):
        self.n = n

class foo2(object):
    def __init__(self, n):
        self.n = n
    __slots__ = ['n']

o = None
for i in xrange(50000):
    o = foo1(o)
print 'alloc OK'
del o 
print 'dealloc OK'

o = None 
for i in xrange(50000):
    o = foo2(o)
print 'alloc OK'
del o 
print 'OK'
-----

Running this results in a segmentation fault in the
second 'del':

-----
onegood1-2% python foo.py
alloc OK
dealloc OK
alloc OK
zsh: 18593 segmentation fault  python foo.py
-----

A gdb stack trace shows:

-----
Program received signal EXC_BAD_ACCESS, Could not
access memory.
0x00037bbc in lookdict_string (mp=0xa7fb8, key=0x191d0,
hash=3882000) at Objects/dictobject.c:306
306     {
(gdb) where
#0  0x00037bbc in lookdict_string (mp=0xa7fb8,
key=0x191d0, hash=3882000) at Objects/dictobject.c:306
#1  0x00018994 in _PyType_Lookup (type=0x3d14f0,
name=0x3b3c10) at Objects/typeobject.c:1227
#2  0x00017348 in lookup_maybe (self=0xbb88f0,
attrstr=0x3d14f0 "", attrobj=0xa0228) at
Objects/typeobject.c:460
#3  0x00016f38 in call_finalizer (self=0xbb88f0) at
Objects/typeobject.c:280
#4  0x00017054 in subtype_dealloc (self=0xbb88f0) at
Objects/typeobject.c:328
#5  0x00017118 in subtype_dealloc (self=0xbb88d0) at
Objects/typeobject.c:353
#6  0x00017118 in subtype_dealloc (self=0xbb88b0) at
Objects/typeobject.c:353
[...]
#5431 0x00017118 in subtype_dealloc (self=0xbe3410) at
Objects/typeobject.c:353
#5432 0x00017118 in subtype_dealloc (self=0xbe33f0) at
Objects/typeobject.c:353
#5433 0x00017118 in subtype_dealloc (self=0xbe33d0) at
Objects/typeobject.c:353
#5434 0x000382f4 in PyDict_DelItem (op=0x3b3300,
key=0x405520) at Objects/dictobject.c:588
#5435 0x0005b348 in eval_frame (f=0x0) at
Python/ceval.c:1550
#5436 0x0005d6fc in PyEval_EvalCodeEx (co=0x3fd760,
globals=0x402d60, locals=0x3804c, args=0x0, argcount=0,
kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at Python/ceval.c:2585
#5437 0x000588e0 in PyEval_EvalCode (co=0x3d14f0,
globals=0x402d60, locals=0x46257b48) at Python/ceval.c:483
#5438 0x00027850 in run_node (n=0x3bfba0,
filename=0x402d60 "", globals=0x3b3300,
locals=0x3b3300, flags=0x3d16e8) at Python/pythonrun.c:1079
#5439 0x000277f4 in run_err_node (n=0x3804c,
filename=0x402d60 "", globals=0x46257b48, locals=0x0,
flags=0x3d16e8) at Python/pythonrun.c:1066
#5440 0x000277c0 in PyRun_FileExFlags (fp=0x80008a98,
filename=0xbffffb46 "foo.py", start=1176861512,
globals=0x3b3300, locals=0x3b3300, closeit=1,
flags=0xbffff9c8) at Python/pythonrun.c:1057
#5441 0x0002683c in PyRun_SimpleFileExFlags
(fp=0x80008a98, filename=0xbffffb46 "foo.py",
closeit=1, flags=0xbffff9c8) at Python/pythonrun.c:685
#5442 0x00026254 in PyRun_AnyFileExFlags
(fp=0x80008a98, filename=0xbffffb46 "foo.py",
closeit=1, flags=0xbffff9c8) at Python/pythonrun.c:495
#5443 0x00005e10 in Py_Main (argc=2, argv=0xbffffab0)
at Modules/main.c:364
#5444 0x00001e2c in _start ()
#5445 0x00001c5c in start ()
-----

The number of objects that can be deallocated depends
on the stacksize, so it appears to be a stack overrun
problem.

This is on a Mac OS X 10.1.5 system, but was originally
reported by Glyph Lefkowitz using Python 2.2.1 on PPC
Linux 2.4.18 (Debian I think) and has been verified
also by Aahz using Python 2.2.1 on Mandrake 8.1.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574207&group_id=5470



From noreply@sourceforge.net  Wed Jun 26 20:48:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jun 2002 12:48:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-574235 ] convert_path fails with empty pathname
Message-ID: <E17NIln-0001hC-00@usw-sf-web1.sourceforge.net>

Bugs item #574235, was opened at 2002-06-26 14:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574235&group_id=5470

Category: Distutils
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Aneesh Dalvi (adalvi)
Assigned to: Nobody/Anonymous (nobody)
Summary: convert_path fails with empty pathname

Initial Comment:
In distutils/util.py, in the function convert_path, I find I 
have to add the following two lines:

def convert_path (pathname):
    ...
    if os.sep == '/':
        return pathname
>>    if pathname=='':
>>        return pathname

This is required when installing piddle-1.0.15 on a Win32 
platform.  It is required under Python 2.1.2 as well as 
2.2.1.

I don't know if it is something specific to piddle, Win32, 
or something else.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574235&group_id=5470



From noreply@sourceforge.net  Wed Jun 26 20:58:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jun 2002 12:58:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-574241 ] Automated daily documentation builds
Message-ID: <E17NIvz-0005xu-00@usw-sf-web2.sourceforge.net>

Bugs item #574241, was opened at 2002-06-26 14:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574241&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Automated daily documentation builds

Initial Comment:
Set-up a cron job or python script to make daily 
rebuilds of the Python documentation at:  
www.python.org/dev/doc/devel

Developers using Windows and not using Cygwin do 
not have a method for doing their own builds.  

I think daily updates would be helpful for all 
developers and would increase the likelihood that 
people check their patches versus current 
documentation.

Also, it increases the chance that someone will notice 
and report a documentation error earlier in the 
release cycle.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574241&group_id=5470



From noreply@sourceforge.net  Thu Jun 27 00:17:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jun 2002 16:17:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-574057 ] pydoc(.org) does not find file.flush()
Message-ID: <E17NM2T-0000uu-00@usw-sf-web2.sourceforge.net>

Bugs item #574057, was opened at 2002-06-26 07:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574057&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Maryniak (maryniak)
>Assigned to: Ka-Ping Yee (ping)
Summary: pydoc(.org) does not find file.flush()

Initial Comment:
Dear reader(s),

On http://pydoc.org/ a search for 'flush'
(of the builtin File object) does not find it
(I knew Python had to have a C-ish fflush()
 and of course I did find it in the end).

This is strange, because 'class __builtin__.file' does
occur in pydoc, e.g. search on 'open' and it finds:

  http://web.pydoc.org/2.2/__builtin__.html#file

And there flush() is also sitting there:

  http://web.pydoc.org/2.2/__builtin__.html#file-flush

A grateful pydoc(.org) user, kind regards,

Eric
-- 
Eric Maryniak <e.maryniak@pobox.com>
WWW homepage: http://pobox.com/~e.maryniak/


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-06-26 19:17

Message:
Logged In: YES 
user_id=31435

Sorry, we've got no connection with pydoc.org, and I have 
no idea how they programmed their search function.  I 
suggest you contact Ping directly:

mailto:ping@lfw.org


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-26 10:32

Message:
Logged In: YES 
user_id=3066

pydoc is Tim's favorite module.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574057&group_id=5470



From noreply@sourceforge.net  Thu Jun 27 02:27:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jun 2002 18:27:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-574207 ] Chained __slots__ dealloc segfault
Message-ID: <E17NO4k-0005vd-00@usw-sf-web5.sourceforge.net>

Bugs item #574207, was opened at 2002-06-26 14:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574207&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan Hogg (jhogg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Chained __slots__ dealloc segfault

Initial Comment:
With the following script ('foo.py'):

-----
class foo1(object):
    def __init__(self, n):
        self.n = n

class foo2(object):
    def __init__(self, n):
        self.n = n
    __slots__ = ['n']

o = None
for i in xrange(50000):
    o = foo1(o)
print 'alloc OK'
del o 
print 'dealloc OK'

o = None 
for i in xrange(50000):
    o = foo2(o)
print 'alloc OK'
del o 
print 'OK'
-----

Running this results in a segmentation fault in the
second 'del':

-----
onegood1-2% python foo.py
alloc OK
dealloc OK
alloc OK
zsh: 18593 segmentation fault  python foo.py
-----

A gdb stack trace shows:

-----
Program received signal EXC_BAD_ACCESS, Could not
access memory.
0x00037bbc in lookdict_string (mp=0xa7fb8, key=0x191d0,
hash=3882000) at Objects/dictobject.c:306
306     {
(gdb) where
#0  0x00037bbc in lookdict_string (mp=0xa7fb8,
key=0x191d0, hash=3882000) at Objects/dictobject.c:306
#1  0x00018994 in _PyType_Lookup (type=0x3d14f0,
name=0x3b3c10) at Objects/typeobject.c:1227
#2  0x00017348 in lookup_maybe (self=0xbb88f0,
attrstr=0x3d14f0 "", attrobj=0xa0228) at
Objects/typeobject.c:460
#3  0x00016f38 in call_finalizer (self=0xbb88f0) at
Objects/typeobject.c:280
#4  0x00017054 in subtype_dealloc (self=0xbb88f0) at
Objects/typeobject.c:328
#5  0x00017118 in subtype_dealloc (self=0xbb88d0) at
Objects/typeobject.c:353
#6  0x00017118 in subtype_dealloc (self=0xbb88b0) at
Objects/typeobject.c:353
[...]
#5431 0x00017118 in subtype_dealloc (self=0xbe3410) at
Objects/typeobject.c:353
#5432 0x00017118 in subtype_dealloc (self=0xbe33f0) at
Objects/typeobject.c:353
#5433 0x00017118 in subtype_dealloc (self=0xbe33d0) at
Objects/typeobject.c:353
#5434 0x000382f4 in PyDict_DelItem (op=0x3b3300,
key=0x405520) at Objects/dictobject.c:588
#5435 0x0005b348 in eval_frame (f=0x0) at
Python/ceval.c:1550
#5436 0x0005d6fc in PyEval_EvalCodeEx (co=0x3fd760,
globals=0x402d60, locals=0x3804c, args=0x0, argcount=0,
kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at Python/ceval.c:2585
#5437 0x000588e0 in PyEval_EvalCode (co=0x3d14f0,
globals=0x402d60, locals=0x46257b48) at Python/ceval.c:483
#5438 0x00027850 in run_node (n=0x3bfba0,
filename=0x402d60 "", globals=0x3b3300,
locals=0x3b3300, flags=0x3d16e8) at Python/pythonrun.c:1079
#5439 0x000277f4 in run_err_node (n=0x3804c,
filename=0x402d60 "", globals=0x46257b48, locals=0x0,
flags=0x3d16e8) at Python/pythonrun.c:1066
#5440 0x000277c0 in PyRun_FileExFlags (fp=0x80008a98,
filename=0xbffffb46 "foo.py", start=1176861512,
globals=0x3b3300, locals=0x3b3300, closeit=1,
flags=0xbffff9c8) at Python/pythonrun.c:1057
#5441 0x0002683c in PyRun_SimpleFileExFlags
(fp=0x80008a98, filename=0xbffffb46 "foo.py",
closeit=1, flags=0xbffff9c8) at Python/pythonrun.c:685
#5442 0x00026254 in PyRun_AnyFileExFlags
(fp=0x80008a98, filename=0xbffffb46 "foo.py",
closeit=1, flags=0xbffff9c8) at Python/pythonrun.c:495
#5443 0x00005e10 in Py_Main (argc=2, argv=0xbffffab0)
at Modules/main.c:364
#5444 0x00001e2c in _start ()
#5445 0x00001c5c in start ()
-----

The number of objects that can be deallocated depends
on the stacksize, so it appears to be a stack overrun
problem.

This is on a Mac OS X 10.1.5 system, but was originally
reported by Glyph Lefkowitz using Python 2.2.1 on PPC
Linux 2.4.18 (Debian I think) and has been verified
also by Aahz using Python 2.2.1 on Mandrake 8.1.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-26 21:27

Message:
Logged In: YES 
user_id=33168

I do not get this problem with current CVS.
I do get this problem with 2.2.1+ (current).
Attaching the test file I used.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574207&group_id=5470



From noreply@sourceforge.net  Thu Jun 27 03:02:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jun 2002 19:02:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-574235 ] convert_path fails with empty pathname
Message-ID: <E17NObq-0006TH-00@usw-sf-web5.sourceforge.net>

Bugs item #574235, was opened at 2002-06-26 15:48
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574235&group_id=5470

Category: Distutils
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Aneesh Dalvi (adalvi)
Assigned to: Nobody/Anonymous (nobody)
Summary: convert_path fails with empty pathname

Initial Comment:
In distutils/util.py, in the function convert_path, I find I 
have to add the following two lines:

def convert_path (pathname):
    ...
    if os.sep == '/':
        return pathname
>>    if pathname=='':
>>        return pathname

This is required when installing piddle-1.0.15 on a Win32 
platform.  It is required under Python 2.1.2 as well as 
2.2.1.

I don't know if it is something specific to piddle, Win32, 
or something else.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-26 22:02

Message:
Logged In: YES 
user_id=33168

This approach seems reasonable.
I've attached a patch.
I'm not sure why an empty path would
be passed, but I suppose it can't hurt to check.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574235&group_id=5470



From noreply@sourceforge.net  Thu Jun 27 03:12:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jun 2002 19:12:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-574207 ] Chained __slots__ dealloc segfault
Message-ID: <E17NOln-0000j2-00@usw-sf-web4.sourceforge.net>

Bugs item #574207, was opened at 2002-06-26 14:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574207&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan Hogg (jhogg)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Chained __slots__ dealloc segfault

Initial Comment:
With the following script ('foo.py'):

-----
class foo1(object):
    def __init__(self, n):
        self.n = n

class foo2(object):
    def __init__(self, n):
        self.n = n
    __slots__ = ['n']

o = None
for i in xrange(50000):
    o = foo1(o)
print 'alloc OK'
del o 
print 'dealloc OK'

o = None 
for i in xrange(50000):
    o = foo2(o)
print 'alloc OK'
del o 
print 'OK'
-----

Running this results in a segmentation fault in the
second 'del':

-----
onegood1-2% python foo.py
alloc OK
dealloc OK
alloc OK
zsh: 18593 segmentation fault  python foo.py
-----

A gdb stack trace shows:

-----
Program received signal EXC_BAD_ACCESS, Could not
access memory.
0x00037bbc in lookdict_string (mp=0xa7fb8, key=0x191d0,
hash=3882000) at Objects/dictobject.c:306
306     {
(gdb) where
#0  0x00037bbc in lookdict_string (mp=0xa7fb8,
key=0x191d0, hash=3882000) at Objects/dictobject.c:306
#1  0x00018994 in _PyType_Lookup (type=0x3d14f0,
name=0x3b3c10) at Objects/typeobject.c:1227
#2  0x00017348 in lookup_maybe (self=0xbb88f0,
attrstr=0x3d14f0 "", attrobj=0xa0228) at
Objects/typeobject.c:460
#3  0x00016f38 in call_finalizer (self=0xbb88f0) at
Objects/typeobject.c:280
#4  0x00017054 in subtype_dealloc (self=0xbb88f0) at
Objects/typeobject.c:328
#5  0x00017118 in subtype_dealloc (self=0xbb88d0) at
Objects/typeobject.c:353
#6  0x00017118 in subtype_dealloc (self=0xbb88b0) at
Objects/typeobject.c:353
[...]
#5431 0x00017118 in subtype_dealloc (self=0xbe3410) at
Objects/typeobject.c:353
#5432 0x00017118 in subtype_dealloc (self=0xbe33f0) at
Objects/typeobject.c:353
#5433 0x00017118 in subtype_dealloc (self=0xbe33d0) at
Objects/typeobject.c:353
#5434 0x000382f4 in PyDict_DelItem (op=0x3b3300,
key=0x405520) at Objects/dictobject.c:588
#5435 0x0005b348 in eval_frame (f=0x0) at
Python/ceval.c:1550
#5436 0x0005d6fc in PyEval_EvalCodeEx (co=0x3fd760,
globals=0x402d60, locals=0x3804c, args=0x0, argcount=0,
kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at Python/ceval.c:2585
#5437 0x000588e0 in PyEval_EvalCode (co=0x3d14f0,
globals=0x402d60, locals=0x46257b48) at Python/ceval.c:483
#5438 0x00027850 in run_node (n=0x3bfba0,
filename=0x402d60 "", globals=0x3b3300,
locals=0x3b3300, flags=0x3d16e8) at Python/pythonrun.c:1079
#5439 0x000277f4 in run_err_node (n=0x3804c,
filename=0x402d60 "", globals=0x46257b48, locals=0x0,
flags=0x3d16e8) at Python/pythonrun.c:1066
#5440 0x000277c0 in PyRun_FileExFlags (fp=0x80008a98,
filename=0xbffffb46 "foo.py", start=1176861512,
globals=0x3b3300, locals=0x3b3300, closeit=1,
flags=0xbffff9c8) at Python/pythonrun.c:1057
#5441 0x0002683c in PyRun_SimpleFileExFlags
(fp=0x80008a98, filename=0xbffffb46 "foo.py",
closeit=1, flags=0xbffff9c8) at Python/pythonrun.c:685
#5442 0x00026254 in PyRun_AnyFileExFlags
(fp=0x80008a98, filename=0xbffffb46 "foo.py",
closeit=1, flags=0xbffff9c8) at Python/pythonrun.c:495
#5443 0x00005e10 in Py_Main (argc=2, argv=0xbffffab0)
at Modules/main.c:364
#5444 0x00001e2c in _start ()
#5445 0x00001c5c in start ()
-----

The number of objects that can be deallocated depends
on the stacksize, so it appears to be a stack overrun
problem.

This is on a Mac OS X 10.1.5 system, but was originally
reported by Glyph Lefkowitz using Python 2.2.1 on PPC
Linux 2.4.18 (Debian I think) and has been verified
also by Aahz using Python 2.2.1 on Mandrake 8.1.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-06-26 22:12

Message:
Logged In: YES 
user_id=31435

Neal, it's odd that you can't provoke a problem.  Try 
boosting MAX.  The del here triggers a chain of 
deallocations that requires call-stack space proportional to 
the length of the object chain (MAX).  This is the kind of 
situation Python's infamous TRASHCAN macros aim at 
worming around, but the slot cleanup code doesn't play 
that game (yet).

Assigned to Guido just because he'll enjoy it <wink>.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-26 21:27

Message:
Logged In: YES 
user_id=33168

I do not get this problem with current CVS.
I do get this problem with 2.2.1+ (current).
Attaching the test file I used.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574207&group_id=5470



From noreply@sourceforge.net  Thu Jun 27 03:32:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jun 2002 19:32:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-574207 ] Chained __slots__ dealloc segfault
Message-ID: <E17NP5b-0007a2-00@usw-sf-web1.sourceforge.net>

Bugs item #574207, was opened at 2002-06-26 14:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574207&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan Hogg (jhogg)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Chained __slots__ dealloc segfault

Initial Comment:
With the following script ('foo.py'):

-----
class foo1(object):
    def __init__(self, n):
        self.n = n

class foo2(object):
    def __init__(self, n):
        self.n = n
    __slots__ = ['n']

o = None
for i in xrange(50000):
    o = foo1(o)
print 'alloc OK'
del o 
print 'dealloc OK'

o = None 
for i in xrange(50000):
    o = foo2(o)
print 'alloc OK'
del o 
print 'OK'
-----

Running this results in a segmentation fault in the
second 'del':

-----
onegood1-2% python foo.py
alloc OK
dealloc OK
alloc OK
zsh: 18593 segmentation fault  python foo.py
-----

A gdb stack trace shows:

-----
Program received signal EXC_BAD_ACCESS, Could not
access memory.
0x00037bbc in lookdict_string (mp=0xa7fb8, key=0x191d0,
hash=3882000) at Objects/dictobject.c:306
306     {
(gdb) where
#0  0x00037bbc in lookdict_string (mp=0xa7fb8,
key=0x191d0, hash=3882000) at Objects/dictobject.c:306
#1  0x00018994 in _PyType_Lookup (type=0x3d14f0,
name=0x3b3c10) at Objects/typeobject.c:1227
#2  0x00017348 in lookup_maybe (self=0xbb88f0,
attrstr=0x3d14f0 "", attrobj=0xa0228) at
Objects/typeobject.c:460
#3  0x00016f38 in call_finalizer (self=0xbb88f0) at
Objects/typeobject.c:280
#4  0x00017054 in subtype_dealloc (self=0xbb88f0) at
Objects/typeobject.c:328
#5  0x00017118 in subtype_dealloc (self=0xbb88d0) at
Objects/typeobject.c:353
#6  0x00017118 in subtype_dealloc (self=0xbb88b0) at
Objects/typeobject.c:353
[...]
#5431 0x00017118 in subtype_dealloc (self=0xbe3410) at
Objects/typeobject.c:353
#5432 0x00017118 in subtype_dealloc (self=0xbe33f0) at
Objects/typeobject.c:353
#5433 0x00017118 in subtype_dealloc (self=0xbe33d0) at
Objects/typeobject.c:353
#5434 0x000382f4 in PyDict_DelItem (op=0x3b3300,
key=0x405520) at Objects/dictobject.c:588
#5435 0x0005b348 in eval_frame (f=0x0) at
Python/ceval.c:1550
#5436 0x0005d6fc in PyEval_EvalCodeEx (co=0x3fd760,
globals=0x402d60, locals=0x3804c, args=0x0, argcount=0,
kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at Python/ceval.c:2585
#5437 0x000588e0 in PyEval_EvalCode (co=0x3d14f0,
globals=0x402d60, locals=0x46257b48) at Python/ceval.c:483
#5438 0x00027850 in run_node (n=0x3bfba0,
filename=0x402d60 "", globals=0x3b3300,
locals=0x3b3300, flags=0x3d16e8) at Python/pythonrun.c:1079
#5439 0x000277f4 in run_err_node (n=0x3804c,
filename=0x402d60 "", globals=0x46257b48, locals=0x0,
flags=0x3d16e8) at Python/pythonrun.c:1066
#5440 0x000277c0 in PyRun_FileExFlags (fp=0x80008a98,
filename=0xbffffb46 "foo.py", start=1176861512,
globals=0x3b3300, locals=0x3b3300, closeit=1,
flags=0xbffff9c8) at Python/pythonrun.c:1057
#5441 0x0002683c in PyRun_SimpleFileExFlags
(fp=0x80008a98, filename=0xbffffb46 "foo.py",
closeit=1, flags=0xbffff9c8) at Python/pythonrun.c:685
#5442 0x00026254 in PyRun_AnyFileExFlags
(fp=0x80008a98, filename=0xbffffb46 "foo.py",
closeit=1, flags=0xbffff9c8) at Python/pythonrun.c:495
#5443 0x00005e10 in Py_Main (argc=2, argv=0xbffffab0)
at Modules/main.c:364
#5444 0x00001e2c in _start ()
#5445 0x00001c5c in start ()
-----

The number of objects that can be deallocated depends
on the stacksize, so it appears to be a stack overrun
problem.

This is on a Mac OS X 10.1.5 system, but was originally
reported by Glyph Lefkowitz using Python 2.2.1 on PPC
Linux 2.4.18 (Debian I think) and has been verified
also by Aahz using Python 2.2.1 on Mandrake 8.1.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-26 22:32

Message:
Logged In: YES 
user_id=33168

I bumped MAX up to 500000 and 2.3 didn't crash.
But then I dropped my max stack size down from 8M to 1M
and that caused the crash.  So the stack handling must be
better in 2.3, but as you point out, still not fixed.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-26 22:12

Message:
Logged In: YES 
user_id=31435

Neal, it's odd that you can't provoke a problem.  Try 
boosting MAX.  The del here triggers a chain of 
deallocations that requires call-stack space proportional to 
the length of the object chain (MAX).  This is the kind of 
situation Python's infamous TRASHCAN macros aim at 
worming around, but the slot cleanup code doesn't play 
that game (yet).

Assigned to Guido just because he'll enjoy it <wink>.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-26 21:27

Message:
Logged In: YES 
user_id=33168

I do not get this problem with current CVS.
I do get this problem with 2.2.1+ (current).
Attaching the test file I used.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574207&group_id=5470



From noreply@sourceforge.net  Thu Jun 27 04:52:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jun 2002 20:52:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-571167 ] glob() fails for network drive in cgi
Message-ID: <E17NQKI-0001XB-00@usw-sf-web3.sourceforge.net>

Bugs item #571167, was opened at 2002-06-19 15:29
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=571167&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
>Priority: 5
Submitted By: Brian Schuweiler (bshoe282)
Assigned to: Nobody/Anonymous (nobody)
Summary: glob() fails for network drive in cgi

Initial Comment:
glob.glob() does not work when globbing a network 
mapped drive while running as a cgi script.  The method 
works fine when run as a normal python script (even for 
mapped drives), but does not work when run from a 
browser as a cgi script.  The glob returns an empty list 
as if the drive just isn't there.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=571167&group_id=5470



From noreply@sourceforge.net  Thu Jun 27 04:55:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jun 2002 20:55:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-559117 ] HTTPSConnection memory leakage
Message-ID: <E17NQN6-000220-00@usw-sf-web4.sourceforge.net>

Bugs item #559117, was opened at 2002-05-22 11:09
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=559117&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
>Priority: 3
Submitted By: Paolo Andreetto (pandreetto)
>Assigned to: Jeremy Hylton (jhylton)
Summary: HTTPSConnection memory leakage

Initial Comment:
I've tried this test script:

import time,httplib,gc

gc.set_debug(gc.DEBUG_STATS)

while 1:
	conn=httplib.HTTPSConnection('<myhostip>')
	conn.connect()
	conn.request('GET', '/index.html')
	res=conn.getresponse()
	conn.close()
	time.sleep(1)
	print gc.collect()

and I've seen that a memory leakage occurs. The process
requires 4Kbytes every 10 seconds. The output of
garbage collector shows that at the end of each cycle a
new object is contained into last generation.
I've tried also to remove from the script both the
conn.request and the conn.getresponse but nothing has
changed; perhaps the problem is in the connect() method.
All tests run on linux (debian distribution, sid
version for i386) with kernel 2.4.18 and python 2.1.3.
The web server is apache with mod-ssl on redhat 7.2.


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-27 03:55

Message:
Logged In: YES 
user_id=31392

Some of the SSL fixes should back reported to 2.1, if we 
ever to a 2.1.4 release.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-06 15:25

Message:
Logged In: YES 
user_id=31392

Several leaks were fixed just before Python 2.2b1.  It looks
like those changes were not backported to the 2.1
maintenance branch.  I don't have time to backport the
changes, but I'd be happy to review a patch.  Since the
problem wouldn't get fix until a (hypothetical) 2.1.4, you
might get more mileage out of an upgrade to 2.2.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=559117&group_id=5470



From noreply@sourceforge.net  Thu Jun 27 05:10:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jun 2002 21:10:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-574132 ] Major GC related performance regression
Message-ID: <E17NQc4-0001lD-00@usw-sf-web3.sourceforge.net>

Bugs item #574132, was opened at 2002-06-26 15:33
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574132&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Jacobs (jacobs99)
Assigned to: Nobody/Anonymous (nobody)
Summary: Major GC related performance regression

Initial Comment:
A change in the Python 2.3 CVS tree has resulted
in a major performance regression.  It shows up
when allocating large lists of objects, but only when
the garbage collector is enabled.  I've attached a simple
script that I use to measure the time it takes to
incrementally append a large number of objects into
a single Python list.   For previous versions of
Python (up to and including 2.2.1), the time scaled
linearly with the number of elements added to the
list (or close enough for the list sizes considered).  
However, with the Python 2.3 CVS version,
the time required to build the list scales quadratically.

Here is the core of my benchmark:
  rows = []
  start = time.time()
  for i in indices:
    rows.append( (1,) )

See the attached file for the full source as well
as timing results for several versions of Python
with and without garbage collection enabled.


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-27 04:10

Message:
Logged In: YES 
user_id=31392

The first 4 run calls in this test spenned 70 percent of 
their time in visit_move().

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574132&group_id=5470



From noreply@sourceforge.net  Thu Jun 27 07:54:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 26 Jun 2002 23:54:17 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-574465 ] Docs in DocBook format
Message-ID: <E17NTAX-0004C1-00@usw-sf-web3.sourceforge.net>

Feature Requests item #574465, was opened at 2002-06-27 08:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=574465&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bastian Kleineidam (calvin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Docs in DocBook format

Initial Comment:
The current documentation in LaTeX makes it hard to
convert it to anything other than the supported formats
(PS,PDF,HTML).
To generate all documentation (including .info docs)
you'd have to install TeX (plus some conversion tools),
Perl and Emacs. 

How about making the docs in DocBook format? Its a lot
of work, but it would help format conversion a lot
without installing additional software.

Greetings, Bastian

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=574465&group_id=5470



From noreply@sourceforge.net  Thu Jun 27 08:51:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jun 2002 00:51:17 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-481962 ] Make modules callable
Message-ID: <E17NU3h-0005LX-00@usw-sf-web4.sourceforge.net>

Feature Requests item #481962, was opened at 2001-11-15 15:11
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=481962&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Justin Shaw (justinshaw)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make modules callable

Initial Comment:
Many modules are have the same name as the main class 
they contain.  I.E. 

gnu = Gnuplot.Gnuplot()

Why not make modules callable.  That is if a module 
contains a function called "__init__()" then that 
fucntion gets called whenever the code

x = module(args)

is encountered.

Just an idea.

----------------------------------------------------------------------

Comment By: Andrew Bennetts (spiv)
Date: 2002-06-27 17:51

Message:
Logged In: YES 
user_id=50945

Wouldn't calling a function named "__call__" make more sense
than "__init__"?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=481962&group_id=5470



From noreply@sourceforge.net  Thu Jun 27 08:53:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jun 2002 00:53:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-573949 ] ActiveX Script Support Error
Message-ID: <E17NU6H-0005Ov-00@usw-sf-web4.sourceforge.net>

Bugs item #573949, was opened at 2002-06-26 15:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=573949&group_id=5470

Category: Windows
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: rhinology (rhinology)
Assigned to: Mark Hammond (mhammond)
Summary: ActiveX Script Support Error

Initial Comment:
CRT (a popular telnet terminal software) supports 
ActiveX Script. Both VBScript and JScript work well with 
CRT. When I use M. Hammond's Python ActiveX Script 
module, Python can only recognize CRT objects the first 
time after CRT is started. If another script (VBScript or 
JScript or even Python itself) is executed, Python won't 
recognize CRT objects any longer.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-06-27 17:53

Message:
Logged In: YES 
user_id=14198

Reporter replied in private mail saying 148 solved the problem.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-06-26 17:27

Message:
Logged In: YES 
user_id=14198

what version of win32all was this?  There was a similar 
problem with ASP which has been fixed in the 147 and 148 
builds.  Can you please try them.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-26 15:11

Message:
Logged In: YES 
user_id=31435

Assigned to Mark for the obvious reason.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=573949&group_id=5470



From noreply@sourceforge.net  Thu Jun 27 13:47:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jun 2002 05:47:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-495624 ] Error building info docs
Message-ID: <E17NYgh-0000ML-00@usw-sf-web5.sourceforge.net>

Bugs item #495624, was opened at 2001-12-20 16:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=495624&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Error building info docs

Initial Comment:
make info fails ...

Element.pm is from the (Debian) package libhtml-tree-
perl, version 3.11. Any hints, what's wrong?

$ make info
cd info && make
make[1]: Entering directory `/export/swt-
dev/users/doko/packages/python2.2/python2.2-
2.1.99c1/Doc/info'
../tools/mkinfo ../html/api/api.html
perl -
I/home/swt/doko/export/packages/python2.2/python2.2-
2.1.99c1/Doc/tools /home/swt/doko/export/packages/pytho
n2.2/python2.2-
2.1.99c1/Doc/tools/html2texi.pl /home/swt/doko/export/p
ackages/python2.2/python2.2-
2.1.99c1/Doc/html/api/api.html
/usr/share/perl5/HTML/Element.pm:2091: function 
main::output_body expected 3 arguments, got 5: Guido 
van Rossum  1 4 HTML::Element=HASH(0x82c479c) 0
make[1]: *** [python-api.info] Error 255
make[1]: Leaving directory `/export/swt-
dev/users/doko/packages/python2.2/python2.2-
2.1.99c1/Doc/info'
make: *** [info] Error 2


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-27 08:47

Message:
Logged In: YES 
user_id=3066

Is this still a problem?  We updated the info conversions
earlier this year.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2002-01-07 20:01

Message:
Logged In: YES 
user_id=60903

Found updated versions of the conversion scripts

http://pag.lcs.mit.edu/~mernst/software/#html2texi
http://pag.lcs.mit.edu/~mernst/software/#checkargs

with http://pag.lcs.mit.edu/~mernst/software/python-info-
Makefile from the same site I get a step further ...

fixinfo.el is out of date ...

who is pdm/pdm, who builds the info tarballs for download?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=495624&group_id=5470



From noreply@sourceforge.net  Thu Jun 27 14:18:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jun 2002 06:18:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-574570 ] Freeze on Windows missing recent changes
Message-ID: <E17NZAa-0000zY-00@usw-sf-web5.sourceforge.net>

Bugs item #574570, was opened at 2002-06-27 13:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574570&group_id=5470

Category: Demos and Tools
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Lawrence Hudson (lhudson)
Assigned to: Nobody/Anonymous (nobody)
Summary: Freeze on Windows missing recent changes

Initial Comment:
Freeze still references zlib 1.1.3 and does not yet
know about _winreg.

Patches #574531 and #574532 for contain fixes.

Are we the only people using this tool on Windows??


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574570&group_id=5470



From noreply@sourceforge.net  Thu Jun 27 15:04:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jun 2002 07:04:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-574594 ] Search/Expand fails on 2nd set of [ & ]
Message-ID: <E17NZsz-0001l9-00@usw-sf-web5.sourceforge.net>

Bugs item #574594, was opened at 2002-06-27 09:04
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574594&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Moshe Yudkowsky (myudkowsky)
Assigned to: Fredrik Lundh (effbot)
Summary: Search/Expand fails on 2nd set of [ & ]

Initial Comment:
Search followed by an expand or group() fails to select
any data from the string being searched when 

(a) the search pattern seeks a [ and ] in the string, and

(b) the string contains two pairs of [ and ].

I.e., if the search pattern is 

"\[spam.*\] *(.*)"

and then we search two strings:

str1 = "[spam score 10/10] Spammer Junk"

str2 = "[spam score 10/10] Spammer Junk  [spammer's token]"

we should match, and then be able to expand, the entire
remainder of the string excluding the opening [spam
score.*]. However, this only works for the first
string; the second string fails.

I regret to say that the resolution of this problem is
not obvious from the source file.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574594&group_id=5470



From noreply@sourceforge.net  Thu Jun 27 15:25:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jun 2002 07:25:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-574594 ] Search/Expand fails on 2nd set of [ & ]
Message-ID: <E17NaCm-0003fi-00@usw-sf-web3.sourceforge.net>

Bugs item #574594, was opened at 2002-06-27 16:04
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574594&group_id=5470

Category: Regular Expressions
>Group: Not a Bug
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Moshe Yudkowsky (myudkowsky)
Assigned to: Fredrik Lundh (effbot)
Summary: Search/Expand fails on 2nd set of [ & ]

Initial Comment:
Search followed by an expand or group() fails to select
any data from the string being searched when 

(a) the search pattern seeks a [ and ] in the string, and

(b) the string contains two pairs of [ and ].

I.e., if the search pattern is 

"\[spam.*\] *(.*)"

and then we search two strings:

str1 = "[spam score 10/10] Spammer Junk"

str2 = "[spam score 10/10] Spammer Junk  [spammer's token]"

we should match, and then be able to expand, the entire
remainder of the string excluding the opening [spam
score.*]. However, this only works for the first
string; the second string fails.

I regret to say that the resolution of this problem is
not obvious from the source file.


----------------------------------------------------------------------

>Comment By: Fredrik Lundh (effbot)
Date: 2002-06-27 16:25

Message:
Logged In: YES 
user_id=38376

it may be surprising, but this is the expected behaviour: 
the "*" operator always matches as much as it possibly can.  
in your second example, the ".*\]" part matches the entire 
second string, and the " *(.*)" then happily matches the rest 
(an empty string).

I suggest changing the pattern to:

"\[spam[^\]]*\] *(.*)"

</F>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574594&group_id=5470



From noreply@sourceforge.net  Thu Jun 27 15:35:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jun 2002 07:35:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-574605 ] Message.as_string() fails for multipart
Message-ID: <E17NaMj-00071m-00@usw-sf-web2.sourceforge.net>

Bugs item #574605, was opened at 2002-06-27 09:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574605&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Moshe Yudkowsky (myudkowsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: Message.as_string() fails for multipart

Initial Comment:
email.Message.Message has a method as_string(), which
according to documentation should print out the entire
message. However, if I build up a message using
add_payload() several times, as_string() fails.

as_string() fails because the message body becomes a
list instead of a string if it's a multipart message.

I enclose a file that "fixes" this problem; it's for
email/Generator.py, class Generator, and replaces def 
_handle_text(). Intead of testing for just type String,
it tests for type String and type List; if it's a list,
it tests to see that each list item is a string, and
then concatenates the strings into a string for printout.

Someone better versed in Message had better review this!



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574605&group_id=5470



From noreply@sourceforge.net  Thu Jun 27 20:15:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jun 2002 12:15:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-570057 ] Broken pre.subn() (and pre.sub())
Message-ID: <E17Nek8-0003tC-00@usw-sf-web2.sourceforge.net>

Bugs item #570057, was opened at 2002-06-17 16:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570057&group_id=5470

Category: Regular Expressions
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Johan Tufvesson (tuben)
Assigned to: Fredrik Lundh (effbot)
Summary: Broken pre.subn() (and pre.sub())

Initial Comment:
The functions pre.subn() and pre.sub() are broken in
Python2.2 and 2.2.1. The following test was done on
SunOS 5.6:

Python 2.2.1 (#1, Jun 13 2002, 12:57:34) 
[GCC 2.95.2 19991024 (release)] on sunos5
Type "help", "copyright", "credits" or "license" for
more information.
>>> import re
>>> re.sub('(a)', '\g<1>', 'bab')
'bab'
>>> import pre as re
>>> re.sub('(a)', '\g<1>', 'bab')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/tools/lib/python2.2/pre.py", line
179, in sub
    return pattern.sub(repl, string, count)
  File "/usr/local/tools/lib/python2.2/pre.py", line
344, in sub
    return self.subn(repl, string, count)[0]
  File "/usr/local/tools/lib/python2.2/pre.py", line
366, in subn
    repl = pcre_expand(_Dummy, repl)
TypeError: 'NoneType' object is not callable

The error has also been reproduced on SunOS5.7 with the
following interpreter:
Python 2.2 (#1, Dec 28 2001, 22:25:04) 
[GCC 2.95.2 19991024 (release)] on sunos5

The error could not be reproduced on SunOS5.6 using
Python2.1.1:
Python 2.1.1 (#5, Sep 10 2001, 13:44:17) 
[GCC 2.95.2 19991024 (release)] on sunos5

NOTE: The example for re.sub() in the Python Library
manual triggers this bug when used with module pre!


----------------------------------------------------------------------

>Comment By: Fredrik Lundh (effbot)
Date: 2002-06-27 21:15

Message:
Logged In: YES 
user_id=38376

someone who didn't understand the code changed an
"except" to "except error", and the test suite doesn't
spend much energy checking that PRE works as it
should... :-(

(as a workaround, change the line after the "pcre_expand"
call to "except:")

</F>


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570057&group_id=5470



From noreply@sourceforge.net  Thu Jun 27 20:34:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jun 2002 12:34:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-574742 ] Missing docs for module textwrap
Message-ID: <E17Nf2b-0004wW-00@usw-sf-web1.sourceforge.net>

Bugs item #574742, was opened at 2002-06-27 15:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574742&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Greg Ward (gward)
Summary: Missing docs for module textwrap

Initial Comment:
The textwrap module is not documented in the Python
Library Reference.  Please write & check-in the
documentation as Doc/lib/libtextwrap.tex.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574742&group_id=5470



From noreply@sourceforge.net  Thu Jun 27 21:04:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jun 2002 13:04:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-574570 ] Freeze on Windows missing recent changes
Message-ID: <E17NfUx-00014H-00@usw-sf-web4.sourceforge.net>

Bugs item #574570, was opened at 2002-06-27 09:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574570&group_id=5470

Category: Demos and Tools
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Lawrence Hudson (lhudson)
Assigned to: Nobody/Anonymous (nobody)
Summary: Freeze on Windows missing recent changes

Initial Comment:
Freeze still references zlib 1.1.3 and does not yet
know about _winreg.

Patches #574531 and #574532 for contain fixes.

Are we the only people using this tool on Windows??


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-06-27 16:04

Message:
Logged In: YES 
user_id=31435

AFAIK, freeze is never tested on Windows as part of the 
PythonLabs release process.  Meaning it's certainly not 
tested by anyone in PythonLabs, and I have no reason to 
suspect it's tested by anyone else either.  Indeed. the PL 
Windows distro doesn't even include freeze, and it was a 
surprise to me that you use it <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574570&group_id=5470



From noreply@sourceforge.net  Thu Jun 27 21:19:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jun 2002 13:19:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-570057 ] Broken pre.subn() (and pre.sub())
Message-ID: <E17Nfk8-00011f-00@usw-sf-web3.sourceforge.net>

Bugs item #570057, was opened at 2002-06-17 16:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570057&group_id=5470

Category: Regular Expressions
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Johan Tufvesson (tuben)
Assigned to: Fredrik Lundh (effbot)
Summary: Broken pre.subn() (and pre.sub())

Initial Comment:
The functions pre.subn() and pre.sub() are broken in
Python2.2 and 2.2.1. The following test was done on
SunOS 5.6:

Python 2.2.1 (#1, Jun 13 2002, 12:57:34) 
[GCC 2.95.2 19991024 (release)] on sunos5
Type "help", "copyright", "credits" or "license" for
more information.
>>> import re
>>> re.sub('(a)', '\g<1>', 'bab')
'bab'
>>> import pre as re
>>> re.sub('(a)', '\g<1>', 'bab')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/tools/lib/python2.2/pre.py", line
179, in sub
    return pattern.sub(repl, string, count)
  File "/usr/local/tools/lib/python2.2/pre.py", line
344, in sub
    return self.subn(repl, string, count)[0]
  File "/usr/local/tools/lib/python2.2/pre.py", line
366, in subn
    repl = pcre_expand(_Dummy, repl)
TypeError: 'NoneType' object is not callable

The error has also been reproduced on SunOS5.7 with the
following interpreter:
Python 2.2 (#1, Dec 28 2001, 22:25:04) 
[GCC 2.95.2 19991024 (release)] on sunos5

The error could not be reproduced on SunOS5.6 using
Python2.1.1:
Python 2.1.1 (#5, Sep 10 2001, 13:44:17) 
[GCC 2.95.2 19991024 (release)] on sunos5

NOTE: The example for re.sub() in the Python Library
manual triggers this bug when used with module pre!


----------------------------------------------------------------------

>Comment By: Fredrik Lundh (effbot)
Date: 2002-06-27 22:19

Message:
Logged In: YES 
user_id=38376

fixed in CVS

----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2002-06-27 21:15

Message:
Logged In: YES 
user_id=38376

someone who didn't understand the code changed an
"except" to "except error", and the test suite doesn't
spend much energy checking that PRE works as it
should... :-(

(as a workaround, change the line after the "pcre_expand"
call to "except:")

</F>


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570057&group_id=5470



From noreply@sourceforge.net  Thu Jun 27 21:37:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jun 2002 13:37:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-574773 ] removedirs() is not a recursive function
Message-ID: <E17Ng1d-00055j-00@usw-sf-web2.sourceforge.net>

Bugs item #574773, was opened at 2002-06-27 20:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574773&group_id=5470

Category: Documentation
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Dani (asqui)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: removedirs() is not a recursive function

Initial Comment:
The _Python Library Reference_, section 6.1.4: os: Files 
and Directories_ lists the following definition of 
os.removedirs():

removedirs(path) 
 Recursive directory removal function. Works like rmdir() 
except that, if the leaf directory is successfully removed, 
directories corresponding to rightmost path segments 
will be pruned way until either the whole path is 
consumed or an error is raised (which is ignored, 
because it generally means that a parent directory is not 
empty). Throws an error exception if the leaf directory 
could not be successfully removed. New in version 
1.5.2. 

>From what I can see there is nothing recursive about 
os.removedirs(), just simple iteration.

This is misleading because it suggests something like 
removedirs('foo/bar/') will remove 'foo/bar/' and all its 
subdirectories, providing they are empty. When in fact 
what it does is remove directory foo/bar/ if it is empty, 
then remove foo/ if it is empty.

(I'm fairly new to python so I could be mistaken, but I 
checked with peers on IRC who instructed me to submit 
a bug report.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574773&group_id=5470



From noreply@sourceforge.net  Fri Jun 28 02:15:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jun 2002 18:15:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-574570 ] Freeze on Windows missing recent changes
Message-ID: <E17NkMB-0002eR-00@usw-sf-web1.sourceforge.net>

Bugs item #574570, was opened at 2002-06-27 23:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574570&group_id=5470

Category: Demos and Tools
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Lawrence Hudson (lhudson)
>Assigned to: Mark Hammond (mhammond)
Summary: Freeze on Windows missing recent changes

Initial Comment:
Freeze still references zlib 1.1.3 and does not yet
know about _winreg.

Patches #574531 and #574532 for contain fixes.

Are we the only people using this tool on Windows??


----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-06-28 11:15

Message:
Logged In: YES 
user_id=14198

Patch 574531 was just checked in.  574532 appears to contain
no patch.  I will close this report when the missing patch
is uploaded.

Thanks!

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-28 06:04

Message:
Logged In: YES 
user_id=31435

AFAIK, freeze is never tested on Windows as part of the 
PythonLabs release process.  Meaning it's certainly not 
tested by anyone in PythonLabs, and I have no reason to 
suspect it's tested by anyone else either.  Indeed. the PL 
Windows distro doesn't even include freeze, and it was a 
surprise to me that you use it <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574570&group_id=5470



From noreply@sourceforge.net  Fri Jun 28 02:19:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jun 2002 18:19:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-571167 ] glob() fails for network drive in cgi
Message-ID: <E17NkQV-0002hm-00@usw-sf-web1.sourceforge.net>

Bugs item #571167, was opened at 2002-06-20 01:29
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=571167&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Schuweiler (bshoe282)
>Assigned to: Mark Hammond (mhammond)
Summary: glob() fails for network drive in cgi

Initial Comment:
glob.glob() does not work when globbing a network 
mapped drive while running as a cgi script.  The method 
works fine when run as a normal python script (even for 
mapped drives), but does not work when run from a 
browser as a cgi script.  The glob returns an empty list 
as if the drive just isn't there.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-06-28 11:19

Message:
Logged In: YES 
user_id=14198

Assuming Windows.

This is almost certainly a permissions problem.  The IIS
server does not run CGI as a "regular" user, but as the
"system user".  The system user has no permissions to access
network resources, hence your problem.

Thus, this is not a Python problem.  You need to check the
IIS docs to see how, or even if, you can loosen the
permissions (and assuming you understand the implications of
doing so).

Unless i hear back in a few days that there is another
problem I will close this as invalid.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=571167&group_id=5470



From noreply@sourceforge.net  Fri Jun 28 02:23:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jun 2002 18:23:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-573948 ] Py_Initialize in MFC causes memroy leaks
Message-ID: <E17NkU9-0002kw-00@usw-sf-web1.sourceforge.net>

Bugs item #573948, was opened at 2002-06-26 14:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=573948&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: rhinology (rhinology)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_Initialize in MFC causes memroy leaks

Initial Comment:
My Developing Environment is MS Visual Studio.NET.

First I make a python static library (create a Win32 
static library project and copy all pythoncore files to the 
project and build it). Then I create a Win32 console 
application project and put Py_Initialize and Py_Finalize 
in the main function. Everything is OK.

Now I create a MFC application, put Py_Initialize in 
CMyApp::InitInstance and  Py_Finalize in 
CMyApp:ExitInstance. After the program exits (Debug 
Mode), VC++ detects many memory leaks. I try to put 
Py_Finalize in InitInstance, just after the Py_Initialize, 
but the problem still exists.

Python, being a static library, can't be built with MFC 
appplications?

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-06-28 11:23

Message:
Logged In: YES 
user_id=14198

Sorry, but this is not a bug.  MFC has a very dumb leak
detector.  Almost all of the leaks reported by MFC are not
leaks as such, but are one-off allocations by Python that
are never freed.  As such, the leaks never grow, but are a
one-off hit.

The core Python development team uses Purify, which is much
smarter and is capable of differentiating true leaks from
these one-off allocations.  Thus, if you feel there really
is a memory leak, purify is probably the tool you must use
to find it.

Further, I believe there is already a bug that multiple
Py_Init/Finalize calls *do* leak memory.  However, this is
not the focus of this bug.

Closing as invalid.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=573948&group_id=5470



From noreply@sourceforge.net  Fri Jun 28 05:37:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 27 Jun 2002 21:37:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-574939 ] Tex Macro Error
Message-ID: <E17NnVx-0002Ju-00@usw-sf-web2.sourceforge.net>

Bugs item #574939, was opened at 2002-06-27 23:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574939&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Tex Macro Error

Initial Comment:
David Abrahams reported missing right parens for 
list.pop() and list.sort() in the docs at 
http://www.python.org/dev/doc/devel/lib/typesseq-
mutable.html 

I scanned forward and also found them missing for 
dict.get() and dict.setdefault().

The parens *are* in the tex files.  It appears that 
there is a strange interaction between the \optional 
macro and the enclosing \lineiii macro resulting in 
the paren being consumed.

Older versions of the docs are okay, so the bug is new.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574939&group_id=5470



From noreply@sourceforge.net  Fri Jun 28 08:08:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jun 2002 00:08:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-574978 ] Example for shutil is incorrect
Message-ID: <E17Nprj-0001hS-00@usw-sf-web3.sourceforge.net>

Bugs item #574978, was opened at 2002-06-28 07:08
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574978&group_id=5470

Category: Documentation
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Cameron Blackwood (drkorg)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Example for shutil is incorrect

Initial Comment:
The doc's on python.org (library reference for 2.2.1 at
url:
    http://python.org/doc/current/lib/shutil-example.html
) has sample code for a copytree function

def copytree(src, dst, symlinks=0):
  [blah blah]

but lists the action on finding a directory as:
 elif os.path.isdir(srcname):
                copytree(srcname, dstname)
which does not pass on the symlinks flag to the
sub directory copy.

You will be pleased to know that the source for the
shutil module is correct in that it has:
            elif os.path.isdir(srcname):
                copytree(srcname, dstname, symlinks)
which is correct. It's just the documentation that is
wrong.

It also seems to have been in the doc's since 1.5.2
(from my searches of old documentation here).

I know its a small thing, but hey..... every bit helps
 :^)

cheers,
cam
korg AT cs dot mu dot oz dot au


PS: python rocks with socks on

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574978&group_id=5470



From noreply@sourceforge.net  Fri Jun 28 09:27:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jun 2002 01:27:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-520645 ] unpickable basic types => confusing err
Message-ID: <E17Nr6Z-0002q4-00@usw-sf-web3.sourceforge.net>

Bugs item #520645, was opened at 2002-02-20 13:00
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=520645&group_id=5470

Category: Type/class unification
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Samuele Pedroni (pedronis)
Assigned to: Guido van Rossum (gvanrossum)
Summary: unpickable basic types => confusing err

Initial Comment:
E.g.

Python 2.2
>>> f=open('c:/autoexec.bat','r')
>>> w=open('c:/transit/p','w')
>>> import pickle as pic
>>> pic.dump(f,w)
Traceback (most recent call last):
<<snip>>
TypeError: coercing to Unicode: need string or buffer, 
file found
>>> import cPickle as cpic
>>> cpic.dump(f,w)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\USR\PYTHON22\lib\copy_reg.py", line 56, in 
_reduce
    state = base(self)
TypeError: coercing to Unicode: need string or buffer, 
file found

VS.

Python 2.1 
>>> f=open('c:/autoexec.bat','r')
>>> w=open('c:/transit/p','w')
>>> import pickle as pic
>>> pic.dump(f,w)
Traceback (most recent call last):
<<snip>>
pickle.PicklingError: can't pickle 'file' object: 
<open file 'c:/autoexec.bat',
mode 'r' at 00795290>
>>> import cPickle as cpic
>>> cpic.dump(f,w)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
cPickle.UnpickleableError: Cannot pickle <type 'file'> 
objects
>>>



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-06-28 01:27

Message:
Logged In: NO 

I have the same error when I try to pickle libftp.FTP object.
It is possible bypass it?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-14 11:23

Message:
Logged In: YES 
user_id=6380

I cannot reproduce this on the 2.2.1 branch or on the CVS 
trunk.  I believe it was fixed by rev. 2.10 of copy_reg.py 
(without this even being the intention :-).

Closing.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=520645&group_id=5470



From noreply@sourceforge.net  Fri Jun 28 15:50:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jun 2002 07:50:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-574132 ] Major GC related performance regression
Message-ID: <E17Nx4z-0006mj-00@usw-sf-web5.sourceforge.net>

Bugs item #574132, was opened at 2002-06-26 10:33
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574132&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Jacobs (jacobs99)
Assigned to: Nobody/Anonymous (nobody)
Summary: Major GC related performance regression

Initial Comment:
A change in the Python 2.3 CVS tree has resulted
in a major performance regression.  It shows up
when allocating large lists of objects, but only when
the garbage collector is enabled.  I've attached a simple
script that I use to measure the time it takes to
incrementally append a large number of objects into
a single Python list.   For previous versions of
Python (up to and including 2.2.1), the time scaled
linearly with the number of elements added to the
list (or close enough for the list sizes considered).  
However, with the Python 2.3 CVS version,
the time required to build the list scales quadratically.

Here is the core of my benchmark:
  rows = []
  start = time.time()
  for i in indices:
    rows.append( (1,) )

See the attached file for the full source as well
as timing results for several versions of Python
with and without garbage collection enabled.


----------------------------------------------------------------------

>Comment By: Kevin Jacobs (jacobs99)
Date: 2002-06-28 09:50

Message:
Logged In: YES 
user_id=459565

Here is a detailed analysis of the problem, using the following
kernel:

lst = []
for i in range(100000):
  lst.append( (1,) )

The key ingredients are:

  1) A method is called on a container (rather than 
__setitem__ or
     __setattr__).

  2) A new object is allocated while the method object lives on 
the Python
     VM stack, as shown by the disassembled bytecodes:

         40 LOAD_FAST                1 (lst)
         43 LOAD_ATTR                3 (append)
         46 LOAD_CONST               2 (1)
         49 BUILD_TUPLE              1
         52 CALL_FUNCTION            1

These ingredients combine in the following way to trigger 
quadratic-time
behavior in the Python garbage collector:

  * First, the LOAD_ATTR on "lst" for "append" is called, and 
a PyCFunction
    is returned from this code in descrobject.c:method_get:

        return PyCFunction_New(descr->d_method, obj);

    Thus, a _new_ PyCFunction is allocated every time the 
method is
    requested.

  * This new method object is added to generation 0 of the 
garbage
    collector, which holds a reference to "lst".

  * The BUILD_TUPLE call may then trigger a garbage 
collection cycle.

  * Since the "append" method is in generation 0, the 
reference traversal
    must also follow all objects within "lst", even if "lst" is in
    generation 1 or 2.  This traversal requires time linear in the 
number of
    objects in "lst", thus increasing the overall time complexity 
of the
    code to quadratic in the number of elements in "lst".

Also note that this is a much more general problem than this 
small example.
It can affect many types of objects in addition to methods, 
including
descriptors, iterator objects, and any other object that 
contains a "back
reference".

So, what can be done about this.... One simple solution 
would be to not
traverse some "back references" if we are collecting objects 
in generation
0.  This will avoid traversing virtually all of these ephemoral 
objects that
will trigger such expensive behavior.  If they live long enough 
to pass
through to generation one or two, then clearly they should be 
traversed.

So, what do all of you GC gurus think?  Provided that my 
analysis is sound,
I can rapidly propose a patch to demonstrate this approach if 
there is
sufficient positive sentiment.

PS: I have not looked into why this doesn't happen in Python 
2.2.x or
    before.  I suspect that it must be related to the recent GC 
changes in
    methodobject.py.  I'm not motivated to spend much time 
looking into
    this, because the current GC behavior is technically 
correct, though
    clearly sub-optimal.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-26 23:10

Message:
Logged In: YES 
user_id=31392

The first 4 run calls in this test spenned 70 percent of 
their time in visit_move().

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574132&group_id=5470



From noreply@sourceforge.net  Fri Jun 28 16:01:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jun 2002 08:01:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-465045 ] base n integer to string conversion
Message-ID: <E17NxG1-0003VM-00@usw-sf-web2.sourceforge.net>

Bugs item #465045, was opened at 2001-09-25 20:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=465045&group_id=5470

Category: Python Library
Group: Feature Request
>Status: Closed
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: base n integer to string conversion

Initial Comment:
I see that the C files for int and long arithmetic 
already contain format() functions to format the
numbers in arbitrary bases.  The Python-exported
decimal and hex conversion routines simply call
the format function.

I have three suggestions/requests, in increasing order 
of controversy:

1) How about exporting the format routine to Python, 
so there's a builtin function for converting an 
integer object to an arbitrary base 2<=b<=36.
The code is already there--may as well let people
use it.  Something like format(n,base) would be
a simple interface.

2) Right now there's no simple way to convert an
integer to a raw byte string.  I end up doing
something like 
   a = binascii.unhexlify("%x"%n)
which is a kludge.  I'd like to propose that
as a special case, format(n,256) give the raw bytes.

3) Finally, if it's not too weird, format(n,128)
could possibly return the BER (base 128) encoded
representation of n, similar to pack("w",n) in perl.
Bit 8 (the high bit) is set in each byte except
the last.  That means you can read BER integers
byte by byte and know where they end.  They're used
in various security objects like X509 certificates.
If not here, then sooner or later this function
should appear in some library module.

Thanks
Paul


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-24 19:39

Message:
Logged In: YES 
user_id=80475

This is feature request appears to be suffering from lack of 
interest.  If no one speaks-up for it by 27 July 2002, I'll 
close it.

If it is needed, I would be happy to help implement it.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-10-12 09:27

Message:
Logged In: YES 
user_id=6380

OK, I believe you.  Can you submit a patch?

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2001-10-12 02:20

Message:
Logged In: YES 
user_id=72053

The struct module doesn't give any way of converting
arbitrary ints (meaning longs) to binary.  Really, it's
needed.  Some people do it with gmpy, but if Python is
going to support longs as a built-in type, one shouldn't
have to resort to 3rd-party modules to read and write
them in binary.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-10-05 21:09

Message:
Logged In: YES 
user_id=6380

Various forms of fixed-length int to binary conversion are 
provided by the struct module.

What's a "surprising deficiency" for you could simply be 
everybody else's lack of interest -- if nobody needs it, it 
won't be added to the language... :-)

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2001-10-05 18:05

Message:
Logged In: YES 
user_id=72053

Re which bases are useful: I want base 256 all the time and find the lack of
any clean way to convert ints to binary is a surprising deficiency in Python.
I'm not too concerned about what the interface should be, but I hope one is
added.

I agree, BER is a bit obscure, but if you feel it's ok to put it in the binascii
module, I might submit a patch.  How about if I put base-256 there too?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-09-26 11:00

Message:
Logged In: YES 
user_id=31435

1) Base 2 is semi-frequently requested.  Note that Greg 
Wilson has open patch 455076 to add %b format and bin() 
function.  No non-binary base has any fans.

2) I expect Paul means unbounded ints (based on previous 
requests).

3) Yup.  Jeremy's Pisces may already deal w/ this (found 
via Google search).

3') Pickle already represents ints < 256 in one byte, and 
less than 2**16 in 2 (plus a 1-byte type code, of course).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-26 08:38

Message:
Logged In: YES 
user_id=6380

1) Which bases besides 8, 10 and 16 do you plan to use? The
C code strikes me as more general than needed.

2) You can do this with the struct module. No need for
kludges.

3) BER seems pretty esoteric. The binascii module seems the
right place. Feel free to submit a patch!

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2001-09-25 20:45

Message:
Logged In: YES 
user_id=72053

One minor comment: besides representing longs, BER encoded
integers are also good for small integers.  Numbers < 128
are represented in one byte.  If short strings were
marshalled with a BER-encoded length instead of a 4-byte
length, that could save some space in .pyc files and
pickled objects.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=465045&group_id=5470



From noreply@sourceforge.net  Fri Jun 28 16:11:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jun 2002 08:11:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-568134 ] asynchat module undocumented
Message-ID: <E17NxPN-0002Yc-00@usw-sf-web4.sourceforge.net>

Bugs item #568134, was opened at 2002-06-12 13:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=568134&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason R. Mastaler (jasonrm)
>Assigned to: Steve Holden (holdenweb)
Summary: asynchat module undocumented

Initial Comment:
While asyncore is documented, asynchat 
is not.

Lack of documentation makes asynchat
more difficult to understand/use than it
should be.



----------------------------------------------------------------------

>Comment By: Steve Holden (holdenweb)
Date: 2002-06-28 11:11

Message:
Logged In: YES 
user_id=88157

Assigned to self after no response to an email from Anthony.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-13 19:54

Message:
Logged In: YES 
user_id=3066

Ok, I'm fine with Anthony contributing the asynchat
documentation.

----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-06-13 13:52

Message:
Logged In: YES 
user_id=85984

I think it would be better for Anthony
to write the documentation.  I don't 
understand it very well myself (which is
why I was looking for docs in the first
place <wink>).



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-06-13 08:57

Message:
Logged In: YES 
user_id=29957

... if not, I can probably try to get something in a week or
two. I've got a current project that uses it. 

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-13 08:31

Message:
Logged In: YES 
user_id=3066

Agreed.  Can you contribute a section for this module?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=568134&group_id=5470



From noreply@sourceforge.net  Fri Jun 28 16:26:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jun 2002 08:26:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-574207 ] Chained __slots__ dealloc segfault
Message-ID: <E17NxdP-0008Gk-00@usw-sf-web1.sourceforge.net>

Bugs item #574207, was opened at 2002-06-26 18:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574207&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan Hogg (jhogg)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Chained __slots__ dealloc segfault

Initial Comment:
With the following script ('foo.py'):

-----
class foo1(object):
    def __init__(self, n):
        self.n = n

class foo2(object):
    def __init__(self, n):
        self.n = n
    __slots__ = ['n']

o = None
for i in xrange(50000):
    o = foo1(o)
print 'alloc OK'
del o 
print 'dealloc OK'

o = None 
for i in xrange(50000):
    o = foo2(o)
print 'alloc OK'
del o 
print 'OK'
-----

Running this results in a segmentation fault in the
second 'del':

-----
onegood1-2% python foo.py
alloc OK
dealloc OK
alloc OK
zsh: 18593 segmentation fault  python foo.py
-----

A gdb stack trace shows:

-----
Program received signal EXC_BAD_ACCESS, Could not
access memory.
0x00037bbc in lookdict_string (mp=0xa7fb8, key=0x191d0,
hash=3882000) at Objects/dictobject.c:306
306     {
(gdb) where
#0  0x00037bbc in lookdict_string (mp=0xa7fb8,
key=0x191d0, hash=3882000) at Objects/dictobject.c:306
#1  0x00018994 in _PyType_Lookup (type=0x3d14f0,
name=0x3b3c10) at Objects/typeobject.c:1227
#2  0x00017348 in lookup_maybe (self=0xbb88f0,
attrstr=0x3d14f0 "", attrobj=0xa0228) at
Objects/typeobject.c:460
#3  0x00016f38 in call_finalizer (self=0xbb88f0) at
Objects/typeobject.c:280
#4  0x00017054 in subtype_dealloc (self=0xbb88f0) at
Objects/typeobject.c:328
#5  0x00017118 in subtype_dealloc (self=0xbb88d0) at
Objects/typeobject.c:353
#6  0x00017118 in subtype_dealloc (self=0xbb88b0) at
Objects/typeobject.c:353
[...]
#5431 0x00017118 in subtype_dealloc (self=0xbe3410) at
Objects/typeobject.c:353
#5432 0x00017118 in subtype_dealloc (self=0xbe33f0) at
Objects/typeobject.c:353
#5433 0x00017118 in subtype_dealloc (self=0xbe33d0) at
Objects/typeobject.c:353
#5434 0x000382f4 in PyDict_DelItem (op=0x3b3300,
key=0x405520) at Objects/dictobject.c:588
#5435 0x0005b348 in eval_frame (f=0x0) at
Python/ceval.c:1550
#5436 0x0005d6fc in PyEval_EvalCodeEx (co=0x3fd760,
globals=0x402d60, locals=0x3804c, args=0x0, argcount=0,
kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at Python/ceval.c:2585
#5437 0x000588e0 in PyEval_EvalCode (co=0x3d14f0,
globals=0x402d60, locals=0x46257b48) at Python/ceval.c:483
#5438 0x00027850 in run_node (n=0x3bfba0,
filename=0x402d60 "", globals=0x3b3300,
locals=0x3b3300, flags=0x3d16e8) at Python/pythonrun.c:1079
#5439 0x000277f4 in run_err_node (n=0x3804c,
filename=0x402d60 "", globals=0x46257b48, locals=0x0,
flags=0x3d16e8) at Python/pythonrun.c:1066
#5440 0x000277c0 in PyRun_FileExFlags (fp=0x80008a98,
filename=0xbffffb46 "foo.py", start=1176861512,
globals=0x3b3300, locals=0x3b3300, closeit=1,
flags=0xbffff9c8) at Python/pythonrun.c:1057
#5441 0x0002683c in PyRun_SimpleFileExFlags
(fp=0x80008a98, filename=0xbffffb46 "foo.py",
closeit=1, flags=0xbffff9c8) at Python/pythonrun.c:685
#5442 0x00026254 in PyRun_AnyFileExFlags
(fp=0x80008a98, filename=0xbffffb46 "foo.py",
closeit=1, flags=0xbffff9c8) at Python/pythonrun.c:495
#5443 0x00005e10 in Py_Main (argc=2, argv=0xbffffab0)
at Modules/main.c:364
#5444 0x00001e2c in _start ()
#5445 0x00001c5c in start ()
-----

The number of objects that can be deallocated depends
on the stacksize, so it appears to be a stack overrun
problem.

This is on a Mac OS X 10.1.5 system, but was originally
reported by Glyph Lefkowitz using Python 2.2.1 on PPC
Linux 2.4.18 (Debian I think) and has been verified
also by Aahz using Python 2.2.1 on Mandrake 8.1.


----------------------------------------------------------------------

>Comment By: Jonathan Hogg (jhogg)
Date: 2002-06-28 15:26

Message:
Logged In: YES 
user_id=10036

I've uploaded a patch (against HEAD today) that fixes this
problem by putting the objects in the slots into a temporary
list and appending that to the PyTRASHCAN 'delete_later'
chain when the maximum deallocation recursion depth is reached.

[ 575073 ] PyTRASHCAN slots deallocation


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-27 02:32

Message:
Logged In: YES 
user_id=33168

I bumped MAX up to 500000 and 2.3 didn't crash.
But then I dropped my max stack size down from 8M to 1M
and that caused the crash.  So the stack handling must be
better in 2.3, but as you point out, still not fixed.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-27 02:12

Message:
Logged In: YES 
user_id=31435

Neal, it's odd that you can't provoke a problem.  Try 
boosting MAX.  The del here triggers a chain of 
deallocations that requires call-stack space proportional to 
the length of the object chain (MAX).  This is the kind of 
situation Python's infamous TRASHCAN macros aim at 
worming around, but the slot cleanup code doesn't play 
that game (yet).

Assigned to Guido just because he'll enjoy it <wink>.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-27 01:27

Message:
Logged In: YES 
user_id=33168

I do not get this problem with current CVS.
I do get this problem with 2.2.1+ (current).
Attaching the test file I used.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574207&group_id=5470



From noreply@sourceforge.net  Fri Jun 28 19:28:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jun 2002 11:28:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-571167 ] glob() fails for network drive in cgi
Message-ID: <E17O0TR-0002LO-00@usw-sf-web5.sourceforge.net>

Bugs item #571167, was opened at 2002-06-19 10:29
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=571167&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Schuweiler (bshoe282)
Assigned to: Mark Hammond (mhammond)
Summary: glob() fails for network drive in cgi

Initial Comment:
glob.glob() does not work when globbing a network 
mapped drive while running as a cgi script.  The method 
works fine when run as a normal python script (even for 
mapped drives), but does not work when run from a 
browser as a cgi script.  The glob returns an empty list 
as if the drive just isn't there.

----------------------------------------------------------------------

>Comment By: Brian Schuweiler (bshoe282)
Date: 2002-06-28 13:28

Message:
Logged In: YES 
user_id=565626

Thanks for the response.  My initial thoughts were that it is a 
permissions problem.  What made me believe otherwise and 
log a bug was that no errors are thrown in the webserver and 
the glob does return something, but it is an empty set.  It 
seems as though the glob works, but there are no matches 
(even though there definitely are).  

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-06-27 20:19

Message:
Logged In: YES 
user_id=14198

Assuming Windows.

This is almost certainly a permissions problem.  The IIS
server does not run CGI as a "regular" user, but as the
"system user".  The system user has no permissions to access
network resources, hence your problem.

Thus, this is not a Python problem.  You need to check the
IIS docs to see how, or even if, you can loosen the
permissions (and assuming you understand the implications of
doing so).

Unless i hear back in a few days that there is another
problem I will close this as invalid.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=571167&group_id=5470



From noreply@sourceforge.net  Fri Jun 28 20:57:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jun 2002 12:57:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-570655 ] bdist_rpm and the changelog option
Message-ID: <E17O1sS-00041g-00@usw-sf-web5.sourceforge.net>

Bugs item #570655, was opened at 2002-06-18 12:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570655&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mihai Ibanescu (misa)
Assigned to: Nobody/Anonymous (nobody)
Summary: bdist_rpm and the changelog option

Initial Comment:
I think the changelog option for bdist_rpm is not
correctly handled. The documentation says it should
expect a path to a file containing the changelog
entries, but in bdist_rpm.py, line 200, it tries to
read it as a string (ensure_string etc).

The changelogs are multiple lines, and I was unable to
add multi-lined entries in setup.cfg. Even so, the
documentation is still misleading.

----------------------------------------------------------------------

>Comment By: Mihai Ibanescu (misa)
Date: 2002-06-28 15:57

Message:
Logged In: YES 
user_id=205865

Uploaded a patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570655&group_id=5470



From noreply@sourceforge.net  Fri Jun 28 23:56:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jun 2002 15:56:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-575221 ] Library Reference, sec 3.7: UserDict
Message-ID: <E17O4fS-0006fg-00@usw-sf-web5.sourceforge.net>

Bugs item #575221, was opened at 2002-06-28 18:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575221&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark J (average)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Library Reference, sec 3.7: UserDict

Initial Comment:
UserDict docs make reference to using "dictionary" type, instead of "dict" type.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575221&group_id=5470



From noreply@sourceforge.net  Fri Jun 28 23:58:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jun 2002 15:58:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-575221 ] Library Reference, sec 3.7: UserDict
Message-ID: <E17O4gr-0002Ik-00@usw-sf-web4.sourceforge.net>

Bugs item #575221, was opened at 2002-06-28 18:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575221&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark J (average)
>Assigned to: Steve Holden (holdenweb)
Summary: Library Reference, sec 3.7: UserDict

Initial Comment:
UserDict docs make reference to using "dictionary" type, instead of "dict" type.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575221&group_id=5470



From noreply@sourceforge.net  Sat Jun 29 00:33:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jun 2002 16:33:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-575229 ] multiple inheritance w/ slots dumps core
Message-ID: <E17O5F6-0002t3-00@usw-sf-web4.sourceforge.net>

Bugs item #575229, was opened at 2002-06-29 01:33
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575229&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Cesar Douady (douady)
Assigned to: Nobody/Anonymous (nobody)
Summary: multiple inheritance w/ slots dumps core

Initial Comment:
The following script dumps a core (revision 2.2.1) :

class A(object): __slots__=()
class B(object): pass
class C(A,B) : __slots__=()
C().x=2

basic sizes for those classes are:
A => 8 (correct : no dict, no weakref)
B => 16 (correct : dict and weakref slots added)
C => 8 (incorrect : dict and weakref not inherited from
B)

in the last lines of type_new, variables add_dict and
add_weak
are exploited to add those slots, but only when
slots==NULL.
The best base selected for C is A, which is correct in
my opinion
since slots come from it, but dict and weak refs must
be treated
specially and can come from another base.

I have seen nothing in the cvs repository which may fix
this bug.

I did not submit a patch since this is a touchy part of
the interpreter,
but I may do it upon request.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575229&group_id=5470



From noreply@sourceforge.net  Sat Jun 29 00:33:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jun 2002 16:33:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-227361 ] httplib problem with '100 Continue'
Message-ID: <E17O5FQ-0002vW-00@usw-sf-web2.sourceforge.net>

Bugs item #227361, was opened at 2001-01-03 02:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=227361&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Doug Fort (dougfort)
>Assigned to: Jeremy Hylton (jhylton)
Summary: httplib problem with '100 Continue'

Initial Comment:
I believe there is a bug in httplib 

IIS 4 and 5 are subject to send an unsolicited result code of '100 Continue' with a couple of headers and a blank line before sending '302 Object Moved'.

The 100 response is totally worthless and should be ignored.  Unfortunately, httplib.HTTPConnection is unwilling to go back and read more headers when it
already has a response object.

I was able to get past this with the following kludge:

    while 1:
        response = self._client.getresponse()
        if response.status != 100:
            break
        # 2000-12-30 djf -- drop bogus 100 response
        # by kludging httplib
        self._client._HTTPConnection__state = httplib._CS_REQ_SENT
        self._client._HTTPConnection__response = None



----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-28 23:33

Message:
Logged In: YES 
user_id=31392

Fix in httplib.py rev. 1.52.


----------------------------------------------------------------------

Comment By: Jens B. Jorgensen (jensbjorgensen)
Date: 2002-05-02 16:22

Message:
Logged In: YES 
user_id=67930

I've already submitted a patch for this:

http://sourceforge.net/tracker/?func=detail&atid=105470&aid=227361&group_id=5470

Just waiting for it to be accepted.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-02 03:32

Message:
Logged In: NO 

I've got a patch for this bug.  How do I submit it?

----------------------------------------------------------------------

Comment By: Jens B. Jorgensen (jensbjorgensen)
Date: 2002-03-02 00:15

Message:
Logged In: YES 
user_id=67930

I did submit a patch for this, not sure if you noticed. I've
been using it for quite a while and it seems to be working
flawlessly, granted I'm always pretty much using it in the
same context.

----------------------------------------------------------------------

Comment By: Greg Stein (gstein)
Date: 2002-03-01 23:12

Message:
Logged In: YES 
user_id=6501

Yup, I'll clear out all the httplib bugs... not a problem. I
didn't get free time until the end of the 2.2 cycle, so I
punted until now.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 22:48

Message:
Logged In: YES 
user_id=31392

Greg,

Will you be able to work on this for 2.3?


----------------------------------------------------------------------

Comment By: Jens B. Jorgensen (jensbjorgensen)
Date: 2002-02-11 15:58

Message:
Logged In: YES 
user_id=67930

Whether or not the library transparently consumes 100
responses (which I believe it should) or not there is no
question the current behavior represents a bug. When a 100
response is received the connection get's "stuck" because it
believes it has already read a response and refuses to read
another until another request is sent. Once you hit this
with the HTTPConnection you cannot do anything with it
unless you modify its internal state data.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-02-11 09:54

Message:
Logged In: NO 

This may not be a problem at all, depending on how the 
authors of httplib intended to process this header. I 
haven't read their spec so I don't know what they intended.

Here is the section on response code 100 from RFC 2616 
(HTTP 1.1) so you can make up your own mind:

10.1.1 100 Continue

#######################################################
The client SHOULD continue with its request. This interim 
response is used to inform the client that the initial part 
of the request has been received and has not yet been 
rejected by the server. The client SHOULD continue by 
sending the remainder of the request or, if the request has 
already been completed, ignore this response. The server 
MUST send a final response after the request has been 
completed. See section 8.2.3 for detailed discussion of the 
use and handling of this status code.
#######################################################

If you take a look at section 8.2.3, you will find some 
very good reasons why this header responds as it does. You 
might also be able to solve your problem just by reading 
these to section of the spec.

----------------------------------------------------------------------

Comment By: Doug Fort (dougfort)
Date: 2001-01-06 20:14

Message:
I'm not sure httplib should know anything about the actual status.  Right now it is elegantly decoupled from the content it handles. Perhaps just a 'discardresponse()' function.

BTW, I've had very good results with the HTTP 1.1 functionality in general.  This is a small nit.

----------------------------------------------------------------------

Comment By: Greg Stein (gstein)
Date: 2001-01-06 20:04

Message:
Agreed -- this is a problem in httplib. I was hoping to get the "chewing up" of 100 (Continue) responses into httplib before the 2.0 release.

It should be possible to do this in HTTPResponse.begin()

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=227361&group_id=5470



From noreply@sourceforge.net  Sat Jun 29 00:38:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jun 2002 16:38:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-458463 ] HTTPSConnect.__init__ too tricky
Message-ID: <E17O5Jx-0002wu-00@usw-sf-web4.sourceforge.net>

Bugs item #458463, was opened at 2001-09-04 17:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=458463&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: Rich Salz (rsalz)
>Assigned to: Jeremy Hylton (jhylton)
Summary: HTTPSConnect.__init__ too tricky

Initial Comment:
The code in HTTPSConnect's ctor is way too tricky.  How
about this:
   for k in x509.keys():
     if k not in ['key_file', 'cert_file']:
       raise InvalidKeywordArgument()
if you NEED to be clever then use a list comprehensive
  if [ k for k in x509.keys() if k not in
['key_file','cert_file']]:
    raise InvalidKeywordArgument()

(It's also inefficient copying the keys only to delete
them, in case you need a real justification. ;)


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-28 23:38

Message:
Logged In: YES 
user_id=31392

Fixed as Guido suggested in rev. 1.53 of httplib.py


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-04 18:36

Message:
Logged In: YES 
user_id=6380

Looks like your alternative still makes a copy.

What I personally don't get about that piece of code is why
the function doesn't just declare arguments with default
values of None and be done with it.

Assigned to Greg Stein for judgement. Personally, I'd say
there are bigger fish to fry. :-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=458463&group_id=5470



From noreply@sourceforge.net  Sat Jun 29 00:39:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jun 2002 16:39:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-432621 ] httplib: multiple Set-Cookie headers
Message-ID: <E17O5L6-00076F-00@usw-sf-web5.sourceforge.net>

Bugs item #432621, was opened at 2001-06-13 02:20
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=432621&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Jeremy Hylton (jhylton)
Summary: httplib: multiple Set-Cookie headers

Initial Comment:
httplib does not support multiple headers of the same 
name, because the headers are stored in a dictionary.

This causes a problem because an HTTP response can 
contain multiple "Set-Cookie".  

It is stated in RFC2109 - HTTP State Management 
Mechanism that "An origin server may include multiple 
Set-Cookie headers in a response. "

With the current python implementation, only the 
last "Set-Cookie" header is included in the headers 
dictionary, effectively meaning that the other cookies 
were lost.


----------------------------------------------------------------------

Comment By: Greg Stein (gstein)
Date: 2001-08-31 04:23

Message:
Logged In: YES 
user_id=6501

I've been using it for Expat, but that still isn't 
authoritative :-) Basically, I'm trying to suggest that the 
bug has been "accepted as a real bug" and will be 
addressed. Sort of a "started", if you will, rather than 
leaving it in the indeterminate Open/None 
status/resolution. When it gets fixed, the resolution will 
be "Fixed"

I kind of see it as a way to let the submitter know that 
their bug has been considered and acknowledged and will be 
fixed.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-31 03:37

Message:
Logged In: YES 
user_id=6380

Greg: this is a new use of "Accepted" for me. We've only
used "Accepted" for accepted *patches*. Bugs to be fixed
simply remain open until they are fixed; I'm not sure I see
the value of changing the status. Were you innovating here,
or is this common usage in other projects?

----------------------------------------------------------------------

Comment By: Greg Stein (gstein)
Date: 2001-08-31 02:52

Message:
Logged In: YES 
user_id=6501

Use response.msg.getallmatchingheaders() as a workaround.

That said: the default operation of HTTPResponse.getheader
() should use the same, since HTTP headers can (by 
definition) use multiple headers. And HTTP defines a way to 
join those headers into one.

The solution here is to not return a list of header values 
(thus, breaking backwards compat), but to join them per the 
specification (with a ",").

I'm reclassifying this as an Accepted bug due to fix in 
Python 2.2.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2001-08-30 21:10

Message:
Logged In: YES 
user_id=12800

Please use RFC 2822 instead of 822 as the former has
replaced the latter. RFC 2822 describes the number of times
standard headers must or can appear in a mail message. 
AFAIK, rfc822.py does no such enforcement (and there are
good reasons to have both strict and lenient modes).  

My own mimelib (soon to be renamed and installed in the
standard library) accepts duplicates by keeping headers in a
list instead of a dictionary and searching the list linearly
for hits.  The speed advantages of a dictionary are probably
minimal for typical mail messages, so a linear search, which
preserves insertion order and duplicate order, is fine in
practice.

mimelib does not, but should have both a strict and lenient
mode where duplicates breaking the standard are either
allowed or flagged as errors.

----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2001-07-17 11:49

Message:
Logged In: YES 
user_id=88157

RFC 822-compliant mail messages frequently contain several
"Received-By:" headers. I cannot remember anything in the
standard which speaks to the general case. There may well 
be headers whose semantics require enforcement of 
the "There can be only one" variety, but equally some 
others must be treated the same as "Received-By:".

In so far as RFC 2616 [HTTP/1.1] says "Unrecognized header 
fields SHOULD be ignored by the recipient and MUST be 
forwarded by transparent proxies." (section 7.1: Entity 
header fields) this is an argument for being able to handle 
many unknown headers of the same type in the general case.

For correct processing it is therefore necessary to hold 
headers as lists, or in some other way which allows 
multiple headers of the same type. Fortunately there 
appears to be no need to emit headers in the same order 
they were seen in the original to preserve meaning.


----------------------------------------------------------------------

Comment By: Andrew Gaul (gaul)
Date: 2001-07-15 01:20

Message:
Logged In: YES 
user_id=139865

I'm willing to fix this, but I could use some clarification
of the relevant RFCs (822 and 2045). Do either of these
allow multiple headers with the same field names? I get the
impression from looking around in Google that reusing a
field is discouraged, but necessary for things like HTTP's
Set-Cookie header.

If one or both of the standards allow the above, I'll add an
optional argument (defaulting to the current behaviour) that
controls the handling of duplicate field names. If the flag
is passed, any field name having more than one value will
return the duplicate values in a list. For example:

foo: yes
bar: false
bar: true

will be returned as {foo: yes, bar: [false, true]}
as opposed to the old return value {foo: yes, bar: true}

HTTPResponse will always use this new behaviour, which may
break some programs that rely on the old behaviour.

Does anyone have comments before I code up this solution?
While I am concerned about breaking compatibility, it seems
like a correctness issue that headers aren't handled properly.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-04 06:01

Message:
Logged In: YES 
user_id=3066

Categorized as a feature request.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=432621&group_id=5470



From noreply@sourceforge.net  Sat Jun 29 02:50:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jun 2002 18:50:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-574132 ] Major GC related performance regression
Message-ID: <E17O7NO-0004UF-00@usw-sf-web4.sourceforge.net>

Bugs item #574132, was opened at 2002-06-26 11:33
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574132&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Jacobs (jacobs99)
>Assigned to: Neil Schemenauer (nascheme)
Summary: Major GC related performance regression

Initial Comment:
A change in the Python 2.3 CVS tree has resulted
in a major performance regression.  It shows up
when allocating large lists of objects, but only when
the garbage collector is enabled.  I've attached a simple
script that I use to measure the time it takes to
incrementally append a large number of objects into
a single Python list.   For previous versions of
Python (up to and including 2.2.1), the time scaled
linearly with the number of elements added to the
list (or close enough for the list sizes considered).  
However, with the Python 2.3 CVS version,
the time required to build the list scales quadratically.

Here is the core of my benchmark:
  rows = []
  start = time.time()
  for i in indices:
    rows.append( (1,) )

See the attached file for the full source as well
as timing results for several versions of Python
with and without garbage collection enabled.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-06-28 21:50

Message:
Logged In: YES 
user_id=31435

Assigned to Neil.  I've attached a brief patch that stops 
move_root_reacahable() from pulling objects out of older 
generations into the generation being collected,  IOW, it 
makes move_root_reachable restrict itself to moving 
objects belonging to the generation being collected.  This is 
done without loss of speed (in fact, it's a little faster now).

This allows "the list" in Kevin's example to move to gen2 
and stay there.  Without the patch, it keeps getting yanked 
back into gen1 because move_root_reachable() sucks it 
out of gen1 (or gen2) and into gen0 every time gen0 gets 
collected, "just because" a bound method object in gen0 
points to the list.

Note that this didn't happen in 2.2.1 only because a bug in 
2.2.1's PyCFunction_New caused bound method objects 
not to get tracked at all.

----------------------------------------------------------------------

Comment By: Kevin Jacobs (jacobs99)
Date: 2002-06-28 10:50

Message:
Logged In: YES 
user_id=459565

Here is a detailed analysis of the problem, using the following
kernel:

lst = []
for i in range(100000):
  lst.append( (1,) )

The key ingredients are:

  1) A method is called on a container (rather than 
__setitem__ or
     __setattr__).

  2) A new object is allocated while the method object lives on 
the Python
     VM stack, as shown by the disassembled bytecodes:

         40 LOAD_FAST                1 (lst)
         43 LOAD_ATTR                3 (append)
         46 LOAD_CONST               2 (1)
         49 BUILD_TUPLE              1
         52 CALL_FUNCTION            1

These ingredients combine in the following way to trigger 
quadratic-time
behavior in the Python garbage collector:

  * First, the LOAD_ATTR on "lst" for "append" is called, and 
a PyCFunction
    is returned from this code in descrobject.c:method_get:

        return PyCFunction_New(descr->d_method, obj);

    Thus, a _new_ PyCFunction is allocated every time the 
method is
    requested.

  * This new method object is added to generation 0 of the 
garbage
    collector, which holds a reference to "lst".

  * The BUILD_TUPLE call may then trigger a garbage 
collection cycle.

  * Since the "append" method is in generation 0, the 
reference traversal
    must also follow all objects within "lst", even if "lst" is in
    generation 1 or 2.  This traversal requires time linear in the 
number of
    objects in "lst", thus increasing the overall time complexity 
of the
    code to quadratic in the number of elements in "lst".

Also note that this is a much more general problem than this 
small example.
It can affect many types of objects in addition to methods, 
including
descriptors, iterator objects, and any other object that 
contains a "back
reference".

So, what can be done about this.... One simple solution 
would be to not
traverse some "back references" if we are collecting objects 
in generation
0.  This will avoid traversing virtually all of these ephemoral 
objects that
will trigger such expensive behavior.  If they live long enough 
to pass
through to generation one or two, then clearly they should be 
traversed.

So, what do all of you GC gurus think?  Provided that my 
analysis is sound,
I can rapidly propose a patch to demonstrate this approach if 
there is
sufficient positive sentiment.

PS: I have not looked into why this doesn't happen in Python 
2.2.x or
    before.  I suspect that it must be related to the recent GC 
changes in
    methodobject.py.  I'm not motivated to spend much time 
looking into
    this, because the current GC behavior is technically 
correct, though
    clearly sub-optimal.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-27 00:10

Message:
Logged In: YES 
user_id=31392

The first 4 run calls in this test spenned 70 percent of 
their time in visit_move().

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574132&group_id=5470



From noreply@sourceforge.net  Sat Jun 29 03:01:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jun 2002 19:01:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-552957 ] email.Utils.encode doesn't obey rfc2047
Message-ID: <E17O7YL-0000Nb-00@usw-sf-web5.sourceforge.net>

Bugs item #552957, was opened at 2002-05-06 14:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=552957&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Ty Sarna (tsarna)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Utils.encode doesn't obey rfc2047

Initial Comment:
The email.Utils.encoding function has two bugs, which
are somewhat related -- it fails to deal with long
input strings in two different ways.

First, newlines are not allowed in the middle of
rfc2047 encoded-words (per section 2: "[...] white
space characters MUST NOT appear between components of
an 'encoded-word'"). The _bencode and _qencode routines
that the encode function uses include newlines (or
"=\n"'s for quopri) in their output, and the encode
function doesn't remove them. Try encoding a long
string with 'q' for example. The resulting output will
contain one or more "= \n"'s, and the
email.Utils.decode function will not be able to parse it.

Patch:

*** Utils.py.orig       Mon May  6 13:17:05 2002
--- Utils.py    Mon May  6 13:18:16 2002
***************
*** 98,106 ****
      """Encode a string according to RFC 2047."""
      encoding = encoding.lower()
      if encoding == 'q':
!         estr = _qencode(s)
      elif encoding == 'b':
!         estr = _bencode(s)
      else:
          raise ValueError, 'Illegal encoding code: ' +
encoding
      return '=?%s?%s?%s?=' % (charset.lower(),
encoding, estr)
--- 98,106 ----
      """Encode a string according to RFC 2047."""
      encoding = encoding.lower()
      if encoding == 'q':
!         estr = _qencode(s).replace('=\n','')
      elif encoding == 'b':
!         estr = _bencode(s).replace('\n','')
      else:
          raise ValueError, 'Illegal encoding code: ' +
encoding
      return '=?%s?%s?%s?=' % (charset.lower(),
encoding, estr)

NOTE: The .replace()-ing should NOT be done in _bencode
and _quencode, because they're used other places where
their current behaviour is fine/expected.


Second problem: rfc2047 specifies that an encoded-word
 may be no longer than 75 characters (see section 2).
Also, in the case of, say, a From: header with high-bit
characters in the sender's name, you really want to
encode only the name, not the whole line, so that dumb
mail programs are able to recognize the email address
in the line without having to understand rfc2047.

Proposed solution: rename existing encode function
(with above patche applied) to encode_word. Add a new
encode function that splits the input string into a
list of words and whitespace runs.  Words are encoded
individually using encode_word() iff they are not pure
ascii. The results are then concatenated back with
original whitespace.

This still leaves the possibility that a single word,
when encoded, is longer than 75 characters. The
recommended practice in rfc2047 is to use multiple
encoded words separated by CRLF SPACE (or in our case ,
"\n "). 


Here is code that implements the above:

wsplit = re.compile('([ \n\t]+)').split


def encode(s, charset='iso-8859-1', encoding='q'):
    i = wsplit(s)
    o = []

    # max encoded-word length per rfc2047 section 2 is 75
    # 75 - len("=?" + "?" + "?" + "?=") == 69
    max_enc_text = 69 - len(charset) - len(encoding)
    if encoding == 'q':
        # 3 bytes per character worst case
        safe_wlen = max_enc_text / 3
    elif encoding == 'b':
        safe_wlen = (max_enc_text * 6) / 8
    else:
        safe_wlen = max_enc_text # ?

    for w in i:
        if w[0] in " \n\t":
            o.append(w)
        else:
            try:
                o.append(w.encode('ascii'))
            except:
                ew = encode_word(w, charset, encoding)
                while len(ew) > 75:
                   
o.append(encode_word(w[:safe_wlen],charset,encoding)+"\n ")
                    w = w[safe_wlen:]
                    ew = encode_word(w, charset, encoding)
                o.append(ew)

    return ''.join(o)


----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-06-28 22:01

Message:
Logged In: YES 
user_id=12800

Ty, is it worth patching up email.Utils.encode() given its
deprecation and the existance of the Header class?  I tend
to think not (there should be only one way to do it).

Is Header vulnerable to the same problems?  If so, please
submit a new bug report with a test case.  Please also
attach diffs and patches as attachments instead of in the
bug report because otherwise SF will mess up the indentation.

BTW, you might want to check Python 2.3's cvs since there
have been a lot of updates lately.

Thanks, I'm closing this one.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=552957&group_id=5470



From noreply@sourceforge.net  Sat Jun 29 03:42:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jun 2002 19:42:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-574742 ] Missing docs for module textwrap
Message-ID: <E17O8CG-00031X-00@usw-sf-web3.sourceforge.net>

Bugs item #574742, was opened at 2002-06-27 15:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574742&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Greg Ward (gward)
Summary: Missing docs for module textwrap

Initial Comment:
The textwrap module is not documented in the Python
Library Reference.  Please write & check-in the
documentation as Doc/lib/libtextwrap.tex.


----------------------------------------------------------------------

>Comment By: Greg Ward (gward)
Date: 2002-06-28 22:42

Message:
Logged In: YES 
user_id=14422

Done.  I'm not completely happy with the LaTeX source, as 
explained by my two XXX comments in lib/libtextwrap.tex:

% XXX how to typeset long argument lists? this just spills off
% the edge of the page, with or without \ delimiters
[...]
% XXX how to typeset the empty string? this looks awful, and 
"" is worse.

Fred, can you either tell me how to fix these or fix them 
yourself?  I'll leave this bug open until these small problems 
are resolved.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574742&group_id=5470



From noreply@sourceforge.net  Sat Jun 29 03:43:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jun 2002 19:43:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-574742 ] Missing docs for module textwrap
Message-ID: <E17O8DK-00032J-00@usw-sf-web3.sourceforge.net>

Bugs item #574742, was opened at 2002-06-27 15:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574742&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Fred L. Drake, Jr. (fdrake)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Missing docs for module textwrap

Initial Comment:
The textwrap module is not documented in the Python
Library Reference.  Please write & check-in the
documentation as Doc/lib/libtextwrap.tex.


----------------------------------------------------------------------

>Comment By: Greg Ward (gward)
Date: 2002-06-28 22:43

Message:
Logged In: YES 
user_id=14422

Assigning to Fred because of my LaTeX questions.

----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2002-06-28 22:42

Message:
Logged In: YES 
user_id=14422

Done.  I'm not completely happy with the LaTeX source, as 
explained by my two XXX comments in lib/libtextwrap.tex:

% XXX how to typeset long argument lists? this just spills off
% the edge of the page, with or without \ delimiters
[...]
% XXX how to typeset the empty string? this looks awful, and 
"" is worse.

Fred, can you either tell me how to fix these or fix them 
yourself?  I'll leave this bug open until these small problems 
are resolved.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574742&group_id=5470



From noreply@sourceforge.net  Sat Jun 29 04:23:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jun 2002 20:23:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-575272 ] unicode() "new in" misleading
Message-ID: <E17O8pQ-0005aD-00@usw-sf-web4.sourceforge.net>

Bugs item #575272, was opened at 2002-06-28 23:23
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575272&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: unicode() "new in" misleading

Initial Comment:
Documentation for the unicode() builtin says at the end
"New in 2.0".

While it's true that unicode() was added in 2.0, this
phrase comes after the section describing the use of
__unicode__() for objects that support this protocol. 
This makes it seem that the use of __unicode__() has
been around since 2.0, when in fact /that/ part of the
protocol is new in 2.2.

Can the docs be clarified here?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575272&group_id=5470



From noreply@sourceforge.net  Sat Jun 29 07:07:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 28 Jun 2002 23:07:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-574605 ] Message.as_string() fails for multipart
Message-ID: <E17OBOG-0007Bz-00@usw-sf-web2.sourceforge.net>

Bugs item #574605, was opened at 2002-06-27 10:35
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574605&group_id=5470

Category: Python Library
Group: Python 2.2.1
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Moshe Yudkowsky (myudkowsky)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Message.as_string() fails for multipart

Initial Comment:
email.Message.Message has a method as_string(), which
according to documentation should print out the entire
message. However, if I build up a message using
add_payload() several times, as_string() fails.

as_string() fails because the message body becomes a
list instead of a string if it's a multipart message.

I enclose a file that "fixes" this problem; it's for
email/Generator.py, class Generator, and replaces def 
_handle_text(). Intead of testing for just type String,
it tests for type String and type List; if it's a list,
it tests to see that each list item is a string, and
then concatenates the strings into a string for printout.

Someone better versed in Message had better review this!



----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-06-29 02:07

Message:
Logged In: YES 
user_id=12800

I believe this is the known problem that led to the
deprecation of add_payload().  You should use the attach()
method instead.  Note that some fixes didn't make it into
Python 2.2.1 (I'm too tired to remember) but Python 2.3's
cvs is up-to-date and should/will be backported to Python 2.2.2.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574605&group_id=5470



From noreply@sourceforge.net  Sat Jun 29 14:09:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 29 Jun 2002 06:09:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-575360 ] httplib BadStatusLine behaves strange
Message-ID: <E17OHyG-00022P-00@usw-sf-web3.sourceforge.net>

Bugs item #575360, was opened at 2002-06-29 15:09
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575360&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nicole Dornseif (nerxs)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib BadStatusLine behaves strange

Initial Comment:
1. linkch.py:
import httplib

try:
   conn = httplib.HTTPConnection('aleph0.clarku.edu')
   conn.request("GET", '/~djoyce/java/elements/toc.html')
   resp = conn.getresponse()
   conn.close()

except httplib.BadStatusLine,msg:
   print msg


nik@deepblack:~$ linkch.py
Traceback (most recent call last):
  File "badstatuslner.py", line 20, in ?
    print msg
AttributeError: BadStatusLine instance has no 
attribute 'args'


2. linkch.py:
import httplib

try:
   conn = httplib.HTTPConnection('aleph0.clarku.edu')
   conn.request("GET", '/~djoyce/java/elements/toc.html')
   resp = conn.getresponse()
   conn.close()

except httplib.BadStatusLine,msg:
   print "%r" %(msg)


nik@deepblack:~$ linkch.py
<httplib.BadStatusLine instance at 0x8156cac>

Python 2.2.1
FreeBSD 4.6-RC


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575360&group_id=5470



From noreply@sourceforge.net  Sat Jun 29 17:11:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 29 Jun 2002 09:11:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-575272 ] unicode() "new in" misleading
Message-ID: <E17OKoy-0005uo-00@usw-sf-web2.sourceforge.net>

Bugs item #575272, was opened at 2002-06-28 23:23
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575272&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: unicode() "new in" misleading

Initial Comment:
Documentation for the unicode() builtin says at the end
"New in 2.0".

While it's true that unicode() was added in 2.0, this
phrase comes after the section describing the use of
__unicode__() for objects that support this protocol. 
This makes it seem that the use of __unicode__() has
been around since 2.0, when in fact /that/ part of the
protocol is new in 2.2.

Can the docs be clarified here?

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-06-29 12:11

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/lib/libfuncs.tex 1.109, 1.100.4.4.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575272&group_id=5470



From noreply@sourceforge.net  Sun Jun 30 01:18:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 29 Jun 2002 17:18:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-575536 ] Concatenating a tuple to a list
Message-ID: <E17OSQC-0004ag-00@usw-sf-web4.sourceforge.net>

Bugs item #575536, was opened at 2002-06-29 19:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575536&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Grassi (dgrassi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Concatenating a tuple to a list

Initial Comment:
"a=a+b" is not the same as "a+=b" if a is a list and b is a tuple.  See the code below.

This has been tested on 2.2.1 MacPython, 2.2 MachoPython and 2.2 Python on an Alpha.

Augmented assignment (+=) with a list on the LHS allows a tuple on the RHS.  Standard assignment does not.

This seems intuitively wrong.

--- test code ---
a=[1]
b=(2,)

print 1,type(a), a
print 1,type(b), b
c=a+b

print 2,type(a), a
print 2,type(b), b
a=a+b

print 3,type(a), a
print 3,type(b), b
a+=b

print 4,type(a), a
print 4,type(b), b

Below is the execution results of the above:

>>>
>>> a=[1]
>>> b=(2,)
>>>
>>> print 1,type(a), a
1 <type 'list'> [1]
>>> print 1,type(b), b
1 <type 'tuple'> (2,)
>>> c=a+b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only concatenate list (not "tuple") to list
>>>
>>> print 2,type(a), a
2 <type 'list'> [1]
>>> print 2,type(b), b
2 <type 'tuple'> (2,)
>>> a=a+b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only concatenate list (not "tuple") to list
>>>
>>> print 3,type(a), a
3 <type 'list'> [1]
>>> print 3,type(b), b
3 <type 'tuple'> (2,)
>>> a+=b
>>>
>>> print 4,type(a), a
4 <type 'list'> [1, 2]
>>> print 4,type(b), b
4 <type 'tuple'> (2,)
>>>


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575536&group_id=5470



From noreply@sourceforge.net  Sun Jun 30 05:34:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 29 Jun 2002 21:34:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-575221 ] Library Reference, sec 3.7: UserDict
Message-ID: <E17OWPj-0007c8-00@usw-sf-web1.sourceforge.net>

Bugs item #575221, was opened at 2002-06-28 17:56
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575221&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mark J (average)
Assigned to: Steve Holden (holdenweb)
Summary: Library Reference, sec 3.7: UserDict

Initial Comment:
UserDict docs make reference to using "dictionary" type, instead of "dict" type.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-29 23:34

Message:
Logged In: YES 
user_id=80475

Fixed.  See libuserdict.tex 1.21 and 1.20.8.1


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575221&group_id=5470



From noreply@sourceforge.net  Sun Jun 30 05:45:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 29 Jun 2002 21:45:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-574978 ] Example for shutil is incorrect
Message-ID: <E17OWaQ-0007Z0-00@usw-sf-web4.sourceforge.net>

Bugs item #574978, was opened at 2002-06-28 02:08
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574978&group_id=5470

Category: Documentation
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Cameron Blackwood (drkorg)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Example for shutil is incorrect

Initial Comment:
The doc's on python.org (library reference for 2.2.1 at
url:
    http://python.org/doc/current/lib/shutil-example.html
) has sample code for a copytree function

def copytree(src, dst, symlinks=0):
  [blah blah]

but lists the action on finding a directory as:
 elif os.path.isdir(srcname):
                copytree(srcname, dstname)
which does not pass on the symlinks flag to the
sub directory copy.

You will be pleased to know that the source for the
shutil module is correct in that it has:
            elif os.path.isdir(srcname):
                copytree(srcname, dstname, symlinks)
which is correct. It's just the documentation that is
wrong.

It also seems to have been in the doc's since 1.5.2
(from my searches of old documentation here).

I know its a small thing, but hey..... every bit helps
 :^)

cheers,
cam
korg AT cs dot mu dot oz dot au


PS: python rocks with socks on

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-29 23:45

Message:
Logged In: YES 
user_id=80475

Good catch!  Keep them coming.

Fixed.  See libshutil.tex 1.10 and 1.8.14.2


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574978&group_id=5470



From noreply@sourceforge.net  Sun Jun 30 07:07:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 29 Jun 2002 23:07:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-574132 ] Major GC related performance regression
Message-ID: <E17OXrm-0008Vf-00@usw-sf-web4.sourceforge.net>

Bugs item #574132, was opened at 2002-06-26 15:33
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574132&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Kevin Jacobs (jacobs99)
>Assigned to: Tim Peters (tim_one)
Summary: Major GC related performance regression

Initial Comment:
A change in the Python 2.3 CVS tree has resulted
in a major performance regression.  It shows up
when allocating large lists of objects, but only when
the garbage collector is enabled.  I've attached a simple
script that I use to measure the time it takes to
incrementally append a large number of objects into
a single Python list.   For previous versions of
Python (up to and including 2.2.1), the time scaled
linearly with the number of elements added to the
list (or close enough for the list sizes considered).  
However, with the Python 2.3 CVS version,
the time required to build the list scales quadratically.

Here is the core of my benchmark:
  rows = []
  start = time.time()
  for i in indices:
    rows.append( (1,) )

See the attached file for the full source as well
as timing results for several versions of Python
with and without garbage collection enabled.


----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-06-30 06:07

Message:
Logged In: YES 
user_id=35752

Looks good.  Go ahead and check it in or assign it back to
me and I'll do 
it.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-29 01:50

Message:
Logged In: YES 
user_id=31435

Assigned to Neil.  I've attached a brief patch that stops 
move_root_reacahable() from pulling objects out of older 
generations into the generation being collected,  IOW, it 
makes move_root_reachable restrict itself to moving 
objects belonging to the generation being collected.  This is 
done without loss of speed (in fact, it's a little faster now).

This allows "the list" in Kevin's example to move to gen2 
and stay there.  Without the patch, it keeps getting yanked 
back into gen1 because move_root_reachable() sucks it 
out of gen1 (or gen2) and into gen0 every time gen0 gets 
collected, "just because" a bound method object in gen0 
points to the list.

Note that this didn't happen in 2.2.1 only because a bug in 
2.2.1's PyCFunction_New caused bound method objects 
not to get tracked at all.

----------------------------------------------------------------------

Comment By: Kevin Jacobs (jacobs99)
Date: 2002-06-28 14:50

Message:
Logged In: YES 
user_id=459565

Here is a detailed analysis of the problem, using the following
kernel:

lst = []
for i in range(100000):
  lst.append( (1,) )

The key ingredients are:

  1) A method is called on a container (rather than 
__setitem__ or
     __setattr__).

  2) A new object is allocated while the method object lives on 
the Python
     VM stack, as shown by the disassembled bytecodes:

         40 LOAD_FAST                1 (lst)
         43 LOAD_ATTR                3 (append)
         46 LOAD_CONST               2 (1)
         49 BUILD_TUPLE              1
         52 CALL_FUNCTION            1

These ingredients combine in the following way to trigger 
quadratic-time
behavior in the Python garbage collector:

  * First, the LOAD_ATTR on "lst" for "append" is called, and 
a PyCFunction
    is returned from this code in descrobject.c:method_get:

        return PyCFunction_New(descr->d_method, obj);

    Thus, a _new_ PyCFunction is allocated every time the 
method is
    requested.

  * This new method object is added to generation 0 of the 
garbage
    collector, which holds a reference to "lst".

  * The BUILD_TUPLE call may then trigger a garbage 
collection cycle.

  * Since the "append" method is in generation 0, the 
reference traversal
    must also follow all objects within "lst", even if "lst" is in
    generation 1 or 2.  This traversal requires time linear in the 
number of
    objects in "lst", thus increasing the overall time complexity 
of the
    code to quadratic in the number of elements in "lst".

Also note that this is a much more general problem than this 
small example.
It can affect many types of objects in addition to methods, 
including
descriptors, iterator objects, and any other object that 
contains a "back
reference".

So, what can be done about this.... One simple solution 
would be to not
traverse some "back references" if we are collecting objects 
in generation
0.  This will avoid traversing virtually all of these ephemoral 
objects that
will trigger such expensive behavior.  If they live long enough 
to pass
through to generation one or two, then clearly they should be 
traversed.

So, what do all of you GC gurus think?  Provided that my 
analysis is sound,
I can rapidly propose a patch to demonstrate this approach if 
there is
sufficient positive sentiment.

PS: I have not looked into why this doesn't happen in Python 
2.2.x or
    before.  I suspect that it must be related to the recent GC 
changes in
    methodobject.py.  I'm not motivated to spend much time 
looking into
    this, because the current GC behavior is technically 
correct, though
    clearly sub-optimal.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-27 04:10

Message:
Logged In: YES 
user_id=31392

The first 4 run calls in this test spenned 70 percent of 
their time in visit_move().

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574132&group_id=5470



From noreply@sourceforge.net  Sun Jun 30 17:35:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 30 Jun 2002 09:35:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-575536 ] Concatenating a tuple to a list
Message-ID: <E17Ohfb-0003Ju-00@usw-sf-web1.sourceforge.net>

Bugs item #575536, was opened at 2002-06-29 19:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575536&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Grassi (dgrassi)
>Assigned to: Tim Peters (tim_one)
Summary: Concatenating a tuple to a list

Initial Comment:
"a=a+b" is not the same as "a+=b" if a is a list and b is a tuple.  See the code below.

This has been tested on 2.2.1 MacPython, 2.2 MachoPython and 2.2 Python on an Alpha.

Augmented assignment (+=) with a list on the LHS allows a tuple on the RHS.  Standard assignment does not.

This seems intuitively wrong.

--- test code ---
a=[1]
b=(2,)

print 1,type(a), a
print 1,type(b), b
c=a+b

print 2,type(a), a
print 2,type(b), b
a=a+b

print 3,type(a), a
print 3,type(b), b
a+=b

print 4,type(a), a
print 4,type(b), b

Below is the execution results of the above:

>>>
>>> a=[1]
>>> b=(2,)
>>>
>>> print 1,type(a), a
1 <type 'list'> [1]
>>> print 1,type(b), b
1 <type 'tuple'> (2,)
>>> c=a+b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only concatenate list (not "tuple") to list
>>>
>>> print 2,type(a), a
2 <type 'list'> [1]
>>> print 2,type(b), b
2 <type 'tuple'> (2,)
>>> a=a+b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only concatenate list (not "tuple") to list
>>>
>>> print 3,type(a), a
3 <type 'list'> [1]
>>> print 3,type(b), b
3 <type 'tuple'> (2,)
>>> a+=b
>>>
>>> print 4,type(a), a
4 <type 'list'> [1, 2]
>>> print 4,type(b), b
4 <type 'tuple'> (2,)
>>>


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 11:35

Message:
Logged In: YES 
user_id=80475

Confirmed.  The behavior of list_inplace_concat diverged 
from list_concat.

See attached patch. Recommend applying to Py2.3 only 
since inconsistency isn't a bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575536&group_id=5470



From noreply@sourceforge.net  Sun Jun 30 17:36:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 30 Jun 2002 09:36:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-575536 ] Concatenating a tuple to a list
Message-ID: <E17Ohgj-0003Kw-00@usw-sf-web1.sourceforge.net>

Bugs item #575536, was opened at 2002-06-29 19:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575536&group_id=5470

Category: Python Interpreter Core
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Grassi (dgrassi)
Assigned to: Tim Peters (tim_one)
Summary: Concatenating a tuple to a list

Initial Comment:
"a=a+b" is not the same as "a+=b" if a is a list and b is a tuple.  See the code below.

This has been tested on 2.2.1 MacPython, 2.2 MachoPython and 2.2 Python on an Alpha.

Augmented assignment (+=) with a list on the LHS allows a tuple on the RHS.  Standard assignment does not.

This seems intuitively wrong.

--- test code ---
a=[1]
b=(2,)

print 1,type(a), a
print 1,type(b), b
c=a+b

print 2,type(a), a
print 2,type(b), b
a=a+b

print 3,type(a), a
print 3,type(b), b
a+=b

print 4,type(a), a
print 4,type(b), b

Below is the execution results of the above:

>>>
>>> a=[1]
>>> b=(2,)
>>>
>>> print 1,type(a), a
1 <type 'list'> [1]
>>> print 1,type(b), b
1 <type 'tuple'> (2,)
>>> c=a+b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only concatenate list (not "tuple") to list
>>>
>>> print 2,type(a), a
2 <type 'list'> [1]
>>> print 2,type(b), b
2 <type 'tuple'> (2,)
>>> a=a+b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only concatenate list (not "tuple") to list
>>>
>>> print 3,type(a), a
3 <type 'list'> [1]
>>> print 3,type(b), b
3 <type 'tuple'> (2,)
>>> a+=b
>>>
>>> print 4,type(a), a
4 <type 'list'> [1, 2]
>>> print 4,type(b), b
4 <type 'tuple'> (2,)
>>>


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 11:35

Message:
Logged In: YES 
user_id=80475

Confirmed.  The behavior of list_inplace_concat diverged 
from list_concat.

See attached patch. Recommend applying to Py2.3 only 
since inconsistency isn't a bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575536&group_id=5470



From noreply@sourceforge.net  Sun Jun 30 19:01:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 30 Jun 2002 11:01:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-574132 ] Major GC related performance regression
Message-ID: <E17Oj0d-0002A8-00@usw-sf-web5.sourceforge.net>

Bugs item #574132, was opened at 2002-06-26 11:33
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574132&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Kevin Jacobs (jacobs99)
Assigned to: Tim Peters (tim_one)
Summary: Major GC related performance regression

Initial Comment:
A change in the Python 2.3 CVS tree has resulted
in a major performance regression.  It shows up
when allocating large lists of objects, but only when
the garbage collector is enabled.  I've attached a simple
script that I use to measure the time it takes to
incrementally append a large number of objects into
a single Python list.   For previous versions of
Python (up to and including 2.2.1), the time scaled
linearly with the number of elements added to the
list (or close enough for the list sizes considered).  
However, with the Python 2.3 CVS version,
the time required to build the list scales quadratically.

Here is the core of my benchmark:
  rows = []
  start = time.time()
  for i in indices:
    rows.append( (1,) )

See the attached file for the full source as well
as timing results for several versions of Python
with and without garbage collection enabled.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-06-30 14:01

Message:
Logged In: YES 
user_id=31435

Fixed, in gcmodule.c revision 2.46.

I still need to backport this to 2.2.1; another bug there 
prevents the test case from showing the symptom.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-06-30 02:07

Message:
Logged In: YES 
user_id=35752

Looks good.  Go ahead and check it in or assign it back to
me and I'll do 
it.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-28 21:50

Message:
Logged In: YES 
user_id=31435

Assigned to Neil.  I've attached a brief patch that stops 
move_root_reacahable() from pulling objects out of older 
generations into the generation being collected,  IOW, it 
makes move_root_reachable restrict itself to moving 
objects belonging to the generation being collected.  This is 
done without loss of speed (in fact, it's a little faster now).

This allows "the list" in Kevin's example to move to gen2 
and stay there.  Without the patch, it keeps getting yanked 
back into gen1 because move_root_reachable() sucks it 
out of gen1 (or gen2) and into gen0 every time gen0 gets 
collected, "just because" a bound method object in gen0 
points to the list.

Note that this didn't happen in 2.2.1 only because a bug in 
2.2.1's PyCFunction_New caused bound method objects 
not to get tracked at all.

----------------------------------------------------------------------

Comment By: Kevin Jacobs (jacobs99)
Date: 2002-06-28 10:50

Message:
Logged In: YES 
user_id=459565

Here is a detailed analysis of the problem, using the following
kernel:

lst = []
for i in range(100000):
  lst.append( (1,) )

The key ingredients are:

  1) A method is called on a container (rather than 
__setitem__ or
     __setattr__).

  2) A new object is allocated while the method object lives on 
the Python
     VM stack, as shown by the disassembled bytecodes:

         40 LOAD_FAST                1 (lst)
         43 LOAD_ATTR                3 (append)
         46 LOAD_CONST               2 (1)
         49 BUILD_TUPLE              1
         52 CALL_FUNCTION            1

These ingredients combine in the following way to trigger 
quadratic-time
behavior in the Python garbage collector:

  * First, the LOAD_ATTR on "lst" for "append" is called, and 
a PyCFunction
    is returned from this code in descrobject.c:method_get:

        return PyCFunction_New(descr->d_method, obj);

    Thus, a _new_ PyCFunction is allocated every time the 
method is
    requested.

  * This new method object is added to generation 0 of the 
garbage
    collector, which holds a reference to "lst".

  * The BUILD_TUPLE call may then trigger a garbage 
collection cycle.

  * Since the "append" method is in generation 0, the 
reference traversal
    must also follow all objects within "lst", even if "lst" is in
    generation 1 or 2.  This traversal requires time linear in the 
number of
    objects in "lst", thus increasing the overall time complexity 
of the
    code to quadratic in the number of elements in "lst".

Also note that this is a much more general problem than this 
small example.
It can affect many types of objects in addition to methods, 
including
descriptors, iterator objects, and any other object that 
contains a "back
reference".

So, what can be done about this.... One simple solution 
would be to not
traverse some "back references" if we are collecting objects 
in generation
0.  This will avoid traversing virtually all of these ephemoral 
objects that
will trigger such expensive behavior.  If they live long enough 
to pass
through to generation one or two, then clearly they should be 
traversed.

So, what do all of you GC gurus think?  Provided that my 
analysis is sound,
I can rapidly propose a patch to demonstrate this approach if 
there is
sufficient positive sentiment.

PS: I have not looked into why this doesn't happen in Python 
2.2.x or
    before.  I suspect that it must be related to the recent GC 
changes in
    methodobject.py.  I'm not motivated to spend much time 
looking into
    this, because the current GC behavior is technically 
correct, though
    clearly sub-optimal.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-27 00:10

Message:
Logged In: YES 
user_id=31392

The first 4 run calls in this test spenned 70 percent of 
their time in visit_move().

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574132&group_id=5470



From noreply@sourceforge.net  Sun Jun 30 19:18:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 30 Jun 2002 11:18:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-575715 ] Parts of 2.2.1 core use old gc API
Message-ID: <E17OjGu-00054i-00@usw-sf-web1.sourceforge.net>

Bugs item #575715, was opened at 2002-06-30 14:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575715&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Neil Schemenauer (nascheme)
Summary: Parts of 2.2.1 core use old gc API

Initial Comment:
At least generators, iterators, and bound method 
objects in 2.2.1 are using the 2.1 gc API internally 
(PyObject_GC_Init & friends), which collapses to a 
bunch of nops.  That's not intentional, right?  I'm 
tempted to call it a critical bug, except nobody has 
noticed <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575715&group_id=5470



From noreply@sourceforge.net  Sun Jun 30 19:43:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 30 Jun 2002 11:43:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-575536 ] Concatenating a tuple to a list
Message-ID: <E17OjfH-0001ly-00@usw-sf-web3.sourceforge.net>

Bugs item #575536, was opened at 2002-06-30 02:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575536&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Grassi (dgrassi)
Assigned to: Tim Peters (tim_one)
Summary: Concatenating a tuple to a list

Initial Comment:
"a=a+b" is not the same as "a+=b" if a is a list and b is a tuple.  See the code below.

This has been tested on 2.2.1 MacPython, 2.2 MachoPython and 2.2 Python on an Alpha.

Augmented assignment (+=) with a list on the LHS allows a tuple on the RHS.  Standard assignment does not.

This seems intuitively wrong.

--- test code ---
a=[1]
b=(2,)

print 1,type(a), a
print 1,type(b), b
c=a+b

print 2,type(a), a
print 2,type(b), b
a=a+b

print 3,type(a), a
print 3,type(b), b
a+=b

print 4,type(a), a
print 4,type(b), b

Below is the execution results of the above:

>>>
>>> a=[1]
>>> b=(2,)
>>>
>>> print 1,type(a), a
1 <type 'list'> [1]
>>> print 1,type(b), b
1 <type 'tuple'> (2,)
>>> c=a+b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only concatenate list (not "tuple") to list
>>>
>>> print 2,type(a), a
2 <type 'list'> [1]
>>> print 2,type(b), b
2 <type 'tuple'> (2,)
>>> a=a+b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only concatenate list (not "tuple") to list
>>>
>>> print 3,type(a), a
3 <type 'list'> [1]
>>> print 3,type(b), b
3 <type 'tuple'> (2,)
>>> a+=b
>>>
>>> print 4,type(a), a
4 <type 'list'> [1, 2]
>>> print 4,type(b), b
4 <type 'tuple'> (2,)
>>>


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-30 20:43

Message:
Logged In: YES 
user_id=21627

I'm not so sure that the current += behaviour is desirable.
It means that

a=[1]
a+="hallo"
a+={1:2}

is possible, which should be a TypeError, IMO.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 18:35

Message:
Logged In: YES 
user_id=80475

Confirmed.  The behavior of list_inplace_concat diverged 
from list_concat.

See attached patch. Recommend applying to Py2.3 only 
since inconsistency isn't a bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575536&group_id=5470



From noreply@sourceforge.net  Sun Jun 30 19:46:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 30 Jun 2002 11:46:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-574241 ] Automated daily documentation builds
Message-ID: <E17Ojie-00030G-00@usw-sf-web5.sourceforge.net>

Bugs item #574241, was opened at 2002-06-26 21:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574241&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Automated daily documentation builds

Initial Comment:
Set-up a cron job or python script to make daily 
rebuilds of the Python documentation at:  
www.python.org/dev/doc/devel

Developers using Windows and not using Cygwin do 
not have a method for doing their own builds.  

I think daily updates would be helpful for all 
developers and would increase the likelihood that 
people check their patches versus current 
documentation.

Also, it increases the chance that someone will notice 
and report a documentation error earlier in the 
release cycle.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-30 20:46

Message:
Logged In: YES 
user_id=21627

I don't think this is possible. Automatic rebuilding of the
documentation will likely fail frequently, because of errors
in the tex input.

OTOH, if somebody volunteers to produce the documentation
automatically somewhere in the world (and fixes errors found
during the rebuild), then it would be easy to mirror those
on python.org.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574241&group_id=5470



From noreply@sourceforge.net  Sun Jun 30 20:00:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 30 Jun 2002 12:00:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-575536 ] Concatenating a tuple to a list
Message-ID: <E17Ojvm-0003DE-00@usw-sf-web5.sourceforge.net>

Bugs item #575536, was opened at 2002-06-29 19:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575536&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Grassi (dgrassi)
Assigned to: Tim Peters (tim_one)
Summary: Concatenating a tuple to a list

Initial Comment:
"a=a+b" is not the same as "a+=b" if a is a list and b is a tuple.  See the code below.

This has been tested on 2.2.1 MacPython, 2.2 MachoPython and 2.2 Python on an Alpha.

Augmented assignment (+=) with a list on the LHS allows a tuple on the RHS.  Standard assignment does not.

This seems intuitively wrong.

--- test code ---
a=[1]
b=(2,)

print 1,type(a), a
print 1,type(b), b
c=a+b

print 2,type(a), a
print 2,type(b), b
a=a+b

print 3,type(a), a
print 3,type(b), b
a+=b

print 4,type(a), a
print 4,type(b), b

Below is the execution results of the above:

>>>
>>> a=[1]
>>> b=(2,)
>>>
>>> print 1,type(a), a
1 <type 'list'> [1]
>>> print 1,type(b), b
1 <type 'tuple'> (2,)
>>> c=a+b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only concatenate list (not "tuple") to list
>>>
>>> print 2,type(a), a
2 <type 'list'> [1]
>>> print 2,type(b), b
2 <type 'tuple'> (2,)
>>> a=a+b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only concatenate list (not "tuple") to list
>>>
>>> print 3,type(a), a
3 <type 'list'> [1]
>>> print 3,type(b), b
3 <type 'tuple'> (2,)
>>> a+=b
>>>
>>> print 4,type(a), a
4 <type 'list'> [1, 2]
>>> print 4,type(b), b
4 <type 'tuple'> (2,)
>>>


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 14:00

Message:
Logged In: YES 
user_id=80475

Agreed. My first instinct was to restrict list_inplace_concat
() rather than liberalize list_concat(); however, it is already 
out in the wild and code may be relying on it.

One change or the other should be made since the docs 
promise that 'a op= b'  is equivalent to 'a = a op b' unless 
specifically overriden or when get/set attr is used to 
access 'a'.

Your example highlights the weirdness that can ensue; 
however, I think we already started down that road when 
everything was made iterable and, therefore, substitutable 
into weird combinations:

>>> zip([1], 'hallo', {1:2})
[(1, 'h', 1)]

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-30 13:43

Message:
Logged In: YES 
user_id=21627

I'm not so sure that the current += behaviour is desirable.
It means that

a=[1]
a+="hallo"
a+={1:2}

is possible, which should be a TypeError, IMO.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 11:35

Message:
Logged In: YES 
user_id=80475

Confirmed.  The behavior of list_inplace_concat diverged 
from list_concat.

See attached patch. Recommend applying to Py2.3 only 
since inconsistency isn't a bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575536&group_id=5470



From noreply@sourceforge.net  Sun Jun 30 20:04:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 30 Jun 2002 12:04:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-575536 ] Concatenating a tuple to a list
Message-ID: <E17Ok09-0004CV-00@usw-sf-web2.sourceforge.net>

Bugs item #575536, was opened at 2002-06-29 20:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575536&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Grassi (dgrassi)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Concatenating a tuple to a list

Initial Comment:
"a=a+b" is not the same as "a+=b" if a is a list and b is a tuple.  See the code below.

This has been tested on 2.2.1 MacPython, 2.2 MachoPython and 2.2 Python on an Alpha.

Augmented assignment (+=) with a list on the LHS allows a tuple on the RHS.  Standard assignment does not.

This seems intuitively wrong.

--- test code ---
a=[1]
b=(2,)

print 1,type(a), a
print 1,type(b), b
c=a+b

print 2,type(a), a
print 2,type(b), b
a=a+b

print 3,type(a), a
print 3,type(b), b
a+=b

print 4,type(a), a
print 4,type(b), b

Below is the execution results of the above:

>>>
>>> a=[1]
>>> b=(2,)
>>>
>>> print 1,type(a), a
1 <type 'list'> [1]
>>> print 1,type(b), b
1 <type 'tuple'> (2,)
>>> c=a+b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only concatenate list (not "tuple") to list
>>>
>>> print 2,type(a), a
2 <type 'list'> [1]
>>> print 2,type(b), b
2 <type 'tuple'> (2,)
>>> a=a+b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only concatenate list (not "tuple") to list
>>>
>>> print 3,type(a), a
3 <type 'list'> [1]
>>> print 3,type(b), b
3 <type 'tuple'> (2,)
>>> a+=b
>>>
>>> print 4,type(a), a
4 <type 'list'> [1, 2]
>>> print 4,type(b), b
4 <type 'tuple'> (2,)
>>>


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-06-30 15:04

Message:
Logged In: YES 
user_id=31435

This is all intentional.  Lists choose to implement

list += whatever

as a synonym for

list.extend(whatever)

and whatever can be any iterable object in both.  It's A 
Feature that mutable objects can choose to do something 
different for += than for +.

Trying to make tuples do this too is a bad idea -- there is 
no tuple.extend(), and there can't be because tuples are 
immutable.

Lists and tuples differ here.  If they were the same thing, 
there wouldn't be much point to having both <wink>.

I recommend closing as WontFix, although it's quite 
possible the docs could be improved (haven't looked).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 15:00

Message:
Logged In: YES 
user_id=80475

Agreed. My first instinct was to restrict list_inplace_concat
() rather than liberalize list_concat(); however, it is already 
out in the wild and code may be relying on it.

One change or the other should be made since the docs 
promise that 'a op= b'  is equivalent to 'a = a op b' unless 
specifically overriden or when get/set attr is used to 
access 'a'.

Your example highlights the weirdness that can ensue; 
however, I think we already started down that road when 
everything was made iterable and, therefore, substitutable 
into weird combinations:

>>> zip([1], 'hallo', {1:2})
[(1, 'h', 1)]

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-30 14:43

Message:
Logged In: YES 
user_id=21627

I'm not so sure that the current += behaviour is desirable.
It means that

a=[1]
a+="hallo"
a+={1:2}

is possible, which should be a TypeError, IMO.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 12:35

Message:
Logged In: YES 
user_id=80475

Confirmed.  The behavior of list_inplace_concat diverged 
from list_concat.

See attached patch. Recommend applying to Py2.3 only 
since inconsistency isn't a bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575536&group_id=5470



From noreply@sourceforge.net  Sun Jun 30 20:08:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 30 Jun 2002 12:08:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-575536 ] Concatenating a tuple to a list
Message-ID: <E17Ok4A-0005vK-00@usw-sf-web1.sourceforge.net>

Bugs item #575536, was opened at 2002-06-29 19:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575536&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Grassi (dgrassi)
>Assigned to: Tim Peters (tim_one)
Summary: Concatenating a tuple to a list

Initial Comment:
"a=a+b" is not the same as "a+=b" if a is a list and b is a tuple.  See the code below.

This has been tested on 2.2.1 MacPython, 2.2 MachoPython and 2.2 Python on an Alpha.

Augmented assignment (+=) with a list on the LHS allows a tuple on the RHS.  Standard assignment does not.

This seems intuitively wrong.

--- test code ---
a=[1]
b=(2,)

print 1,type(a), a
print 1,type(b), b
c=a+b

print 2,type(a), a
print 2,type(b), b
a=a+b

print 3,type(a), a
print 3,type(b), b
a+=b

print 4,type(a), a
print 4,type(b), b

Below is the execution results of the above:

>>>
>>> a=[1]
>>> b=(2,)
>>>
>>> print 1,type(a), a
1 <type 'list'> [1]
>>> print 1,type(b), b
1 <type 'tuple'> (2,)
>>> c=a+b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only concatenate list (not "tuple") to list
>>>
>>> print 2,type(a), a
2 <type 'list'> [1]
>>> print 2,type(b), b
2 <type 'tuple'> (2,)
>>> a=a+b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only concatenate list (not "tuple") to list
>>>
>>> print 3,type(a), a
3 <type 'list'> [1]
>>> print 3,type(b), b
3 <type 'tuple'> (2,)
>>> a+=b
>>>
>>> print 4,type(a), a
4 <type 'list'> [1, 2]
>>> print 4,type(b), b
4 <type 'tuple'> (2,)
>>>


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 14:08

Message:
Logged In: YES 
user_id=80475

One other thought -- list.__add__ 's  behavior should 
correspond closely to list.extend():

>>> a = [1]
>>> a.extend((2,3))
>>> a.extend({4:5})
>>> a
[1, 2, 3, 4]

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-30 14:04

Message:
Logged In: YES 
user_id=31435

This is all intentional.  Lists choose to implement

list += whatever

as a synonym for

list.extend(whatever)

and whatever can be any iterable object in both.  It's A 
Feature that mutable objects can choose to do something 
different for += than for +.

Trying to make tuples do this too is a bad idea -- there is 
no tuple.extend(), and there can't be because tuples are 
immutable.

Lists and tuples differ here.  If they were the same thing, 
there wouldn't be much point to having both <wink>.

I recommend closing as WontFix, although it's quite 
possible the docs could be improved (haven't looked).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 14:00

Message:
Logged In: YES 
user_id=80475

Agreed. My first instinct was to restrict list_inplace_concat
() rather than liberalize list_concat(); however, it is already 
out in the wild and code may be relying on it.

One change or the other should be made since the docs 
promise that 'a op= b'  is equivalent to 'a = a op b' unless 
specifically overriden or when get/set attr is used to 
access 'a'.

Your example highlights the weirdness that can ensue; 
however, I think we already started down that road when 
everything was made iterable and, therefore, substitutable 
into weird combinations:

>>> zip([1], 'hallo', {1:2})
[(1, 'h', 1)]

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-30 13:43

Message:
Logged In: YES 
user_id=21627

I'm not so sure that the current += behaviour is desirable.
It means that

a=[1]
a+="hallo"
a+={1:2}

is possible, which should be a TypeError, IMO.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 11:35

Message:
Logged In: YES 
user_id=80475

Confirmed.  The behavior of list_inplace_concat diverged 
from list_concat.

See attached patch. Recommend applying to Py2.3 only 
since inconsistency isn't a bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575536&group_id=5470



From noreply@sourceforge.net  Sun Jun 30 20:25:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 30 Jun 2002 12:25:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-575536 ] Concatenating a tuple to a list
Message-ID: <E17OkKA-0004YM-00@usw-sf-web2.sourceforge.net>

Bugs item #575536, was opened at 2002-06-29 20:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575536&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Grassi (dgrassi)
Assigned to: Tim Peters (tim_one)
Summary: Concatenating a tuple to a list

Initial Comment:
"a=a+b" is not the same as "a+=b" if a is a list and b is a tuple.  See the code below.

This has been tested on 2.2.1 MacPython, 2.2 MachoPython and 2.2 Python on an Alpha.

Augmented assignment (+=) with a list on the LHS allows a tuple on the RHS.  Standard assignment does not.

This seems intuitively wrong.

--- test code ---
a=[1]
b=(2,)

print 1,type(a), a
print 1,type(b), b
c=a+b

print 2,type(a), a
print 2,type(b), b
a=a+b

print 3,type(a), a
print 3,type(b), b
a+=b

print 4,type(a), a
print 4,type(b), b

Below is the execution results of the above:

>>>
>>> a=[1]
>>> b=(2,)
>>>
>>> print 1,type(a), a
1 <type 'list'> [1]
>>> print 1,type(b), b
1 <type 'tuple'> (2,)
>>> c=a+b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only concatenate list (not "tuple") to list
>>>
>>> print 2,type(a), a
2 <type 'list'> [1]
>>> print 2,type(b), b
2 <type 'tuple'> (2,)
>>> a=a+b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only concatenate list (not "tuple") to list
>>>
>>> print 3,type(a), a
3 <type 'list'> [1]
>>> print 3,type(b), b
3 <type 'tuple'> (2,)
>>> a+=b
>>>
>>> print 4,type(a), a
4 <type 'list'> [1, 2]
>>> print 4,type(b), b
4 <type 'tuple'> (2,)
>>>


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-06-30 15:25

Message:
Logged In: YES 
user_id=31435

The intent was that list.__iadd__ correspond exactly to 
list.extend().  There's no need to hypergeneralize 
list.__add__() too:  it's a feature that people who don't 
want to get surprised by Martin-like examples can avoid 
them by using plain + for lists.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 15:08

Message:
Logged In: YES 
user_id=80475

One other thought -- list.__add__ 's  behavior should 
correspond closely to list.extend():

>>> a = [1]
>>> a.extend((2,3))
>>> a.extend({4:5})
>>> a
[1, 2, 3, 4]

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-30 15:04

Message:
Logged In: YES 
user_id=31435

This is all intentional.  Lists choose to implement

list += whatever

as a synonym for

list.extend(whatever)

and whatever can be any iterable object in both.  It's A 
Feature that mutable objects can choose to do something 
different for += than for +.

Trying to make tuples do this too is a bad idea -- there is 
no tuple.extend(), and there can't be because tuples are 
immutable.

Lists and tuples differ here.  If they were the same thing, 
there wouldn't be much point to having both <wink>.

I recommend closing as WontFix, although it's quite 
possible the docs could be improved (haven't looked).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 15:00

Message:
Logged In: YES 
user_id=80475

Agreed. My first instinct was to restrict list_inplace_concat
() rather than liberalize list_concat(); however, it is already 
out in the wild and code may be relying on it.

One change or the other should be made since the docs 
promise that 'a op= b'  is equivalent to 'a = a op b' unless 
specifically overriden or when get/set attr is used to 
access 'a'.

Your example highlights the weirdness that can ensue; 
however, I think we already started down that road when 
everything was made iterable and, therefore, substitutable 
into weird combinations:

>>> zip([1], 'hallo', {1:2})
[(1, 'h', 1)]

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-30 14:43

Message:
Logged In: YES 
user_id=21627

I'm not so sure that the current += behaviour is desirable.
It means that

a=[1]
a+="hallo"
a+={1:2}

is possible, which should be a TypeError, IMO.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 12:35

Message:
Logged In: YES 
user_id=80475

Confirmed.  The behavior of list_inplace_concat diverged 
from list_concat.

See attached patch. Recommend applying to Py2.3 only 
since inconsistency isn't a bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575536&group_id=5470



From noreply@sourceforge.net  Sun Jun 30 20:31:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 30 Jun 2002 12:31:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-575536 ] Concatenating a tuple to a list
Message-ID: <E17OkQJ-0006JA-00@usw-sf-web1.sourceforge.net>

Bugs item #575536, was opened at 2002-06-29 20:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575536&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Grassi (dgrassi)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Concatenating a tuple to a list

Initial Comment:
"a=a+b" is not the same as "a+=b" if a is a list and b is a tuple.  See the code below.

This has been tested on 2.2.1 MacPython, 2.2 MachoPython and 2.2 Python on an Alpha.

Augmented assignment (+=) with a list on the LHS allows a tuple on the RHS.  Standard assignment does not.

This seems intuitively wrong.

--- test code ---
a=[1]
b=(2,)

print 1,type(a), a
print 1,type(b), b
c=a+b

print 2,type(a), a
print 2,type(b), b
a=a+b

print 3,type(a), a
print 3,type(b), b
a+=b

print 4,type(a), a
print 4,type(b), b

Below is the execution results of the above:

>>>
>>> a=[1]
>>> b=(2,)
>>>
>>> print 1,type(a), a
1 <type 'list'> [1]
>>> print 1,type(b), b
1 <type 'tuple'> (2,)
>>> c=a+b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only concatenate list (not "tuple") to list
>>>
>>> print 2,type(a), a
2 <type 'list'> [1]
>>> print 2,type(b), b
2 <type 'tuple'> (2,)
>>> a=a+b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only concatenate list (not "tuple") to list
>>>
>>> print 3,type(a), a
3 <type 'list'> [1]
>>> print 3,type(b), b
3 <type 'tuple'> (2,)
>>> a+=b
>>>
>>> print 4,type(a), a
4 <type 'list'> [1, 2]
>>> print 4,type(b), b
4 <type 'tuple'> (2,)
>>>


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-06-30 15:31

Message:
Logged In: YES 
user_id=31435

Dueling edits.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-30 15:25

Message:
Logged In: YES 
user_id=31435

The intent was that list.__iadd__ correspond exactly to 
list.extend().  There's no need to hypergeneralize 
list.__add__() too:  it's a feature that people who don't 
want to get surprised by Martin-like examples can avoid 
them by using plain + for lists.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 15:08

Message:
Logged In: YES 
user_id=80475

One other thought -- list.__add__ 's  behavior should 
correspond closely to list.extend():

>>> a = [1]
>>> a.extend((2,3))
>>> a.extend({4:5})
>>> a
[1, 2, 3, 4]

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-30 15:04

Message:
Logged In: YES 
user_id=31435

This is all intentional.  Lists choose to implement

list += whatever

as a synonym for

list.extend(whatever)

and whatever can be any iterable object in both.  It's A 
Feature that mutable objects can choose to do something 
different for += than for +.

Trying to make tuples do this too is a bad idea -- there is 
no tuple.extend(), and there can't be because tuples are 
immutable.

Lists and tuples differ here.  If they were the same thing, 
there wouldn't be much point to having both <wink>.

I recommend closing as WontFix, although it's quite 
possible the docs could be improved (haven't looked).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 15:00

Message:
Logged In: YES 
user_id=80475

Agreed. My first instinct was to restrict list_inplace_concat
() rather than liberalize list_concat(); however, it is already 
out in the wild and code may be relying on it.

One change or the other should be made since the docs 
promise that 'a op= b'  is equivalent to 'a = a op b' unless 
specifically overriden or when get/set attr is used to 
access 'a'.

Your example highlights the weirdness that can ensue; 
however, I think we already started down that road when 
everything was made iterable and, therefore, substitutable 
into weird combinations:

>>> zip([1], 'hallo', {1:2})
[(1, 'h', 1)]

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-30 14:43

Message:
Logged In: YES 
user_id=21627

I'm not so sure that the current += behaviour is desirable.
It means that

a=[1]
a+="hallo"
a+={1:2}

is possible, which should be a TypeError, IMO.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 12:35

Message:
Logged In: YES 
user_id=80475

Confirmed.  The behavior of list_inplace_concat diverged 
from list_concat.

See attached patch. Recommend applying to Py2.3 only 
since inconsistency isn't a bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575536&group_id=5470



From noreply@sourceforge.net  Sun Jun 30 20:37:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 30 Jun 2002 12:37:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-575536 ] Concatenating a tuple to a list
Message-ID: <E17OkW9-0003Ws-00@usw-sf-web4.sourceforge.net>

Bugs item #575536, was opened at 2002-06-29 19:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575536&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Grassi (dgrassi)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Concatenating a tuple to a list

Initial Comment:
"a=a+b" is not the same as "a+=b" if a is a list and b is a tuple.  See the code below.

This has been tested on 2.2.1 MacPython, 2.2 MachoPython and 2.2 Python on an Alpha.

Augmented assignment (+=) with a list on the LHS allows a tuple on the RHS.  Standard assignment does not.

This seems intuitively wrong.

--- test code ---
a=[1]
b=(2,)

print 1,type(a), a
print 1,type(b), b
c=a+b

print 2,type(a), a
print 2,type(b), b
a=a+b

print 3,type(a), a
print 3,type(b), b
a+=b

print 4,type(a), a
print 4,type(b), b

Below is the execution results of the above:

>>>
>>> a=[1]
>>> b=(2,)
>>>
>>> print 1,type(a), a
1 <type 'list'> [1]
>>> print 1,type(b), b
1 <type 'tuple'> (2,)
>>> c=a+b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only concatenate list (not "tuple") to list
>>>
>>> print 2,type(a), a
2 <type 'list'> [1]
>>> print 2,type(b), b
2 <type 'tuple'> (2,)
>>> a=a+b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only concatenate list (not "tuple") to list
>>>
>>> print 3,type(a), a
3 <type 'list'> [1]
>>> print 3,type(b), b
3 <type 'tuple'> (2,)
>>> a+=b
>>>
>>> print 4,type(a), a
4 <type 'list'> [1, 2]
>>> print 4,type(b), b
4 <type 'tuple'> (2,)
>>>


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 14:37

Message:
Logged In: YES 
user_id=80475

I have zero emotional attachment to this. Do whatever you 
think best: accept it, close it, or assign to GvR to get a 
pronouncement for alltime.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-30 14:31

Message:
Logged In: YES 
user_id=31435

Dueling edits.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-30 14:25

Message:
Logged In: YES 
user_id=31435

The intent was that list.__iadd__ correspond exactly to 
list.extend().  There's no need to hypergeneralize 
list.__add__() too:  it's a feature that people who don't 
want to get surprised by Martin-like examples can avoid 
them by using plain + for lists.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 14:08

Message:
Logged In: YES 
user_id=80475

One other thought -- list.__add__ 's  behavior should 
correspond closely to list.extend():

>>> a = [1]
>>> a.extend((2,3))
>>> a.extend({4:5})
>>> a
[1, 2, 3, 4]

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-30 14:04

Message:
Logged In: YES 
user_id=31435

This is all intentional.  Lists choose to implement

list += whatever

as a synonym for

list.extend(whatever)

and whatever can be any iterable object in both.  It's A 
Feature that mutable objects can choose to do something 
different for += than for +.

Trying to make tuples do this too is a bad idea -- there is 
no tuple.extend(), and there can't be because tuples are 
immutable.

Lists and tuples differ here.  If they were the same thing, 
there wouldn't be much point to having both <wink>.

I recommend closing as WontFix, although it's quite 
possible the docs could be improved (haven't looked).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 14:00

Message:
Logged In: YES 
user_id=80475

Agreed. My first instinct was to restrict list_inplace_concat
() rather than liberalize list_concat(); however, it is already 
out in the wild and code may be relying on it.

One change or the other should be made since the docs 
promise that 'a op= b'  is equivalent to 'a = a op b' unless 
specifically overriden or when get/set attr is used to 
access 'a'.

Your example highlights the weirdness that can ensue; 
however, I think we already started down that road when 
everything was made iterable and, therefore, substitutable 
into weird combinations:

>>> zip([1], 'hallo', {1:2})
[(1, 'h', 1)]

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-30 13:43

Message:
Logged In: YES 
user_id=21627

I'm not so sure that the current += behaviour is desirable.
It means that

a=[1]
a+="hallo"
a+={1:2}

is possible, which should be a TypeError, IMO.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 11:35

Message:
Logged In: YES 
user_id=80475

Confirmed.  The behavior of list_inplace_concat diverged 
from list_concat.

See attached patch. Recommend applying to Py2.3 only 
since inconsistency isn't a bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575536&group_id=5470



From noreply@sourceforge.net  Sun Jun 30 20:42:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 30 Jun 2002 12:42:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-575536 ] Concatenating a tuple to a list
Message-ID: <E17Okb4-0003Zg-00@usw-sf-web4.sourceforge.net>

Bugs item #575536, was opened at 2002-06-29 19:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575536&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Grassi (dgrassi)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Concatenating a tuple to a list

Initial Comment:
"a=a+b" is not the same as "a+=b" if a is a list and b is a tuple.  See the code below.

This has been tested on 2.2.1 MacPython, 2.2 MachoPython and 2.2 Python on an Alpha.

Augmented assignment (+=) with a list on the LHS allows a tuple on the RHS.  Standard assignment does not.

This seems intuitively wrong.

--- test code ---
a=[1]
b=(2,)

print 1,type(a), a
print 1,type(b), b
c=a+b

print 2,type(a), a
print 2,type(b), b
a=a+b

print 3,type(a), a
print 3,type(b), b
a+=b

print 4,type(a), a
print 4,type(b), b

Below is the execution results of the above:

>>>
>>> a=[1]
>>> b=(2,)
>>>
>>> print 1,type(a), a
1 <type 'list'> [1]
>>> print 1,type(b), b
1 <type 'tuple'> (2,)
>>> c=a+b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only concatenate list (not "tuple") to list
>>>
>>> print 2,type(a), a
2 <type 'list'> [1]
>>> print 2,type(b), b
2 <type 'tuple'> (2,)
>>> a=a+b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only concatenate list (not "tuple") to list
>>>
>>> print 3,type(a), a
3 <type 'list'> [1]
>>> print 3,type(b), b
3 <type 'tuple'> (2,)
>>> a+=b
>>>
>>> print 4,type(a), a
4 <type 'list'> [1, 2]
>>> print 4,type(b), b
4 <type 'tuple'> (2,)
>>>


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 14:42

Message:
Logged In: YES 
user_id=80475

GvR,  please pronounce.
1. liberalize list_concat to match list_inplace_concat,
2. restrict list_inplace_concat to match list_concat, or
3. declare it fine the way it is.

While you're at it, pronounce for tuples also.  Timbot 
makes a good argument that they should be left alone.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 14:37

Message:
Logged In: YES 
user_id=80475

I have zero emotional attachment to this. Do whatever you 
think best: accept it, close it, or assign to GvR to get a 
pronouncement for alltime.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-30 14:31

Message:
Logged In: YES 
user_id=31435

Dueling edits.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-30 14:25

Message:
Logged In: YES 
user_id=31435

The intent was that list.__iadd__ correspond exactly to 
list.extend().  There's no need to hypergeneralize 
list.__add__() too:  it's a feature that people who don't 
want to get surprised by Martin-like examples can avoid 
them by using plain + for lists.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 14:08

Message:
Logged In: YES 
user_id=80475

One other thought -- list.__add__ 's  behavior should 
correspond closely to list.extend():

>>> a = [1]
>>> a.extend((2,3))
>>> a.extend({4:5})
>>> a
[1, 2, 3, 4]

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-30 14:04

Message:
Logged In: YES 
user_id=31435

This is all intentional.  Lists choose to implement

list += whatever

as a synonym for

list.extend(whatever)

and whatever can be any iterable object in both.  It's A 
Feature that mutable objects can choose to do something 
different for += than for +.

Trying to make tuples do this too is a bad idea -- there is 
no tuple.extend(), and there can't be because tuples are 
immutable.

Lists and tuples differ here.  If they were the same thing, 
there wouldn't be much point to having both <wink>.

I recommend closing as WontFix, although it's quite 
possible the docs could be improved (haven't looked).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 14:00

Message:
Logged In: YES 
user_id=80475

Agreed. My first instinct was to restrict list_inplace_concat
() rather than liberalize list_concat(); however, it is already 
out in the wild and code may be relying on it.

One change or the other should be made since the docs 
promise that 'a op= b'  is equivalent to 'a = a op b' unless 
specifically overriden or when get/set attr is used to 
access 'a'.

Your example highlights the weirdness that can ensue; 
however, I think we already started down that road when 
everything was made iterable and, therefore, substitutable 
into weird combinations:

>>> zip([1], 'hallo', {1:2})
[(1, 'h', 1)]

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-30 13:43

Message:
Logged In: YES 
user_id=21627

I'm not so sure that the current += behaviour is desirable.
It means that

a=[1]
a+="hallo"
a+={1:2}

is possible, which should be a TypeError, IMO.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 11:35

Message:
Logged In: YES 
user_id=80475

Confirmed.  The behavior of list_inplace_concat diverged 
from list_concat.

See attached patch. Recommend applying to Py2.3 only 
since inconsistency isn't a bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575536&group_id=5470



From noreply@sourceforge.net  Sun Jun 30 22:20:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 30 Jun 2002 14:20:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-575536 ] Concatenating a tuple to a list
Message-ID: <E17Om75-0003XU-00@usw-sf-web3.sourceforge.net>

Bugs item #575536, was opened at 2002-06-30 02:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575536&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Grassi (dgrassi)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Concatenating a tuple to a list

Initial Comment:
"a=a+b" is not the same as "a+=b" if a is a list and b is a tuple.  See the code below.

This has been tested on 2.2.1 MacPython, 2.2 MachoPython and 2.2 Python on an Alpha.

Augmented assignment (+=) with a list on the LHS allows a tuple on the RHS.  Standard assignment does not.

This seems intuitively wrong.

--- test code ---
a=[1]
b=(2,)

print 1,type(a), a
print 1,type(b), b
c=a+b

print 2,type(a), a
print 2,type(b), b
a=a+b

print 3,type(a), a
print 3,type(b), b
a+=b

print 4,type(a), a
print 4,type(b), b

Below is the execution results of the above:

>>>
>>> a=[1]
>>> b=(2,)
>>>
>>> print 1,type(a), a
1 <type 'list'> [1]
>>> print 1,type(b), b
1 <type 'tuple'> (2,)
>>> c=a+b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only concatenate list (not "tuple") to list
>>>
>>> print 2,type(a), a
2 <type 'list'> [1]
>>> print 2,type(b), b
2 <type 'tuple'> (2,)
>>> a=a+b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only concatenate list (not "tuple") to list
>>>
>>> print 3,type(a), a
3 <type 'list'> [1]
>>> print 3,type(b), b
3 <type 'tuple'> (2,)
>>> a+=b
>>>
>>> print 4,type(a), a
4 <type 'list'> [1, 2]
>>> print 4,type(b), b
4 <type 'tuple'> (2,)
>>>


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-30 23:20

Message:
Logged In: YES 
user_id=21627

I can follow Tim's view that += matches extend, and I have
to accept that extend allows arbitrary sequences. At the
same time, I think the proposed patch is wrong: Why should
[]+() return a list and not a tuple? 

So I propose to close this as "Won't fix". If Raymond and
Dan can agree, we don't need a pronouncement.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 21:42

Message:
Logged In: YES 
user_id=80475

GvR,  please pronounce.
1. liberalize list_concat to match list_inplace_concat,
2. restrict list_inplace_concat to match list_concat, or
3. declare it fine the way it is.

While you're at it, pronounce for tuples also.  Timbot 
makes a good argument that they should be left alone.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 21:37

Message:
Logged In: YES 
user_id=80475

I have zero emotional attachment to this. Do whatever you 
think best: accept it, close it, or assign to GvR to get a 
pronouncement for alltime.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-30 21:31

Message:
Logged In: YES 
user_id=31435

Dueling edits.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-30 21:25

Message:
Logged In: YES 
user_id=31435

The intent was that list.__iadd__ correspond exactly to 
list.extend().  There's no need to hypergeneralize 
list.__add__() too:  it's a feature that people who don't 
want to get surprised by Martin-like examples can avoid 
them by using plain + for lists.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 21:08

Message:
Logged In: YES 
user_id=80475

One other thought -- list.__add__ 's  behavior should 
correspond closely to list.extend():

>>> a = [1]
>>> a.extend((2,3))
>>> a.extend({4:5})
>>> a
[1, 2, 3, 4]

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-30 21:04

Message:
Logged In: YES 
user_id=31435

This is all intentional.  Lists choose to implement

list += whatever

as a synonym for

list.extend(whatever)

and whatever can be any iterable object in both.  It's A 
Feature that mutable objects can choose to do something 
different for += than for +.

Trying to make tuples do this too is a bad idea -- there is 
no tuple.extend(), and there can't be because tuples are 
immutable.

Lists and tuples differ here.  If they were the same thing, 
there wouldn't be much point to having both <wink>.

I recommend closing as WontFix, although it's quite 
possible the docs could be improved (haven't looked).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 21:00

Message:
Logged In: YES 
user_id=80475

Agreed. My first instinct was to restrict list_inplace_concat
() rather than liberalize list_concat(); however, it is already 
out in the wild and code may be relying on it.

One change or the other should be made since the docs 
promise that 'a op= b'  is equivalent to 'a = a op b' unless 
specifically overriden or when get/set attr is used to 
access 'a'.

Your example highlights the weirdness that can ensue; 
however, I think we already started down that road when 
everything was made iterable and, therefore, substitutable 
into weird combinations:

>>> zip([1], 'hallo', {1:2})
[(1, 'h', 1)]

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-30 20:43

Message:
Logged In: YES 
user_id=21627

I'm not so sure that the current += behaviour is desirable.
It means that

a=[1]
a+="hallo"
a+={1:2}

is possible, which should be a TypeError, IMO.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 18:35

Message:
Logged In: YES 
user_id=80475

Confirmed.  The behavior of list_inplace_concat diverged 
from list_concat.

See attached patch. Recommend applying to Py2.3 only 
since inconsistency isn't a bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575536&group_id=5470



From noreply@sourceforge.net  Sun Jun 30 22:32:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 30 Jun 2002 14:32:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-575536 ] Concatenating a tuple to a list
Message-ID: <E17OmIb-0006Ji-00@usw-sf-web2.sourceforge.net>

Bugs item #575536, was opened at 2002-06-29 19:18
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575536&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Dan Grassi (dgrassi)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Concatenating a tuple to a list

Initial Comment:
"a=a+b" is not the same as "a+=b" if a is a list and b is a tuple.  See the code below.

This has been tested on 2.2.1 MacPython, 2.2 MachoPython and 2.2 Python on an Alpha.

Augmented assignment (+=) with a list on the LHS allows a tuple on the RHS.  Standard assignment does not.

This seems intuitively wrong.

--- test code ---
a=[1]
b=(2,)

print 1,type(a), a
print 1,type(b), b
c=a+b

print 2,type(a), a
print 2,type(b), b
a=a+b

print 3,type(a), a
print 3,type(b), b
a+=b

print 4,type(a), a
print 4,type(b), b

Below is the execution results of the above:

>>>
>>> a=[1]
>>> b=(2,)
>>>
>>> print 1,type(a), a
1 <type 'list'> [1]
>>> print 1,type(b), b
1 <type 'tuple'> (2,)
>>> c=a+b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only concatenate list (not "tuple") to list
>>>
>>> print 2,type(a), a
2 <type 'list'> [1]
>>> print 2,type(b), b
2 <type 'tuple'> (2,)
>>> a=a+b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only concatenate list (not "tuple") to list
>>>
>>> print 3,type(a), a
3 <type 'list'> [1]
>>> print 3,type(b), b
3 <type 'tuple'> (2,)
>>> a+=b
>>>
>>> print 4,type(a), a
4 <type 'list'> [1, 2]
>>> print 4,type(b), b
4 <type 'tuple'> (2,)
>>>


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 16:32

Message:
Logged In: YES 
user_id=80475

Done.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-30 16:20

Message:
Logged In: YES 
user_id=21627

I can follow Tim's view that += matches extend, and I have
to accept that extend allows arbitrary sequences. At the
same time, I think the proposed patch is wrong: Why should
[]+() return a list and not a tuple? 

So I propose to close this as "Won't fix". If Raymond and
Dan can agree, we don't need a pronouncement.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 14:42

Message:
Logged In: YES 
user_id=80475

GvR,  please pronounce.
1. liberalize list_concat to match list_inplace_concat,
2. restrict list_inplace_concat to match list_concat, or
3. declare it fine the way it is.

While you're at it, pronounce for tuples also.  Timbot 
makes a good argument that they should be left alone.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 14:37

Message:
Logged In: YES 
user_id=80475

I have zero emotional attachment to this. Do whatever you 
think best: accept it, close it, or assign to GvR to get a 
pronouncement for alltime.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-30 14:31

Message:
Logged In: YES 
user_id=31435

Dueling edits.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-30 14:25

Message:
Logged In: YES 
user_id=31435

The intent was that list.__iadd__ correspond exactly to 
list.extend().  There's no need to hypergeneralize 
list.__add__() too:  it's a feature that people who don't 
want to get surprised by Martin-like examples can avoid 
them by using plain + for lists.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 14:08

Message:
Logged In: YES 
user_id=80475

One other thought -- list.__add__ 's  behavior should 
correspond closely to list.extend():

>>> a = [1]
>>> a.extend((2,3))
>>> a.extend({4:5})
>>> a
[1, 2, 3, 4]

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-06-30 14:04

Message:
Logged In: YES 
user_id=31435

This is all intentional.  Lists choose to implement

list += whatever

as a synonym for

list.extend(whatever)

and whatever can be any iterable object in both.  It's A 
Feature that mutable objects can choose to do something 
different for += than for +.

Trying to make tuples do this too is a bad idea -- there is 
no tuple.extend(), and there can't be because tuples are 
immutable.

Lists and tuples differ here.  If they were the same thing, 
there wouldn't be much point to having both <wink>.

I recommend closing as WontFix, although it's quite 
possible the docs could be improved (haven't looked).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 14:00

Message:
Logged In: YES 
user_id=80475

Agreed. My first instinct was to restrict list_inplace_concat
() rather than liberalize list_concat(); however, it is already 
out in the wild and code may be relying on it.

One change or the other should be made since the docs 
promise that 'a op= b'  is equivalent to 'a = a op b' unless 
specifically overriden or when get/set attr is used to 
access 'a'.

Your example highlights the weirdness that can ensue; 
however, I think we already started down that road when 
everything was made iterable and, therefore, substitutable 
into weird combinations:

>>> zip([1], 'hallo', {1:2})
[(1, 'h', 1)]

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-30 13:43

Message:
Logged In: YES 
user_id=21627

I'm not so sure that the current += behaviour is desirable.
It means that

a=[1]
a+="hallo"
a+={1:2}

is possible, which should be a TypeError, IMO.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-06-30 11:35

Message:
Logged In: YES 
user_id=80475

Confirmed.  The behavior of list_inplace_concat diverged 
from list_concat.

See attached patch. Recommend applying to Py2.3 only 
since inconsistency isn't a bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575536&group_id=5470



From noreply@sourceforge.net  Sun Jun 30 23:15:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 30 Jun 2002 15:15:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-575770 ] os.spawnv() fails with underscores
Message-ID: <E17OmyP-0006P0-00@usw-sf-web5.sourceforge.net>

Bugs item #575770, was opened at 2002-06-30 22:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575770&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Rodrigues (nokta_kanto)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.spawnv() fails with underscores

Initial Comment:
 I'm running Python 2.2 in Windows 98. 
 
When trying to os.spawnv() a program in a path that contains an 
underscore, the program does not run but no error message is 
printed.  This error happens in the dos version of Python 2.2, but 
not in IDLE. 
 
I detected the error by creating a DOS program that returns the 
recognizable value 111. If I call that file "c:\ret111.exe" and run it with 
the following command: 
 
os.spawnv( os.P_WAIT, progname, [progname] ) 
 
where progname is the full path and name of the program, then the 
function returns the value 111.  If I put that file in 
"c:\pulse_prog\ret111.exe", and run the same command with the new 
value of progname, then the return value is 111 in IDLE but 0 in 
dos-prompt python. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575770&group_id=5470



From noreply@sourceforge.net  Sun Jun 30 23:27:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 30 Jun 2002 15:27:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-575773 ] Negative __len__ provokes SystemError
Message-ID: <E17OnAS-0005L7-00@usw-sf-web4.sourceforge.net>

Bugs item #575773, was opened at 2002-06-30 22:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575773&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tony Lownds (tonylownds)
Assigned to: Nobody/Anonymous (nobody)
Summary: Negative __len__ provokes SystemError

Initial Comment:
class A(object):
  def __len__(self): 
    return -2  # anything < 0

  def __getslice__(self, x, y):  
    pass

A()[-1:]   # anything < 0

... results in....

Traceback (most recent call last):
  File "cause_system_error.py", line 8, in ?
    A()[-1:]   # anything < 0
SystemError: error return without exception set




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575773&group_id=5470