[ python-Bugs-1401642 ] Win32COM policy.py unicode exceptions

[SourceForge.net]

Bugs item #1401642, was opened at 2006-01-10 14:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1401642&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: rbell01824 (rbell01824)
Assigned to: Nobody/Anonymous (nobody)
Summary: Win32COM policy.py unicode exceptions

Initial Comment:
Getting exceptions when catching events while
interacting with InternetExplorer.Application.

Class connects to IE via

self.ie =
DispatchWithEvents("InternetExplorer.Application",
InternetExplorerEvents)

Subsequent events on some (not all) URLs cause
exceptions as follows:

pythoncom error: Python error invoking COM method.

Traceback (most recent call last):
  File
"C:\Python24\Lib\site-packages\win32com\server\policy.py",
line 285, in _Invoke_
return self._invoke_(dispid, lcid, wFlags, args)
  File
"C:\Python24\Lib\site-packages\win32com\server\policy.py",
line 290, in _invoke_
return S_OK, -1, self._invokeex_(dispid, lcid,
wFlags, args, None, None)
  File
"C:\Python24\Lib\site-packages\win32com\server\policy.py",
line 653, in _invokeex_
args, kwArgs = self._transform_args_(args, kwArgs,
dispid, lcid, wFlags, serviceProvider)
  File
"C:\Python24\Lib\site-packages\win32com\server\policy.py",
line 648, in _transform_args_
arg = str(arg)
exceptions.UnicodeEncodeError: 'ascii' codec can't
encode character u'\xae' in position 67: ordinal not in
range(128)

URL being accessed via 

self.ie.Navigate( url )

A number of URLs lead to the behavior including the
following:

http://www.cnb.com:80/
http://www.cnb1.com:80/
http://www.charterbankcc.com:80/
http://www.charterbankec.com:80/

I can provide test code if it is helpful.



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1401642&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1401642 ] Win32COM policy.py unicode exceptions

[SourceForge.net]

Bugs item #1401642, was opened at 2006-01-10 14:34
Message generated for change (Comment added) made by rbell01824
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1401642&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: rbell01824 (rbell01824)
Assigned to: Nobody/Anonymous (nobody)
Summary: Win32COM policy.py unicode exceptions

Initial Comment:
Getting exceptions when catching events while
interacting with InternetExplorer.Application.

Class connects to IE via

self.ie =
DispatchWithEvents("InternetExplorer.Application",
InternetExplorerEvents)

Subsequent events on some (not all) URLs cause
exceptions as follows:

pythoncom error: Python error invoking COM method.

Traceback (most recent call last):
  File
"C:\Python24\Lib\site-packages\win32com\server\policy.py",
line 285, in _Invoke_
return self._invoke_(dispid, lcid, wFlags, args)
  File
"C:\Python24\Lib\site-packages\win32com\server\policy.py",
line 290, in _invoke_
return S_OK, -1, self._invokeex_(dispid, lcid,
wFlags, args, None, None)
  File
"C:\Python24\Lib\site-packages\win32com\server\policy.py",
line 653, in _invokeex_
args, kwArgs = self._transform_args_(args, kwArgs,
dispid, lcid, wFlags, serviceProvider)
  File
"C:\Python24\Lib\site-packages\win32com\server\policy.py",
line 648, in _transform_args_
arg = str(arg)
exceptions.UnicodeEncodeError: 'ascii' codec can't
encode character u'\xae' in position 67: ordinal not in
range(128)

URL being accessed via 

self.ie.Navigate( url )

A number of URLs lead to the behavior including the
following:

http://www.cnb.com:80/
http://www.cnb1.com:80/
http://www.charterbankcc.com:80/
http://www.charterbankec.com:80/

I can provide test code if it is helpful.



--

>Comment By: rbell01824 (rbell01824)
Date: 2006-01-10 15:11

Message:
Logged In: YES 
user_id=1190195

The following url reproduces multiple instances of the behavior:

http://www.clever.net/kerry/scuba/main.htm

The browser should be configured to allow popups.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1401642&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Feature Requests-1396946 ] %ehrntDRT support for time.strptime

[SourceForge.net]

Feature Requests item #1396946, was opened at 2006-01-04 16:24
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1396946&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Python Library
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Johan Dahlin (zilche)
Assigned to: Nobody/Anonymous (nobody)
Summary: %ehrntDRT support for time.strptime 

Initial Comment:
As defined in:
http://www.opengroup.org/onlinepubs/009695399/functions/strptime.html

%r -> locales representation of time + AM/PM
%e -> %d
%h -> %b
%D -> %m/%d/%y
%R -> %H:%M
%T -> %H:%M:%S
%n/%t -> whitespace

--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 20:18

Message:
Logged In: YES 
user_id=1188172

If these codes are supported in strptime, they must also be
supported in strftime. But the platform strftime is not
guaranteed to support these escapes on e.g. Windows.

I don't know if rewriting strftime in Python makes sense.

Anyhow, turning this into a feature request.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1396946&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1377858 ] segfaults when using __del__ and weakrefs

[SourceForge.net]

Bugs item #1377858, was opened at 2005-12-10 22:20
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377858&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Carl Friedrich Bolz (cfbolz)
Assigned to: Nobody/Anonymous (nobody)
Summary: segfaults when using __del__ and weakrefs

Initial Comment:
You can segfault Python by creating a weakref to an
object in its __del__ method, storing it somewhere and
then trying to dereference the weakref afterwards. the
attached file shows the described behaviour.

--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 20:29

Message:
Logged In: YES 
user_id=1188172

Added to outstanding_crashes.py.

--

Comment By: Michael Hudson (mwh)
Date: 2006-01-09 12:58

Message:
Logged In: YES 
user_id=6656

Hmm, maybe the referenced mayhem is more to do with clearing __dict__ than 
calling __del__.  What breaks if we do things in this order:

1. call __del__
2. clear weakrefs
3. clear __dict__

?

--

Comment By: Michael Hudson (mwh)
Date: 2006-01-09 12:54

Message:
Logged In: YES 
user_id=6656

Hmm, I was kind of hoping this report would get more attention.

The problem is obvious if you read typeobject.c around line 660: the weakref 
list is cleared before __del__ is called, so any weakrefs added during the 
execution of __del__ are never informed of the object's death.  One fix for 
this 
would be to clear the weakref list _after_ calling __del__ but that led to 
other 
mayhem in ways I haven't boethered to understand  (see SF bug 
#742911).  I guess we could just clear out any weakrefs created in __del__ 
without calling their callbacks.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377858&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1397850 ] libpython2.4.so get not installed

[SourceForge.net]

Bugs item #1397850, was opened at 2006-01-05 16:01
Message generated for change (Comment added) made by hajoehlers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397850&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: hajo (hajoehlers)
Assigned to: Nobody/Anonymous (nobody)
Summary: libpython2.4.so get not installed 

Initial Comment:
Given:
AIX 5.1
GCC 3.3.2
Python 2.4.2 ( Python-2.4.2.tar.gz )

./configure   \
 --enable-unicode \
 --enable-shared  \
 --with-gcc   \
 --mandir=/usr/local/man  \
 --infodir=/usr/local/info

Problem:
during " gmake install "  the libpython2.4.a will not
be installed in /usr/local/lib and the link for
libpython2.4.so does not exist then.

I did not dig further but below is the output from
"gmake install"

For me the 
...
if test -f libpython2.4.so; then ...

look wrong because it does not contain a Path and will
fail.

regards
Hajo

output during "gmake install"

...
if test -f libpython2.4.so; then \^M
if test ".so" = .dll; then \^M
/opt/freeware/bin/install -c -m 555
libpython2.4.so /usr/local/bin; \^M
else \^M
/opt/freeware/bin/install -c -m 555
libpython2.4.so /usr/local/lib/libpython2.4.a; \^M
if test libpython2.4.so !=
libpython2.4.a; then \^M
(cd /usr/local/lib; ln -sf
libpython2.4.a libpython2.4.so); \^M
fi \^M
fi; \^M
elsetrue; \^M
...


--

>Comment By: hajo (hajoehlers)
Date: 2006-01-10 21:26

Message:
Logged In: YES 
user_id=1420117

Hi Neal
if give up to test/fix the configure.in With the help from
Ulrich Berning i build a static version and convert these to
a shared one. See notes down below.

Tnx for supporting
Hajo


$ cat ./mkshared.python 

[ python-Bugs-1397205 ] no handler base classes in xml.sax

[SourceForge.net]

Bugs item #1397205, was opened at 2006-01-04 21:34
Message generated for change (Comment added) made by pterk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397205&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Alan G (abgrover)
Assigned to: Nobody/Anonymous (nobody)
Summary: no handler base classes in xml.sax

Initial Comment:
The 2.4.1 Documentation for xml.sax.handler states:

Handler implementations should inherit from the base
classes provided in the module xml.sax, so that all
methods get default implementations.

However, there are no handler base classes in xml.sax.

--

Comment By: Peter van Kampen (pterk)
Date: 2006-01-10 22:33

Message:
Logged In: YES 
user_id=174455

You need to look at xml.sax.handler.

See (bottom of)
http://www.python.org/doc/2.4.2/lib/module-xml.sax.html (See
also xml.sax.handler)

There's also a hint in xml.sax.__doc__

Python 2.4.1 (#2, May  5 2005, 11:32:06)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import xml.sax.handler
>>> dir(xml.sax.handler)
['ContentHandler', 'DTDHandler', 'EntityResolver',
'ErrorHandler', '__builtins__', '__doc__', '__file__',
'__name__', 'all_features', 'all_properties',
'feature_external_ges', 'feature_external_pes',
'feature_namespace_prefixes', 'feature_namespaces',
'feature_string_interning', 'feature_validation',
'property_declaration_handler', 'property_dom_node',
'property_encoding', 'property_interning_dict',
'property_lexical_handler', 'property_xml_string', 'version']


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397205&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1397205 ] no handler base classes in xml.sax

[SourceForge.net]

Bugs item #1397205, was opened at 2006-01-04 21:34
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397205&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Alan G (abgrover)
Assigned to: Nobody/Anonymous (nobody)
Summary: no handler base classes in xml.sax

Initial Comment:
The 2.4.1 Documentation for xml.sax.handler states:

Handler implementations should inherit from the base
classes provided in the module xml.sax, so that all
methods get default implementations.

However, there are no handler base classes in xml.sax.

--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 22:38

Message:
Logged In: YES 
user_id=1188172

Thanks, corrected the reference in rev. 42007/42008.

--

Comment By: Peter van Kampen (pterk)
Date: 2006-01-10 22:33

Message:
Logged In: YES 
user_id=174455

You need to look at xml.sax.handler.

See (bottom of)
http://www.python.org/doc/2.4.2/lib/module-xml.sax.html (See
also xml.sax.handler)

There's also a hint in xml.sax.__doc__

Python 2.4.1 (#2, May  5 2005, 11:32:06)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import xml.sax.handler
>>> dir(xml.sax.handler)
['ContentHandler', 'DTDHandler', 'EntityResolver',
'ErrorHandler', '__builtins__', '__doc__', '__file__',
'__name__', 'all_features', 'all_properties',
'feature_external_ges', 'feature_external_pes',
'feature_namespace_prefixes', 'feature_namespaces',
'feature_string_interning', 'feature_validation',
'property_declaration_handler', 'property_dom_node',
'property_encoding', 'property_interning_dict',
'property_lexical_handler', 'property_xml_string', 'version']


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397205&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1397474 ] timeit execution enviroment

[SourceForge.net]

Bugs item #1397474, was opened at 2006-01-05 04:50
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397474&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: rurpy (rurpy)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: timeit execution enviroment

Initial Comment:
library reference manual, section 10.10

The documentation for the timeit module 
does not make clear exactly what enviroment
the timed code will be run in, particularly
when a function in the current program is 
being timed (as opposed to an external 
program.)

This information is available in the examples
section but examples should illustrate already 
described behavior, not present new information.

I think the following text should be appended 
below the third paragraph in the "class Timer"
section which reads:

  To measure the execution time of the first 
  statement, use the timeit() method. The 
  repeat() method is a convenience to call 
  timeit() multiple times and return a list
  of results. 

Proposed addition:

  The timed statement is executed in the namespace
  of the timeit module.  If a function in the 
  __main__ module is being timed, it can
  be made accessible to the timer module by
  using a setup statement like 
"from __main__ import xx"
  where xx is the function's name in __main__.
  Of course "__main__" can be a different module
  name if appropriate.





--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1397474&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-927248 ] Python segfaults when freeing " deep" objects

[SourceForge.net]

Bugs item #927248, was opened at 2004-04-01 06:07
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=927248&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 6
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python segfaults when freeing "deep" objects

Initial Comment:
An example to produce this behavior:

>>> f = lambda: None
>>> for i in range(100):
... f = f.__call__
... 
>>> f = None
Segmentation fault


--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 22:54

Message:
Logged In: YES 
user_id=1188172

CVS HEAD of 2006/01/10 still segfaults (here GCC 3.4.5).

Segfault occurs at wrapper_dealloc in descrobject.c.

--

Comment By: Walter Dörwald (doerwalter)
Date: 2004-06-02 21:25

Message:
Logged In: YES 
user_id=89016

Python CVS from 2004-06-02 seems to work:
Python 2.4a0 (#5, Jun  2 2004, 20:23:30) 
[GCC 2.96 2731 (Red Hat Linux 7.3 2.96-113)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> f = lambda: None
>>> for x in xrange(100):
...  f = f.__call__
... 
>>> f

>>> f = None
>>> f
>>>

--

Comment By: Jacob Smullyan (smulloni)
Date: 2004-04-08 05:20

Message:
Logged In: YES 
user_id=108556

Python CVS as of April 7th consistently segfaults with the
above example for me:

[EMAIL PROTECTED] src $ ~/apps/python-cvs/bin/python
Python 2.4a0 (#1, Apr  7 2004, 23:10:34) 
[GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5,
propolice-3.3-7)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> f=lambda: None
>>> for x in xrange(100):
... f=f.__call__
... 
>>> f=None
Segmentation fault

Of course, maybe that's a good thing :).

--

Comment By: Jim Jewett (jimjjewett)
Date: 2004-04-05 02:32

Message:
Logged In: YES 
user_id=764593

CVS for 2.4 has comments for (and a fix for) problems similar 
to this.  Does the bug still exist with that source code?

--

Comment By: Hye-Shik Chang (perky)
Date: 2004-04-01 07:21

Message:
Logged In: YES 
user_id=55188

Oh. my patch doesn't fix another scenario that using
recursive by two or more types of slots. So I remove.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=927248&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-942706 ] Python crash on __init__/__getattr__/__setattr__ interaction

[SourceForge.net]

Bugs item #942706, was opened at 2004-04-27 01:39
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=942706&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: has (hhas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python crash on __init__/__getattr__/__setattr__ interaction

Initial Comment:
The following code causes [Mac]Python 2.3 process to crash 
(Bad!) rather than raise an error (good) when creating a new 
instance of Foo:

class Foo:
def __init__(self):
self.x = 1

def __getattr__(self, name):
if self.x:
pass # etc...

def __setattr__(self, name, val):
if self.x:
pass # etc...


(See  for a working example plus general 
solution to the referencing-instance-var-before-it's-created 
paradox that threw up this bug in the first place.)

--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 22:56

Message:
Logged In: YES 
user_id=1188172

To the OP: Is there still a crash with newest Python 2.4?

--

Comment By: Walter Dörwald (doerwalter)
Date: 2004-06-02 21:17

Message:
Logged In: YES 
user_id=89016

Assigning to self.x in __init__() calls __setattr__(), which 
checks self.x, which calls __getattr__() which checks self.x, 
which leads to endless recursion. This usually leads to 
a "RuntimeError: maximum recursion depth exceeded". In what 
way does Python 2.3 crash?

To avoid the recursion access the instance dictionary directly:
class Foo:
   def __init__(self):
  self.x = 1

   def __getattr__(self, name):
  if "x" in self.__dict__ and self.__dict__["x"]:
 pass # etc...

   def __setattr__(self, name, val):
  if self.x:
 pass # etc...


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=942706&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-931877 ] Segfault in object_reduce_ex

[SourceForge.net]

Bugs item #931877, was opened at 2004-04-08 19:46
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=931877&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Segfault in object_reduce_ex

Initial Comment:
Shane Hathaway bumped into this, unbounded recursion 
in typeobject.c's object_reduce_ex().  This occurs in 
Python 2.3.3 and current CVS.

Assigned to Guido, to ponder whether object_reduce_ex 
is doing what it should; if it is (which seems likely to 
me), I suppose we need to inject a recursion counter to 
prevent the segfault.

The failing case is short, but I'll attach it (temp99.py) to 
avoid SF line mangling.  While the test uses pickle, same 
symptom if it's changed to use cPickle instead.

Jim Fulton's analysis:

"""
This is a very clever infinite loop.  The proxy doesn't
actually proxy, but it does manage to confuse reduce 
about what's going on.

reduce tries to figure out if it has been overridden by
asking whether the class's reduce is the same as
object.__reduce__. It doesn't expect to be lied to
about the class.  Things wouldn't have been so bad if
the proxy had proxied __reduce__ as well as __class__.
"""

The priority hasn't been bumped, because "the real 
code" from which this was whittled down wasn't doing 
what it needed to do anyway, and the recursion went 
away when the real code was repaired.

--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 22:58

Message:
Logged In: YES 
user_id=1188172

Still crashing with 2.5...

--

Comment By: Nathan Srebro (nati)
Date: 2004-11-30 02:26

Message:
Logged In: YES 
user_id=63133

This infinite recursion also occurs in another place, that
got me stumped for a couple of days when old code that
worked with Python 2.2 stopped working.  If __class__ is not
fidgeted with (as in original bug report), but a descriptor
returns a custom reduce for the class, but not for its
objects, reduce enters an infinite loop on the object:

"""
class descriptor_for_reduce(object):
def __get__(self,obj,tp=None):
if obj is not None: return
super(ASpecialClass,obj).__reduce__
return self.reducer
def reducer(self,proto=None):
return "VerySpecial"

class ASpecialClass(object):
__reduce__ = descriptor_for_reduce()

copy.copy(ASpecialClass())
"""

ASpecialClass().__reduce__ is object.__reduce__, which is
implemented by typeobject.c:object_reduce_ex.  This function
(that doesn't know if its called as the __reduce__ or the
__reduce_ex__ method) tries to detect if the object's
__reduce__ is overridden.  It does so by checking if the
object's class's __reduce__ is overridden, and in fact it
is.  It then assumes that the object's __reduce__ is
overridden, and calls it.  But the object's __reduce__ is
the same function, causing the infinite loop.

If __reduce_ex__ is used instead of __reduce__, the problem
goes away, ASpecialClass().__reduce_ex__() return the usual
tuple, and ASpecialClass.__reduce_ex__() return
"VerySpecial".  But when __reduce__ is overridden,
ASpecialClass().__reduce__() enters an infinite loop.

I believe this is a legitimate example that should behave
just as when __reduce_ex__ is overridden.  The example
doesn't lie about __class__, and it is certainly legitimate
for define a property that behaves differently for the class
and for its objects.

Where did this come up and why would I ever care about a
class's __reduce__?  The __reduce__ attribute of a class is
never used by (the standard) pickle or copy, since
save_global() is called instead. However, I have a custom
pickler, implemented as a subclass of pickle.Pickler, which
falls back on the class's __reduce__ when save_global()
fails.  This way, I can pickle certain classes that are
created at run-time (and can be easily recreated, e.g. from
their bases and dictionaries).


--

Comment By: Tim Peters (tim_one)
Date: 2004-04-08 19:51

Message:
Logged In: YES 
user_id=31435

Hmm!  The temp99.py download link doesn't work for me.  
Here's the content in case it doesn't work for others either:

"""
import cPickle as pickle
from pickle import dumps

class SimpleItem:
def __reduce__(self):
return (self.__class__, None, {})

class Proxy(object):
__class__ =  property(lambda self: self.__target.__class__)

def __init__(self, target):
self.__target = target

def __getstate__(self):
raise RuntimeError("No don't pickle me!  Aa

[ python-Bugs-983311 ] simple attribute access causing segfault in certain cases

[SourceForge.net]

Bugs item #983311, was opened at 2004-07-01 11:42
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983311&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Simon Michael (simon)
Assigned to: Nobody/Anonymous (nobody)
Summary: simple attribute access causing segfault in certain cases

Initial Comment:
Reproduce:

 zopectl debug (done in zope debugger to get necessary
imports)
 >>> from AccessControl.tests.testSecurity import
SecurityTests
 >>> SecurityTests.doc_class

Python 2.3.4 crashes silently. Python 2.3.3 works
normally on the same machine. This is some virtual
server variant of debian gnu/linux on intel
(aktiom.net. On another machine (standard debian i386)
Python 2.3.3 shows the same crash.

That attr in
zope/lib/python/AccessControl/tests/testSecurity.py
looks like:

 class SecurityTests (DTMLTests):
 doc_class = UnownedDTML # another class

Cf http://zwiki.org/IssueNo0860 .

--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 23:00

Message:
Logged In: YES 
user_id=1188172

I think yes.

--

Comment By: Michael Hudson (mwh)
Date: 2004-07-14 10:56

Message:
Logged In: YES 
user_id=6656

Uh, there seems little chance this is a Python core bug.  Can we 
close this report?

--

Comment By: Andy Dustman (adustman)
Date: 2004-07-13 22:02

Message:
Logged In: YES 
user_id=71372

This may or may not be related: I've had scattered reports
of people having trouble with attribute access (maybe) with
MySQLdb-1.0.0 on Python-2.3.4 (and maybe 2.3.3 but not 2.2)
on *BSD and Mac OS X, but I can't reproduce it on Linux
(x86) with 2.3.4. One person is getting a segfault upon
import (this is not in the bug listed below); I am trying to
get a gdb backtraces.

https://sourceforge.net/tracker/index.php?func=detail&aid=970667&group_id=22307&atid=374932


--

Comment By: Simon Michael (simon)
Date: 2004-07-13 21:33

Message:
Logged In: YES 
user_id=572

See also discussion at http://collector.zope.org/Zope/1395

--

Comment By: Armin Rigo (arigo)
Date: 2004-07-01 22:21

Message:
Logged In: YES 
user_id=4771

What I mean here is that you should report this bug to Zope, not to Python, 
unless there is a good reason to suspect that a bug in the Python core is 
causing it.  But to me it really looks like a bug in the Zope extension module, 
which for some reason shows up only with some version of Python or on some 
platform.

--

Comment By: Simon Michael (simon)
Date: 2004-07-01 21:25

Message:
Logged In: YES 
user_id=572

UnownedDTML is indeed a zope extension class.

--

Comment By: Armin Rigo (arigo)
Date: 2004-07-01 17:20

Message:
Logged In: YES 
user_id=4771

If this bug involves C extension modules specific to Zope
then I'd first consider it as a bug in one of these modules.
 I would be particularly suspicious that this is the case in
a file called testSecurity: isn't its goal to check some
C-implemented security feature of Zope?

If I am wrong please try to provide a Python code sample. 
Reading a class attribute out of some class tends to work
just fine.

--

Comment By: Andreas Jung (ajung)
Date: 2004-07-01 12:34

Message:
Logged In: YES 
user_id=11084

Works for me with Python 2.3.3/4 on three different Linux
systems.


--

Comment By: Simon Michael (simon)
Date: 2004-07-01 11:52

Message:
Logged In: YES 
user_id=572

> Python 2.3.3 works normally on the same machine.

I meant:  Python 2.3.3 works normally on another, similar
machine (virtual linux host).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983311&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-600007 ] Another dealloc stack killer

[SourceForge.net]

Bugs item #67, was opened at 2002-08-26 03:37
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=67&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 3
Submitted By: Tim Peters (tim_one)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Another dealloc stack killer

Initial Comment:
>From c.l.py:

"""
From: Pavel Pergamenshchik <[EMAIL PROTECTED]>
Sent: Sunday, August 25, 2002 9:17 PM
To: python-list@python.org
Subject: Python 2.2.1 bug

I found a way to break Python 2.2.1 (at least) both on 
Linux and Windows.
...

eval("int" + ".__call__"*10)

at the prompt, then press ctrl-D or ctrl-Z to edit. This 
will result in a segfault on Linux and some 
weird "unknown software exception" thing on Windows.
"""

At shutdown, the C stack is blown by a very deep 
nest of

_Py_Dealloc
wrapper_dealloc

calls.  That was under current CVS head; I'm sure it's 
the same deal in 2.2.

--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 23:02

Message:
Logged In: YES 
user_id=1188172

Duplicate of #927248.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-08-29 01:30

Message:
Logged In: YES 
user_id=33168

The threshold was 30 for me on Linux.

--

Comment By: Tim Peters (tim_one)
Date: 2002-08-26 16:06

Message:
Logged In: YES 
user_id=31435

I suppose you need to reduce your stack limit, or boost the 
multiplier, then.  I would agree it's hard to get excited 
about this one .

--

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-26 15:56

Message:
Logged In: YES 
user_id=6380

Hm, I cannot reproduce this on Linux, with either the
2.2maintenance branch or 2.3. I trust that it's a problem
though. Reducing priority.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=67&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-927248 ] Python segfaults when freeing " deep" objects

[SourceForge.net]

Bugs item #927248, was opened at 2004-03-31 23:07
Message generated for change (Comment added) made by kuran
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=927248&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python segfaults when freeing "deep" objects

Initial Comment:
An example to produce this behavior:

>>> f = lambda: None
>>> for i in range(100):
... f = f.__call__
... 
>>> f = None
Segmentation fault


--

>Comment By: Jp Calderone (kuran)
Date: 2006-01-10 17:05

Message:
Logged In: YES 
user_id=366566

Note that in doerwalter transcript, _ is still bound to the
method wrapper, preventing Python from attempting to free it.


--

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 16:54

Message:
Logged In: YES 
user_id=1188172

CVS HEAD of 2006/01/10 still segfaults (here GCC 3.4.5).

Segfault occurs at wrapper_dealloc in descrobject.c.

--

Comment By: Walter Dörwald (doerwalter)
Date: 2004-06-02 15:25

Message:
Logged In: YES 
user_id=89016

Python CVS from 2004-06-02 seems to work:
Python 2.4a0 (#5, Jun  2 2004, 20:23:30) 
[GCC 2.96 2731 (Red Hat Linux 7.3 2.96-113)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> f = lambda: None
>>> for x in xrange(100):
...  f = f.__call__
... 
>>> f

>>> f = None
>>> f
>>>

--

Comment By: Jacob Smullyan (smulloni)
Date: 2004-04-07 23:20

Message:
Logged In: YES 
user_id=108556

Python CVS as of April 7th consistently segfaults with the
above example for me:

[EMAIL PROTECTED] src $ ~/apps/python-cvs/bin/python
Python 2.4a0 (#1, Apr  7 2004, 23:10:34) 
[GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5,
propolice-3.3-7)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> f=lambda: None
>>> for x in xrange(100):
... f=f.__call__
... 
>>> f=None
Segmentation fault

Of course, maybe that's a good thing :).

--

Comment By: Jim Jewett (jimjjewett)
Date: 2004-04-04 20:32

Message:
Logged In: YES 
user_id=764593

CVS for 2.4 has comments for (and a fix for) problems similar 
to this.  Does the bug still exist with that source code?

--

Comment By: Hye-Shik Chang (perky)
Date: 2004-04-01 00:21

Message:
Logged In: YES 
user_id=55188

Oh. my patch doesn't fix another scenario that using
recursive by two or more types of slots. So I remove.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=927248&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1043446 ] Uninterruptable loop

[SourceForge.net]

Bugs item #1043446, was opened at 2004-10-09 06:26
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1043446&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 3
Submitted By: Jp Calderone (kuran)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Uninterruptable loop

Initial Comment:
import itertools
list(itertools.repeat('x'))

^C will not interrupt this.


--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 23:15

Message:
Logged In: YES 
user_id=1188172

What to do here?

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-10-16 00:25

Message:
Logged In: YES 
user_id=593130

Killing the interpreter will, of course, interrupt anything ;-).

The ability to ask the interpreter, via an alternate non-code 
communication channel, to stop doing what one just 
requested via the normal code input channel,  is an 
implementation-specific metafeature independent of the 
language definition.  So I see this as a CPython feature-
expansion request rather than a bug report.

If the CPython interpreter documentation promises that ^C 
or whatever will always grab the interpreter's attention, then 
that overpromise is a bug that should be modified.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-10-10 10:06

Message:
Logged In: YES 
user_id=80475

FWIW, there are many variations of this theme using almost
anything accepting an iterable input (dict.fromkeys, tuple,
set, etc) paired with any long running or infinite iterator
(itertools.count, xrange(sys.maxint), etc).  Even the
tp_print slot can get caught up in emitting oversized output
in a way that is uninterruptable.

I don't see a clean way of teaching all of these functions
to periodically check for signals, and either handle them,
raise an exception or continue.   Fixing this could muck-up
and complicate a bunch of otherwise clean code.  

Still, it would be nice if everything were interruptable. 
I'm just not sure it's worth it.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1043446&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-830261 ] __mul__ taken as __rmul__ for mul-by-int only

[SourceForge.net]

Bugs item #830261, was opened at 2003-10-25 23:57
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=830261&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex Martelli (aleax)
Assigned to: Nobody/Anonymous (nobody)
Summary: __mul__ taken as __rmul__ for mul-by-int only

Initial Comment:
Tiniest way to reproduce:
>>> class X(object):
...   def __mul__(self, other): return '%r???' % other
...
>>> x=X()
>>> 23*x
'23???'
>>> 2.3*x
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: can't multiply sequence to non-int
>>>

weird error message hints at cause: Objects/typeobject.c sets sq_repeat slot 
indifferently for both __mul__ AND __rmul__, then Objects/abstract.c function 
PyNumber_Multiply checks both operands for sq_repeats, finds it in the RHO and 
thus calls
sequence_repeat which erroneously succeeds when the LHO
is 23 and fails w/weird error message when it's 2.3.

I'm leaving this unassigned because it's anything but obvious to me what the 
fix should be!  If anybody HAS obvious fixes to
suggest I'll be glad to implement and commit them, though.

--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 23:20

Message:
Logged In: YES 
user_id=1188172

This appears to be fixed in 2.5 HEAD, but not in the 2.4 branch.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=830261&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-908441 ] default index for __getslice__ is not sys.maxint

[SourceForge.net]

Bugs item #908441, was opened at 2004-03-02 18:41
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=908441&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Drochner (drochner)
Assigned to: Nobody/Anonymous (nobody)
Summary: default index for __getslice__ is not sys.maxint

Initial Comment:
(This applies also to __setslice__ and possibly more.)
(This was already present in Python-2.2.)

If the upper slice index is omitted, a default is
passed to the __getslice__ method.
Documentation claims this is sys.maxint.
This is wrong if INT_MAX and LONG_MAX differ; what
is passed is INT_MAX while sys.maxint is LONG_MAX.

I'm not sure whether to call it a code bug or a
documentation bug; at least there is code out there
which compares to sys.maxint.

The whole code path from ceval.c:_PyEval_SliceIndex()
to operator.c:op_getslice() to 
abstract.c:PySequence_GetSlice() to
classobject.c:instance_slice() has just room for
an "int", so a code fix is pretty invasive...

A small test program to check this:
==
import sys

class sl(object):
def __getslice__(self, a, b):
return (a, b)

print "sys.maxint = %ld" % sys.maxint
bounds = sl()[:]
print "default bounds = [%ld, %ld]" % bounds
==
gives on NetBSD/amd64:
sys.maxint = 9223372036854775807
default bounds = [0, 2147483647]



--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 23:20

Message:
Logged In: YES 
user_id=1188172

Do we want to support long slice indices?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=908441&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-837242 ] id() for large ptr should return a long

[SourceForge.net]

Bugs item #837242, was opened at 2003-11-06 16:11
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: id() for large ptr should return a long

Initial Comment:
Under something like Redhat 10 the address space is
messed about with to "prevent stack smash attacks" or
some such. This means that you sometimes get addresses
in the high half of a 32 bit int. Since Python ints are
signed, this means we return a negative number from
id(). For 2.4, we should probably return a long. 

--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 23:21

Message:
Logged In: YES 
user_id=1188172

Perhaps, for 2.5?

--

Comment By: Martin v. Löwis (loewis)
Date: 2003-11-06 21:54

Message:
Logged In: YES 
user_id=21627

Would there anything be wrong with making that change right
away?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-890010 ] Odd warning behaviors

[SourceForge.net]

Bugs item #890010, was opened at 2004-02-03 23:25
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890010&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Jeremy Hylton (jhylton)
Summary: Odd warning behaviors

Initial Comment:
This is from Evan Simpson, on the zope-dev list.  The 
bulk have to do with what happens if __name__ is set to 
None:


Subject: Re: [Zope-dev] Re: Zope 2.7.0 rc2 + python 
2.3.3 problem
http://mail.zope.org/mailman/listinfo/zope-dev

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> range(1.0)
__main__:1: DeprecationWarning: integer argument 
expected, got float
[0]
 >>>

So far, so good.  However:

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> __name__=None
 >>> range(1.0)
[]
 >>> 1+1
Traceback (most recent call last):
   File "/usr/lib/python2.3/warnings.py", line 57, in warn
 warn_explicit(message, category, filename, lineno, 
module, registry)
   File "/usr/lib/python2.3/warnings.py", line 63, in 
warn_explicit
 if module[-3:].lower() == ".py":
TypeError: unsubscriptable object
 >>>

...and...

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> import warnings
 >>> warnings.simplefilter("error", 
category=DeprecationWarning)
 >>> range(1.0)
[]
 >>> 1+1
Traceback (most recent call last):
   File "/usr/lib/python2.3/warnings.py", line 57, in warn
 warn_explicit(message, category, filename, lineno, 
module, registry)
   File "/usr/lib/python2.3/warnings.py", line 92, in 
warn_explicit
 raise message
DeprecationWarning: integer argument expected, got 
float
 >>>

...and...

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> import pdb
 >>> __name__ = None
 >>> pdb.run('range(1.0)')
 > (1)?()
(Pdb) s
--Call--
 > /usr/lib/python2.3/warnings.py(24)warn()
-> def warn(message, category=None, stacklevel=1):
(Pdb) r
--Return--
/usr/lib/python2.3/bdb.py:302: RuntimeWarning: 
tp_compare didn't return 
-1 or -2 for exception
   i = max(0, len(stack) - 1)
[traceback snipped]

Looks like something isn't properly propagating 
exceptions.

Cheers,

Evan @ 4-am


--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 23:28

Message:
Logged In: YES 
user_id=1188172

In current SVN heads, range(1.0) gives DeprecationWarning and 
__name__=None; range(1.0) gives TypeError.

Is this okay?

--

Comment By: Tim Peters (tim_one)
Date: 2004-02-17 01:51

Message:
Logged In: YES 
user_id=31435

I'm listening, but with half of part of one ear.  Have to agree 
convertsimple() was wrong in these cases, but can't make 
time for more than that.  Reassigned to Jeremy, partly at 
random (his is one of the names that shows up as a recent 
getargs.c changer).

--

Comment By: Michael Hudson (mwh)
Date: 2004-02-12 15:09

Message:
Logged In: YES 
user_id=6656

Is anyone listening?

--

Comment By: Michael Hudson (mwh)
Date: 2004-02-04 16:05

Message:
Logged In: YES 
user_id=6656

Oops, wrong file.

--

Comment By: Michael Hudson (mwh)
Date: 2004-02-04 16:03

Message:
Logged In: YES 
user_id=6656

How's this?  It's horrible, but I'm not sure that can be avoided.

--

Comment By: Michael Hudson (mwh)
Date: 2004-02-04 14:22

Message:
Logged In: YES 
user_id=6656

OK, the problem is that returning NULL from 
getargs.c:convertsimple indicates *success* (argh!).

Fixing that provokes weird errors from handle_range_longs.

--

Comment By: Michael Hudson (mwh)
Date: 2004-02-04 13:10

Message:
Logged In: YES 
user_id=6656

Might this be specific to range()?

[EMAIL PROTECTED] build]$ ./python.exe -Werror
Python 2.4a0 (#3, Feb  3 2004, 19:23:25) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> range(5.0)

[ python-Bugs-871026 ] PyOS_snprintf segfaults on missing native snprintf

[SourceForge.net]

Bugs item #871026, was opened at 2004-01-05 17:37
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=871026&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Federico Di Gregorio (fog)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyOS_snprintf segfaults on missing native snprintf

Initial Comment:
On architectures missing a native snprintf (checked on
win32 + Borland), PyOS_snprintf may cause a segfault
when passed a string argument (%s) larger than 512 bytes. 

Btw, allocating an extra 512 bytes and hoping for the
best while calling native vsprintf is also a security
risk (due to buffer overruns.)


--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 23:42

Message:
Logged In: YES 
user_id=1188172

Another year passed (almost), so this can be closed?

--

Comment By: Tim Peters (tim_one)
Date: 2004-03-22 05:26

Message:
Logged In: YES 
user_id=31435

Nick, Python already uses _snprintf and _vsnprintf under 
MSVC on Windows.  The OP said he tried using Borland on 
Windows, which presumably lacks them (Borland has its own 
runtime libraries, and do note that these things are not part 
of the Win32 API, they're part of the compiler-specific C 
runtime library).

Since snprintf and vsnprintf are required by both POSIX and 
the C99 standard, and are supplied (albeit with a goofy 
spelling, and non-standard endcase behavior) by MSVC, the 
number of platforms they're not available on is both small and 
shrinking.  I doubt any current Python developer uses such a 
platform, so if the OP doesn't care enough to volunteer a 
patch either, we should acknowledge reality and close this as 
WontFix.  (The OP could still ask Borland to modernize their C 
offering, of course -- if Borland is falling behind the times, it's 
not really Python's problem to write a modern C library for 
them.)

--

Comment By: Nick Bastin (mondragon)
Date: 2004-03-22 04:39

Message:
Logged In: YES 
user_id=430343

Win32 actually *does* have snprintf, but like most functions added to the 
C standard later in life, it's implemented as _snprintf().  Really, it seems 
that the autoconf rule needs to be smarter than just checking for 
snprintf, but rather needs to redefine snprintf as _snprintf on platforms 
that have _snprintf.

Of course, the implementation of PyOS_snprintf still needs fixing.

--

Comment By: Federico Di Gregorio (fog)
Date: 2004-01-05 22:12

Message:
Logged In: YES 
user_id=10245

Yes, it causes a segfault when a module using PyOS_snprintf
passes it a string that is bigger than the buffer length +
512. This happens because first vsprintf is called with a
too small buffer and the stack is corrupted and then (too
late!)  there is the check and the fatal error.
Py_FatalError is called (maybe) but the return address is
gone from the stack and all you get is a segfault at the end
of the function.

I know PyOS_snprintf is internal but it can be used by
extension modules and (anyway) growing a buffer 512 bytes
statically is almost the same as using sprintf (without the
'n') directly.


--

Comment By: Tim Peters (tim_one)
Date: 2004-01-05 18:01

Message:
Logged In: YES 
user_id=31435

Does it really cause a segfault?  This code is trying to cause 
Py_FatalError instead in that case:

else if ((size_t)len >= size + 512)
Py_FatalError("Buffer overflow in 
PyOS_snprintf/PyOS_vsnprintf");

If that part isn't working, that is indeed a bug.

WRT security, PyOS_snprintf is an internal API function -- 
programs written in Python can't invoke it directly.  If a 
(necessarily) internal use of the function triggers this case, 
that's an error in the coding of the internals, but the *intent* 
is that Py_FatalError() get invoked then anyway, which 
immediately kills the Python process (via C abort()).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=871026&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1401642 ] Win32COM policy.py unicode exceptions

[SourceForge.net]

Bugs item #1401642, was opened at 2006-01-10 15:34
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1401642&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
>Group: 3rd Party
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: rbell01824 (rbell01824)
Assigned to: Nobody/Anonymous (nobody)
Summary: Win32COM policy.py unicode exceptions

Initial Comment:
Getting exceptions when catching events while
interacting with InternetExplorer.Application.

Class connects to IE via

self.ie =
DispatchWithEvents("InternetExplorer.Application",
InternetExplorerEvents)

Subsequent events on some (not all) URLs cause
exceptions as follows:

pythoncom error: Python error invoking COM method.

Traceback (most recent call last):
  File
"C:\Python24\Lib\site-packages\win32com\server\policy.py",
line 285, in _Invoke_
return self._invoke_(dispid, lcid, wFlags, args)
  File
"C:\Python24\Lib\site-packages\win32com\server\policy.py",
line 290, in _invoke_
return S_OK, -1, self._invokeex_(dispid, lcid,
wFlags, args, None, None)
  File
"C:\Python24\Lib\site-packages\win32com\server\policy.py",
line 653, in _invokeex_
args, kwArgs = self._transform_args_(args, kwArgs,
dispid, lcid, wFlags, serviceProvider)
  File
"C:\Python24\Lib\site-packages\win32com\server\policy.py",
line 648, in _transform_args_
arg = str(arg)
exceptions.UnicodeEncodeError: 'ascii' codec can't
encode character u'\xae' in position 67: ordinal not in
range(128)

URL being accessed via 

self.ie.Navigate( url )

A number of URLs lead to the behavior including the
following:

http://www.cnb.com:80/
http://www.cnb1.com:80/
http://www.charterbankcc.com:80/
http://www.charterbankec.com:80/

I can provide test code if it is helpful.



--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 23:49

Message:
Logged In: YES 
user_id=1188172

Since it's a problem with the win32 extensions which aren't
part of the official Python distribution, please report this
to ActiveState or the Pywin32 maintainer.

--

Comment By: rbell01824 (rbell01824)
Date: 2006-01-10 16:11

Message:
Logged In: YES 
user_id=1190195

The following url reproduces multiple instances of the behavior:

http://www.clever.net/kerry/scuba/main.htm

The browser should be configured to allow popups.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1401642&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1394135 ] Deleting first item causes anydbm.first() to fail

[SourceForge.net]

Bugs item #1394135, was opened at 2005-12-31 05:24
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394135&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Bisalputra (danbiz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Deleting first item causes anydbm.first() to fail

Initial Comment:
If the first item in a database is deleted, the first
call to anydbm.first() after the deletion causes a
DBNotFoundError exception to be raised.

The attached program causes the error on my system.  I
am currently working around the problem by calling
first() after each deletion, enclosed by a try block.

I am using Python 2.4.2 running under Windows ME.

--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 23:50

Message:
Logged In: YES 
user_id=1188172

Confirmed here (Linux, various Pythons).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394135&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-687648 ] classic division in demos/ directory

[SourceForge.net]

Bugs item #687648, was opened at 2003-02-16 23:27
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687648&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Demos and Tools
Group: Not a Bug
Status: Open
Resolution: None
>Priority: 4
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
Summary: classic division in demos/ directory

Initial Comment:
PEP 238 states:

 - The standard library will use the future
division statement and
   the // operator when appropriate, so as to
completely avoid
   classic division.

  While the demos/ directory is not technically part of
the standard library, it does contain code that should
work, and that newbies may examine in the course of
learning Python.  Python source there should follow the
same rules as anyplace else.

  I'll volunteer to make the changes and submit a
patch, if it is agreed that the changes should indeed
be made.


--

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-22 09:59

Message:
Logged In: YES 
user_id=80475

Is this still open or is there a patch forthcoming?

--

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-23 14:48

Message:
Logged In: YES 
user_id=6380

Excellent.  I hope you'll try to also make a judgement (at
least in some cases) whether a particular piece of demo code
is still relevant -- there is unfortunately a lot of stale
demo code.

Also see if there are other kinds of modernization that
could be done (see PEP 290).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687648&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-871026 ] PyOS_snprintf segfaults on missing native snprintf

[SourceForge.net]

Bugs item #871026, was opened at 2004-01-05 11:37
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=871026&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
>Group: 3rd Party
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Federico Di Gregorio (fog)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyOS_snprintf segfaults on missing native snprintf

Initial Comment:
On architectures missing a native snprintf (checked on
win32 + Borland), PyOS_snprintf may cause a segfault
when passed a string argument (%s) larger than 512 bytes. 

Btw, allocating an extra 512 bytes and hoping for the
best while calling native vsprintf is also a security
risk (due to buffer overruns.)


--

>Comment By: Tim Peters (tim_one)
Date: 2006-01-10 17:54

Message:
Logged In: YES 
user_id=31435

Indeed, nine months is long enough to make a baby, so
closing this as 3rdParty + WontFix.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 17:42

Message:
Logged In: YES 
user_id=1188172

Another year passed (almost), so this can be closed?

--

Comment By: Tim Peters (tim_one)
Date: 2004-03-21 23:26

Message:
Logged In: YES 
user_id=31435

Nick, Python already uses _snprintf and _vsnprintf under 
MSVC on Windows.  The OP said he tried using Borland on 
Windows, which presumably lacks them (Borland has its own 
runtime libraries, and do note that these things are not part 
of the Win32 API, they're part of the compiler-specific C 
runtime library).

Since snprintf and vsnprintf are required by both POSIX and 
the C99 standard, and are supplied (albeit with a goofy 
spelling, and non-standard endcase behavior) by MSVC, the 
number of platforms they're not available on is both small and 
shrinking.  I doubt any current Python developer uses such a 
platform, so if the OP doesn't care enough to volunteer a 
patch either, we should acknowledge reality and close this as 
WontFix.  (The OP could still ask Borland to modernize their C 
offering, of course -- if Borland is falling behind the times, it's 
not really Python's problem to write a modern C library for 
them.)

--

Comment By: Nick Bastin (mondragon)
Date: 2004-03-21 22:39

Message:
Logged In: YES 
user_id=430343

Win32 actually *does* have snprintf, but like most functions added to the 
C standard later in life, it's implemented as _snprintf().  Really, it seems 
that the autoconf rule needs to be smarter than just checking for 
snprintf, but rather needs to redefine snprintf as _snprintf on platforms 
that have _snprintf.

Of course, the implementation of PyOS_snprintf still needs fixing.

--

Comment By: Federico Di Gregorio (fog)
Date: 2004-01-05 16:12

Message:
Logged In: YES 
user_id=10245

Yes, it causes a segfault when a module using PyOS_snprintf
passes it a string that is bigger than the buffer length +
512. This happens because first vsprintf is called with a
too small buffer and the stack is corrupted and then (too
late!)  there is the check and the fatal error.
Py_FatalError is called (maybe) but the return address is
gone from the stack and all you get is a segfault at the end
of the function.

I know PyOS_snprintf is internal but it can be used by
extension modules and (anyway) growing a buffer 512 bytes
statically is almost the same as using sprintf (without the
'n') directly.


--

Comment By: Tim Peters (tim_one)
Date: 2004-01-05 12:01

Message:
Logged In: YES 
user_id=31435

Does it really cause a segfault?  This code is trying to cause 
Py_FatalError instead in that case:

else if ((size_t)len >= size + 512)
Py_FatalError("Buffer overflow in 
PyOS_snprintf/PyOS_vsnprintf");

If that part isn't working, that is indeed a bug.

WRT security, PyOS_snprintf is an internal API function -- 
programs written in Python can't invoke it directly.  If a 
(necessarily) internal use of the function triggers this case, 
that's an error in the coding of the internals, but the *intent* 
is that Py_FatalError() get invoked then anyway, which 
immediately kills the Python process (via C abort()).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=871026&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mai

[ python-Bugs-992207 ] exec statement balks at CR/LF

[SourceForge.net]

Bugs item #992207, was opened at 2004-07-16 11:21
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992207&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Konrad Hinsen (hinsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: exec statement balks at CR/LF

Initial Comment:
Under Linux and MacOS (no others tested), if "foo.py" is a DOS/
Windows style Python file (CR/LF line endings), then

  python foo.py

will work, as will

  execfile("foo.py")

and

  exec file("foo.py")

from inside Python. However,

   exec file("foo.py").read()

will report a syntax error. In other words, the parser seems to 
accept CR/LF only if the source of the data is a file, not a string.

When running under Linux and MacOS (no others tested), the exec 
statement reports a syntax error. I didn't find anything about this 
in the documentation, so I don't know if it's a bug or a feature. If 
it's a feature, it is not a useful one!



--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 23:57

Message:
Logged In: YES 
user_id=1188172

I'm not sure this is a bug.

Is exec supposed to accept code in crlf-terminated strings?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992207&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1105770 ] null source chars handled oddly

[SourceForge.net]

Bugs item #1105770, was opened at 2005-01-20 08:35
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105770&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Reginald B. Charney (rcharney)
Assigned to: Nobody/Anonymous (nobody)
Summary: null source chars handled oddly

Initial Comment:
When null characters appear in the source, outside
literals, tokenize seems to either: skip the null
character and the next two following characters; or
ignore the remainder of the line, including the newline
character.

(To see the invalid characters, use vim, or an editor
that displays control characters when needed.)

--

>Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-11 00:07

Message:
Logged In: YES 
user_id=1188172

Confirmed with current SVN heads.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105770&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1105770 ] null source chars handled oddly

[SourceForge.net]

Bugs item #1105770, was opened at 2005-01-20 08:35
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105770&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: None
>Status: Open
Resolution: None
Priority: 5
Submitted By: Reginald B. Charney (rcharney)
Assigned to: Nobody/Anonymous (nobody)
Summary: null source chars handled oddly

Initial Comment:
When null characters appear in the source, outside
literals, tokenize seems to either: skip the null
character and the next two following characters; or
ignore the remainder of the line, including the newline
character.

(To see the invalid characters, use vim, or an editor
that displays control characters when needed.)

--

Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-11 00:07

Message:
Logged In: YES 
user_id=1188172

Confirmed with current SVN heads.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105770&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1402308 ] segfault when using mmap(-1,...) [+PATCH]

[SourceForge.net]

Bugs item #1402308, was opened at 2006-01-11 00:38
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1402308&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralf Schmitt (titty)
Assigned to: Nobody/Anonymous (nobody)
Summary: segfault when using mmap(-1,...) [+PATCH]

Initial Comment:
This is happening on OSX, Python 2.4.2:

[EMAIL PROTECTED]:~/Python-2.4.2$ cat ~/t.py
#! /usr/bin/env python
import sys
print sys.version

import mmap

mmap.mmap(-1, 4096)
[EMAIL PROTECTED]:~/Python-2.4.2$ ./python ~/t.py
2.4.2 (#1, Jan 11 2006, 00:58:35) 
[GCC 4.0.1 (Apple Computer, Inc. build 5247)]
Segmentation fault


The following one line diff solves that problem (mmap's data member 
is otherwise uninitialized...)

[EMAIL PROTECTED]:~/Python-2.4.2$ diff -u Modules/mmapmodule.c-orig 
Modules/mmapmodule.c--- Modules/mmapmodule.c-orig   
2006-01-11 01:12:32.0 +0100
+++ Modules/mmapmodule.c2006-01-11 01:13:06.0 
+0100
@@ -910,6 +910,7 @@
 #endif
m_obj = PyObject_New (mmap_object, &mmap_object_type);
if (m_obj == NULL) {return NULL;}
+   m_obj->data = NULL;
m_obj->size = (size_t) map_size;
m_obj->pos = (size_t) 0;
m_obj->fd = dup(fd);




However, the problem is that passing -1 as filedescriptor to mmap
is perfectly ok when one wants to mmap anonymous memory (at least 
on FreeeBSD and OS X). The following patch also solves that problem.
[mmap.mmap(-1, 4096, mmap.MAP_ANON) now works...]
Any chance to get this included? Passing -1 to mmap should not hurt 
anybody, as systems which do not support it, should then return an 
error from mmap. 

[EMAIL PROTECTED]:~/Python-2.4.2$ diff -u Modules/mmapmodule.c-orig 
Modules/mmapmodule.c--- Modules/mmapmodule.c-orig   
2006-01-11 01:12:32.0 +0100
+++ Modules/mmapmodule.c2006-01-11 01:23:52.0 
+0100
@@ -910,10 +910,12 @@
 #endif
m_obj = PyObject_New (mmap_object, &mmap_object_type);
if (m_obj == NULL) {return NULL;}
+   m_obj->data = NULL;
m_obj->size = (size_t) map_size;
m_obj->pos = (size_t) 0;
-   m_obj->fd = dup(fd);
-   if (m_obj->fd == -1) {
+   if (fd == -1) {
+   m_obj->fd = -1;
+   } else if ((m_obj->fd = dup(fd)) == -1) {
Py_DECREF(m_obj);
PyErr_SetFromErrno(mmap_module_error);
return NULL;


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1402308&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com