[ python-Bugs-1170766 ] weakref.proxy incorrect behaviour

[SourceForge.net]

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

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Kozlovsky (kozlovsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: weakref.proxy incorrect behaviour

Initial Comment:
According documentation, proxy in most contexts must 
have the same behaviour as object itself.

PROBLEM:

bool(proxy_object) != bool(object_itself)

EXAMPLE:

>>> class X(list): pass # collection class
... 
>>> x = X() # empty collection
>>> import weakref
>>> proxy = weakref.proxy(x)
>>> bool(x)
False
>>> bool(proxy)
True

PYTHON VERSION:

2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit 
(Intel)]

also tested on:

2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit 
(Intel)]

--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-27 06:17

Message:
Logged In: YES 
user_id=80475

Fixed the __nonzero__ problem for Py2.5 and will backport to
Py2.4.  See Objects/weakrefobject.c 1.21.

Leaviing this report open until the rest of the module can
be checked and fixed.



--

Comment By: Armin Rigo (arigo)
Date: 2005-03-26 09:50

Message:
Logged In: YES 
user_id=4771

The bug is in weakrefobject:proxy_nonzero(), which calls the underlying 
object's nb_nonzero slot instead of going through the general PyObject_IsTrue() 
mecanism.  Built-in types like list and dict don't have a nb_nonzero slot.

As a related bug, (Callable)ProxyType should implement tp_richcompare in 
addition to tp_compare.  In fact, we should review the code to check if 
ProxyType knows about the most recent type slots...

--

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

[ python-Bugs-210834 ] urlparse and HTTP parameters (PR#205)

[SourceForge.net]

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

Category: Python Library
Group: Feature Request
Status: Closed
>Resolution: Out of Date
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jeremy Hylton (jhylton)
Summary: urlparse and HTTP parameters (PR#205)

Initial Comment:
Jitterbug-Id: 205
Submitted-By: [EMAIL PROTECTED]
Date: Tue, 15 Feb 2000 17:09:44 -0500 (EST)
Version: 1.5.2
OS: All


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

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



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

--

Comment By: Brett Cannon (bcannon)
Date: 2004-04-18 23:28

Message:
Logged In: YES 
user_id=357491

is urlparse still not compatible?  The regression tests test against RFC 
2396 examples now.

--

Comment By: Jeremy Hylton (jhylton)
Date: 2000-10-03 07:14

Message:
added to pep 42


--

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2000-09-16 15:07

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

--

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-07 15:03

Message:
Please do triage on this bug.

--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2000-08-16 19:02

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

--

Comment By: Nobody/Anonymous (nobody)
Date: 2000-08-01 14:13

Message:
Go for it!

--

Comment By: Nobody/Anonymous (nobody)
Date: 2000-08-01 14:13

Message:
From: Guido van Rossum <[EMAIL PROTECTED]>
Subject: Re: urlparse and HTTP parameters (PR#205)
Date: Wed Feb 23 21:39:30 2000

Go for it!

--Guido van Rossum


--

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

[ python-Bugs-1171023 ] Thread.join() fails to release Lock on KeyboardInterrupt

[SourceForge.net]

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

Category: Threads
Group: Python 2.4
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Peter Hansen (phansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Thread.join() fails to release Lock on KeyboardInterrupt

Initial Comment:
In threading.Thread.join(), the Condition/Lock object
called self.__block is acquired upon entry, and
released on exit without an enclosing try/finally to
ensure that the release really occurs.

If the join() call has no timeout, the wait() call that
occurs inside can never be interrupted so there is no
problem.

If the join() call has a timeout, however, the wait()
occurs in a loop which can be interrupted by a Ctrl-C,
raising a KeyboardInterrupt which skips the
self.__block.release() call and leaves the Lock acquired.

This is a problem if the main thread (which is the only
one that will see a KeyboardInterrupt) is the one
calling join() and only if the other thread on which
the join() is being called is a non-daemon thread or,
in the case of a daemon thread, if the main thread
subsequently attempts to wait for the other thread to
terminate (for example, by monitoring isAlive() on the
other thread).

In any event, the lack of a try/finally means the
joined thread will never really finish because any
attempt by it to call its __stop() method will block
forever.

--

>Comment By: Brett Cannon (bcannon)
Date: 2005-03-27 11:02

Message:
Logged In: YES 
user_id=357491

Duplicate of bug #1171023.

--

Comment By: Peter Hansen (phansen)
Date: 2005-03-26 07:19

Message:
Logged In: YES 
user_id=567267

A workaround (tested) is to subclass Thread and ensure that
the lock is released.  I'm not certain this is completely
safe as written, but I'm assuming that you can safely
attempt to release a lock that you don't own and the worst
that can happen is you'll get an exception (which the
workaround code catches and ignores).

--

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

[ python-Bugs-1167930 ] threading.Thread.join() cannot be interrupted by a Ctrl-C

[SourceForge.net]

Bugs item #1167930, was opened at 2005-03-21 14:19
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167930&group_id=5470

Category: Threads
>Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Nicholas Veeser (nveeser)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading.Thread.join() cannot be interrupted by a Ctrl-C

Initial Comment:
I write a python program that that starts several
threads and then waits on them all.  If I use join() to
wait on the threads, there is no way to Stop the
process with Ctrl-C.  

Threading.Thread.join() uses a lock
(thread.allocate_lock())  to put itself on the
"wait_queue".It then calls thread.Lock.acquire(),
which blocks indefinitely.  Lock.acquire() (at least in
POSIX) seems to work in such a way as to ignore any
signals.  (both semaphore and condition variable type).


PyThread_acquire_lock() will not return until the lock
is acquired, even if a signal is sent.   Effectively,
Ctrl-C is "masked" until the lock is released, (the
joined thread is done), and the main thread comes back
to the interpreter and handles the signal, producing a
KeyboardInterrupt Exception.  But not before the lock
is released, which is once the thread is finished,
which is too late if you want to kill the main thread
and have it gracefully stop its child threads.

So the "main" thread has no way to call, join() and
still respond to Ctrl-C in some way.

One solution could be to change threading.Thread.join()
to use other methods of synchronization which respond
to Ctrl-C more effectively.

Another solution would be to have Lock.acquire() throw
a KeyboardInterruped exception like other system calls.
 This IHMO would make the python objects behave more
like Java, which requires catching the
InterruptedException, giving the developer more control
over how to handle this case.

--

>Comment By: Brett Cannon (bcannon)
Date: 2005-03-27 11:02

Message:
Logged In: YES 
user_id=357491

The other bug report phansen is talking about is bug #1171023 (http://
www.python.org/sf/1171023).  Closed as a duplicate but it can still be used 
for file uploads by phansen.

Also worth reading for its explanation.

--

Comment By: Peter Hansen (phansen)
Date: 2005-03-26 07:22

Message:
Logged In: YES 
user_id=567267

It appears only the original submitter (and admins?) can
attach files, so I've attached the example workaround in the
other bug report that I submitted.  It makes more sense in
that one anyway.

--

Comment By: Peter Hansen (phansen)
Date: 2005-03-26 06:59

Message:
Logged In: YES 
user_id=567267

Coincidentally this issue came up in a thread in
comp.lang.python just now.  See tim one's reply at
http://groups.google.ca/groups?selm=mailman.884.815188.1799.python-list%40python.org
which indicates that "it's simply not possible for Ctrl+C to
interrupt a mutex acquire".

A workaround is to be sure to call join() with a timeout
value, inside a loop if you absolutely need an indefinite
timeout, but that won't necessarily work because of a
different problem which I just reported as bug 1171023. 
There's a workaround for that problem too though, provided
you can subclass threading.Thread: provide your own join()
which wraps the builtin one and which attempts to release
the lock safely.  I'll attach an example if I can figure out
how... there's no option to do so on this particular page in
Sourceforge. :-(

--

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

[ python-Bugs-1170331 ] Error in base64.b32decode

[SourceForge.net]

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

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: toidinamai (toidinamai)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in base64.b32decode

Initial Comment:
Hi,   
  
 
  
  
 
I believe there is an error in base64.b32decode because
it doesn't seem to
  
allow to decode arbitrary binary data:
  
 


  
 
#!/usr/bin/env python2.4  
  
 
  
  
 
import base64 
  
 
  
  
 
b64d = base64.b64decode   
  
 
b64e = base64.b64encode   
  
 
  
  
 
print "base64: ", repr(b64d(b64e('\x00')))
  
 
  
  
 
b16d = base64.b16decode   
  
 
b16e = base64.b16encode   
  
 
  
  
 
print "base16: ", repr(b16d(b16e('\x00')))
  
 
  
  
 
b32d = base64.b32decode   
  
 
b32e = base64.b32encode   
  
 
  
  
 
print "base32: ", repr(b32d(b32e('\x00')))
  
 
   
  
 
  
  
 
This raises a very strange exception: 
  
 
  
  
 
Traceback (most recent call 

[ python-Bugs-1162677 ] Unable to Install Python 2.4.1rc1 on windows XP SP2

[SourceForge.net]

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

Category: Installation
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Sergio Correia (sergiocorreia)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable to Install  Python 2.4.1rc1 on windows XP SP2

Initial Comment:
First of all, YES i had everything i needed to install,
and yes i read the info on the site.

When i tried to install python-2.4.1c1.msi (or even
ActivePython-2.4.0-244-win32-ix86.msi), install "ended
prematurely because of an error".

I tried everything but, after a while i found a way to
avoid the bug.

I was installing from "F:\Docs\Varios\Sandbox".. i
moved the msi file to C:\ and then the install (both,
python and activepython) worked out perfectly.

Folders were not shared, restricted, compressed or on a
network (it was a normal local hard disk).

Any ideas on why that happened?

Thanks


PS: Sorry about the sp. mistakes. I am not very fluent
on technical english.

--

>Comment By: Martin v. Löwis (loewis)
Date: 2005-03-27 22:42

Message:
Logged In: YES 
user_id=21627

Unfortunately, I have still no clue what could be causing
this problem. Message 1708 means "Installation operation
failed.", message 2262 is "Stream does not exist: [2].
System error: [3]." Here, 2: is meant to be the stream name
- but Installer does not try to use any stream name.

I'm also confused that you say you are running from
f:\Docs\Varios\Sandbox, yet the log file says that the
package being installed is "C:\python-2.4.1c1.msi" (see the
first lines of the log file); the value of OriginalDatabase
is supposed to point to the file you have msiexec'ed.

Since you have a work-around, I'll be closing this as "won't
fix".

--

Comment By: Sergio Correia (sergiocorreia)
Date: 2005-03-22 01:27

Message:
Logged In: YES 
user_id=1238520

I uploaded the file again, downloaded it and it worked. ^_^

--

Comment By: Martin v. Löwis (loewis)
Date: 2005-03-22 01:15

Message:
Logged In: YES 
user_id=21627

Can you please check that the file downloads correctly? I get a zipfile, but 
that only contains a garbage python.log (i.e. no text file). Perhaps you can 
try to attach it uncompressed?

--

Comment By: Sergio Correia (sergiocorreia)
Date: 2005-03-15 07:00

Message:
Logged In: YES 
user_id=1238520

Thanks for the reply.

So i uninstalled it, tried again from 
the "F:\Docs\Varios\Sandbox" folder, got the same error, and 
attached the log.

Btw,  F: is a physical drive, and its not SUBSTed.

=)

Oh, the last lines of the log were:
=== Logging stopped: 15/03/2005  00:54:23 ===
MSI (c) (24:A0) [00:54:23:153]: Note: 1: 1708 
MSI (c) (24:A0) [00:54:23:153]: Note: 1: 2262 2: Error 3: -
2147287038 
MSI (c) (24:A0) [00:54:23:153]: Note: 1: 2262 2: Error 3: -
2147287038 
MSI (c) (24:A0) [00:54:23:153]: Product: Python 2.4.1c1 -- 
Installation failed.

MSI (c) (24:A0) [00:54:23:163]: Grabbed execution mutex.
MSI (c) (24:A0) [00:54:23:163]: Cleaning up uninstalled install 
packages, if any exist
MSI (c) (24:A0) [00:54:23:173]: MainEngineThread is 
returning 1603
=== Verbose logging stopped: 15/03/2005  00:54:23 ===


--

Comment By: Martin v. Löwis (loewis)
Date: 2005-03-14 22:36

Message:
Logged In: YES 
user_id=21627

No, but I know how to find out. Please run, in a cmd.exe window,

msiexec /i python-2.4.1c1.msi /l*v python.log

Compress python.log with Winzip, and attach the resulting
file to this report.

As a wild guess: could it be that F: is SUBSTed?

--

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

[ python-Bugs-1166660 ] The readline module can cause python to segfault

[SourceForge.net]

Bugs item #110, was opened at 2005-03-19 21:48
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=110&group_id=5470

Category: Threads
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Yariv Ido (dcoder)
>Assigned to: Michael Hudson (mwh)
Summary: The readline module can cause python to segfault

Initial Comment:
When starting an interactive interpreter in another
thread, with readline's completion functionality, there
exists a race condition which causes the Python
interpreter to segfault. There's a small discussion
about this bug at
.

Attached is a small proof-of-concept code. Please note
that some people couldn't reproduce this on slower
machines. I've managed to reproduce it on several Linux
systems (Dual Xeon computers), using Python 2.3.4, 2.4
and 2.4.1c2.

Thanks in advance.

--

>Comment By: Michael Hudson (mwh)
Date: 2005-03-27 21:43

Message:
Logged In: YES 
user_id=6656

I'll take a look at this.

Did you submit a bug on the set_startup_hook problem mentioned in the 
ipython tracker?

--

Comment By: Yariv Ido (dcoder)
Date: 2005-03-19 23:59

Message:
Logged In: YES 
user_id=326689

I may be completely off track here, but shouldn't
on_completion(...) (readline.c) use _PyOS_ReadlineTState
instead of completer_tstate to restore the GIL?

Also, in readline_until_enter_or_signal(...), shouldn't
PyEval_SaveThread()'s return value be saved back to 
_PyOS_ReadlineTState?

It seems that these patches manage to fix the above
segmentation fault...

--

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

[ python-Bugs-1169212 ] small change in ossaudiodev module doc.

[SourceForge.net]

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

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: hiower (hiower)
>Assigned to: Greg Ward (gward)
Summary: small change in ossaudiodev module doc.

Initial Comment:
from
http://docs.python.org/lib/ossaudio-device-objects.html:

AFMT_U8 Unsigned, 8-bit audio
AFMT_S16_LE Unsigned, 16-bit audio, little-endian byte
order
(as used by Intel processors)
AFMT_S16_BE Unsigned, 16-bit audio, big-endian byte order
(as used by 68k, PowerPC, Sparc)
AFMT_S8 Signed, 8 bit audio
AFMT_U16_LE Signed, 16-bit little-endian audio
AFMT_U16_BE Signed, 16-bit big-endian audio

Note how the U:s and S:s are switched compared to
signed and unsigned, this should surely not be like this? 

Perhaps AFMT_AC3 and AFMT_S16_NE should be included as
well? (if anyone uses it?)


also, maybe this line:

write(  data)
Write the Python string data to the audio device
and return the number of bytes written.

could be subtituted with something like this:

write(  data)
Write the Python data to the audio device and
return the number of bytes written. The data should be
a string or a list (of amplitude values...something)


--

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

[ python-Bugs-1167262 ] Fails assertion in winsig.c under VC 8.0

[SourceForge.net]

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

Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Timothy Fitz (timothyfitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fails assertion in winsig.c under VC 8.0

Initial Comment:
In 2.4 and current cvs initsignal in signalmodule.c calls 
PyOS_getsig which calls signal with an invalid signal 
number. Under VC 7.1 (and 7.0, and probably before) 
this would return SIG_ERR however under VC 8.0 (beta) 
this causes an assertion failure. 


--

>Comment By: Michael Hudson (mwh)
Date: 2005-03-27 21:59

Message:
Logged In: YES 
user_id=6656

Ew.  My first thought is, is that allowed by ANSI C?  I'd guess it's 
undefined behaviour.  It still seems excessively unfriendly -- have you 
reported this to MS?

--

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

[ python-Bugs-1165306 ] Property access with decorator makes interpreter crash

[SourceForge.net]

Bugs item #1165306, was opened at 2005-03-17 14:56
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Remy Blank (remyblank)
Assigned to: Michael Hudson (mwh)
Summary: Property access with decorator makes interpreter crash

Initial Comment:
The attached file makes the interpreter crash.
Basially, a method is decorated, and used as the getter
function for a property. Accessing the property
provokes the crash.

I get the following output (linux-2.6.10):

[EMAIL PROTECTED] TestCases $ ./crashTest.py
Creating instance
Getting value
Segmentation fault

Using python-2.3.4 from Gentoo, i.e. it has a few
patches from 2.3.5.

On Windows XP with python-2.4, I get a "Python has
encountered a problem and needs to close." dialog box.

--

>Comment By: Michael Hudson (mwh)
Date: 2005-03-27 22:16

Message:
Logged In: YES 
user_id=6656

> > remyblank: let me guess your code wasn't doing what
> > you thought it did? :)
> 
> Err... Not sure what you mean... What would be the correct
> way to do what I thought it did?

Well, I don't know, but what it was doing was trying to create a method 
bound to None...

I'll check this in soon.

--

Comment By: Remy Blank (remyblank)
Date: 2005-03-17 20:13

Message:
Logged In: YES 
user_id=568100

> remyblank: let me guess your code wasn't doing what you
thought it did? :)

Err... Not sure what you mean... What would be the correct
way to do what I thought it did?

The code was largely inspired by a Cookbook entry. These are
still my first steps with decorators, and I have to admit I
don't yet fully understand why I have to create a MethodType
manually.

--

Comment By: Guido van Rossum (gvanrossum)
Date: 2005-03-17 18:43

Message:
Logged In: YES 
user_id=6380

Looks OK on cursory inspection.

--

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 17:28

Message:
Logged In: YES 
user_id=6656

Let's attach a test case too.

--

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 17:15

Message:
Logged In: YES 
user_id=6656

Well, it's a bit more subtle than I thought:

>>> def f(): pass
... 
>>> print f.__get__(1).im_class
None

The problem occurs when *both* im_self and im_class are None; and I'm 
now reasonably convinced that calling the type object is the only way this 
can be acheived.  So a simple check along these lines in 
instancemethod_new would suffice (patch attached), and seems less likely 
to break code.

I suspect this has missed 2.4.1.

remyblank: let me guess your code wasn't doing what you thought it did? :)

--

Comment By: Guido van Rossum (gvanrossum)
Date: 2005-03-17 17:03

Message:
Logged In: YES 
user_id=6380

Looks like I wasn't finished with the thought when I checked
it in. I think I was trying to make instancemethod generally
useful as a currying primitive. That should probably be
considered more careful; please roll it back.

(I think it may have been part of the aborted experiment to
get rid of bound methods.)

Is there time to backport this to 2.4.1?

--

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 16:44

Message:
Logged In: YES 
user_id=6656

Hmm.  A little CVS log reading finds us this:

revision 2.170
date: 2003/04/09 19:35:08;  author: gvanrossum;  state: Exp;  lines: +2 -2
branches:  2.170.10;
Make it possible to call instancemethod() with 2 arguments.

Guido, what was the motivation for this?  Is it possible to create 
instancemethods with im_class == NULL some other way?  (If there is, I 
don't see it).

Also, you didn't add a unit test  (in fact, instancemethod_new only 
gets called twice during a run of the test suite, both times with three 
arguments).

--

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 15:17

Message:
Logged In: YES 
user_id=6656

Confirmed, on 2.4 HEAD, even.

There's a lot going on in your test file that is unecessary, though; this is a 
smaller test case:

types.MethodType(lambda :None, None)(1)

instancemethod_call doesn't seem to expect im_class to be NULL...

--

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

[ python-Bugs-1165761 ] KeyboardInterrupt causes segmentation fault with threads

[SourceForge.net]

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

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Stearns (jeffstearns)
>Assigned to: Tim Peters (tim_one)
Summary: KeyboardInterrupt causes segmentation fault with threads

Initial Comment:
The attached sample program crashes Python 2.4.1c1 with a 
segmentation fault if it is interupted.

I wrote a simple program which simulates multiple HTTP clients.

The program is mult-threaded.

It runs on Debian with a 2.6 kernel.

If the program is interrupted (via ^C), Python 2.4.1c1 takes a 
segmentation fault.

Investigation with gdb shows that the error occurs within 
PyEval_EvalFrame at line 1661 below.
It's executing an END_FINALLY bytecode.
The offending statement is
   v = POP();
The value of v is 0.
This is then passed to PyInt_Check(), which attempts to dereference 
a NULL pointer.


1659case END_FINALLY:
1660v = POP();
1661if (PyInt_Check(v)) {
1662why = (enum why_code) 
PyInt_AS_LONG(v);
1663assert(why != WHY_YIELD);
1664if (why == WHY_RETURN ||
1665why == WHY_CONTINUE)
1666retval = POP();
1667}



#0  PyEval_EvalFrame (f=0x821cd04) at Python/ceval.c:1661
#1  0x080ae6bd in fast_function (func=0x4030df8d, 
pp_stack=0xbfffe85c, n=1, na=1076944740, nk=1079484852) at 
Python/ceval.c:3629
#2  0x080ae254 in call_function (pp_stack=0xbfffe85c, 
oparg=1076944740) at Python/ceval.c:3568
#3  0x080ac7a6 in PyEval_EvalFrame (f=0x8227d04) at Python/
ceval.c:2163
#4  0x080ad21e in PyEval_EvalCodeEx (co=0x4037e660, 
globals=0x4030df64, locals=0x4030df8d, args=0x40295c78, 
argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0)
at Python/ceval.c:2730
#5  0x08105647 in function_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x0) at Objects/funcobject.c:548
#6  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#7  0x08062e38 in instancemethod_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x4030df64) at Objects/classobject.c:2431
#8  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#9  0x080ae0e7 in PyEval_CallObjectWithKeywords 
(func=0x4030df64, arg=0x4028702c, kw=0x405785a4) at Python/
ceval.c:3419
#10 0x0809101c in slot_tp_del (self=0x4057a1b4) at Objects/
typeobject.c:4818
#11 0x08086f93 in subtype_dealloc (self=0x4057a1b4) at Objects/
typeobject.c:669
#12 0x08062a4c in instancemethod_dealloc (im=0x4057857c) at 
Objects/classobject.c:2225
#13 0x080790a4 in dict_dealloc (mp=0x4056aacc) at Objects/
dictobject.c:734
#14 0x0805e544 in instance_dealloc (inst=0x40569dcc) at Objects/
classobject.c:687
#15 0x081042cb in frame_dealloc (f=0x8218f14) at Objects/
frameobject.c:418
#16 0x080dc1e9 in PyThreadState_Clear (tstate=0x81f9820) at 
Python/pystate.c:217
#17 0x080dbdf8 in PyInterpreterState_Clear (interp=0x8148048) at 
Python/pystate.c:93
#18 0x080dcef2 in Py_Finalize () at Python/pythonrun.c:408
#19 0x08055391 in Py_Main (argc=1, argv=0xbfffee14) at Modules/
main.c:504
#20 0x08054eeb in main (argc=1076944740, argv=0x4030df64) at 
Modules/python.c:23


--

>Comment By: Michael Hudson (mwh)
Date: 2005-03-27 22:21

Message:
Logged In: YES 
user_id=6656

Tim, I'd like to check this in.  You get a few days to object :)

--

Comment By: Michael Hudson (mwh)
Date: 2005-03-19 10:29

Message:
Logged In: YES 
user_id=6656

Well, sure.  However, the attached patch makes at least some of them go 
away; it also makes this comment from Py_Finalize:

/* Now we decref the exception classes.  After this point nothing
   can raise an exception.  That's okay, because each Fini() method
   below has been checked to make sure no exceptions are ever
   raised.
*/
less hilariously inaccurate.  I'm not saying it's anything like a thorough fix.

I'm away for a week from about five minutes time, so if you like it, check it 
in yourself, please.

--

Comment By: Tim Peters (tim_one)
Date: 2005-03-18 21:38

Message:
Logged In: YES 
user_id=31435

I'm thinking maybe we should rename .setDaemon() 
to .generateRandomShutdownSegfaults() -- pretty much the 
same thing in practice!  Unless/until teardown is rewritten to 
be purely gc-based, asking a thread to keep running while 
the interpreter is destroying itself is going to be vulnerable.

---

[ python-Bugs-1165761 ] KeyboardInterrupt causes segmentation fault with threads

[SourceForge.net]

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

Category: Threads
Group: Python 2.4
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Jeff Stearns (jeffstearns)
>Assigned to: Michael Hudson (mwh)
Summary: KeyboardInterrupt causes segmentation fault with threads

Initial Comment:
The attached sample program crashes Python 2.4.1c1 with a 
segmentation fault if it is interupted.

I wrote a simple program which simulates multiple HTTP clients.

The program is mult-threaded.

It runs on Debian with a 2.6 kernel.

If the program is interrupted (via ^C), Python 2.4.1c1 takes a 
segmentation fault.

Investigation with gdb shows that the error occurs within 
PyEval_EvalFrame at line 1661 below.
It's executing an END_FINALLY bytecode.
The offending statement is
   v = POP();
The value of v is 0.
This is then passed to PyInt_Check(), which attempts to dereference 
a NULL pointer.


1659case END_FINALLY:
1660v = POP();
1661if (PyInt_Check(v)) {
1662why = (enum why_code) 
PyInt_AS_LONG(v);
1663assert(why != WHY_YIELD);
1664if (why == WHY_RETURN ||
1665why == WHY_CONTINUE)
1666retval = POP();
1667}



#0  PyEval_EvalFrame (f=0x821cd04) at Python/ceval.c:1661
#1  0x080ae6bd in fast_function (func=0x4030df8d, 
pp_stack=0xbfffe85c, n=1, na=1076944740, nk=1079484852) at 
Python/ceval.c:3629
#2  0x080ae254 in call_function (pp_stack=0xbfffe85c, 
oparg=1076944740) at Python/ceval.c:3568
#3  0x080ac7a6 in PyEval_EvalFrame (f=0x8227d04) at Python/
ceval.c:2163
#4  0x080ad21e in PyEval_EvalCodeEx (co=0x4037e660, 
globals=0x4030df64, locals=0x4030df8d, args=0x40295c78, 
argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0)
at Python/ceval.c:2730
#5  0x08105647 in function_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x0) at Objects/funcobject.c:548
#6  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#7  0x08062e38 in instancemethod_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x4030df64) at Objects/classobject.c:2431
#8  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#9  0x080ae0e7 in PyEval_CallObjectWithKeywords 
(func=0x4030df64, arg=0x4028702c, kw=0x405785a4) at Python/
ceval.c:3419
#10 0x0809101c in slot_tp_del (self=0x4057a1b4) at Objects/
typeobject.c:4818
#11 0x08086f93 in subtype_dealloc (self=0x4057a1b4) at Objects/
typeobject.c:669
#12 0x08062a4c in instancemethod_dealloc (im=0x4057857c) at 
Objects/classobject.c:2225
#13 0x080790a4 in dict_dealloc (mp=0x4056aacc) at Objects/
dictobject.c:734
#14 0x0805e544 in instance_dealloc (inst=0x40569dcc) at Objects/
classobject.c:687
#15 0x081042cb in frame_dealloc (f=0x8218f14) at Objects/
frameobject.c:418
#16 0x080dc1e9 in PyThreadState_Clear (tstate=0x81f9820) at 
Python/pystate.c:217
#17 0x080dbdf8 in PyInterpreterState_Clear (interp=0x8148048) at 
Python/pystate.c:93
#18 0x080dcef2 in Py_Finalize () at Python/pythonrun.c:408
#19 0x08055391 in Py_Main (argc=1, argv=0xbfffee14) at Modules/
main.c:504
#20 0x08054eeb in main (argc=1076944740, argv=0x4030df64) at 
Modules/python.c:23


--

>Comment By: Tim Peters (tim_one)
Date: 2005-03-27 19:43

Message:
Logged In: YES 
user_id=31435

Yup, I agree it's an improvement.  Sorry I didn't have time to 
look at it last week (was at PyCon all day 7 days straight).

--

Comment By: Michael Hudson (mwh)
Date: 2005-03-27 16:21

Message:
Logged In: YES 
user_id=6656

Tim, I'd like to check this in.  You get a few days to object :)

--

Comment By: Michael Hudson (mwh)
Date: 2005-03-19 05:29

Message:
Logged In: YES 
user_id=6656

Well, sure.  However, the attached patch makes at least some of them go 
away; it also makes this comment from Py_Finalize:

/* Now we decref the exception classes.  After this point nothing
   can raise an exception.  That's okay, because each Fini() method
   below has been checked to make sure no exceptions are ever
   raised.
*/
less hilariously inaccurate.  I'm not saying it's anything like a thorough fix.

I'm away for a week from about five minutes time, so if you like it, check it 
in yourself, please.

--

Comment By: Tim Peters (tim_one)
Date: 2005-03-18 16:38

Message:
Logged In: YES 
user_id=31

[ python-Bugs-1171023 ] Thread.join() fails to release Lock on KeyboardInterrupt

[SourceForge.net]

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

Category: Threads
Group: Python 2.4
Status: Closed
Resolution: Duplicate
Priority: 5
Submitted By: Peter Hansen (phansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Thread.join() fails to release Lock on KeyboardInterrupt

Initial Comment:
In threading.Thread.join(), the Condition/Lock object
called self.__block is acquired upon entry, and
released on exit without an enclosing try/finally to
ensure that the release really occurs.

If the join() call has no timeout, the wait() call that
occurs inside can never be interrupted so there is no
problem.

If the join() call has a timeout, however, the wait()
occurs in a loop which can be interrupted by a Ctrl-C,
raising a KeyboardInterrupt which skips the
self.__block.release() call and leaves the Lock acquired.

This is a problem if the main thread (which is the only
one that will see a KeyboardInterrupt) is the one
calling join() and only if the other thread on which
the join() is being called is a non-daemon thread or,
in the case of a daemon thread, if the main thread
subsequently attempts to wait for the other thread to
terminate (for example, by monitoring isAlive() on the
other thread).

In any event, the lack of a try/finally means the
joined thread will never really finish because any
attempt by it to call its __stop() method will block
forever.

--

>Comment By: Brett Cannon (bcannon)
Date: 2005-03-27 16:46

Message:
Logged In: YES 
user_id=357491

That was supposed to be bug #1167930, not this bug itself.  =)

--

Comment By: Brett Cannon (bcannon)
Date: 2005-03-27 11:02

Message:
Logged In: YES 
user_id=357491

Duplicate of bug #1171023.

--

Comment By: Peter Hansen (phansen)
Date: 2005-03-26 07:19

Message:
Logged In: YES 
user_id=567267

A workaround (tested) is to subclass Thread and ensure that
the lock is released.  I'm not certain this is completely
safe as written, but I'm assuming that you can safely
attempt to release a lock that you don't own and the worst
that can happen is you'll get an exception (which the
workaround code catches and ignores).

--

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

[ python-Bugs-1169212 ] small change in ossaudiodev module doc.

[SourceForge.net]

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

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: hiower (hiower)
Assigned to: Greg Ward (gward)
Summary: small change in ossaudiodev module doc.

Initial Comment:
from
http://docs.python.org/lib/ossaudio-device-objects.html:

AFMT_U8 Unsigned, 8-bit audio
AFMT_S16_LE Unsigned, 16-bit audio, little-endian byte
order
(as used by Intel processors)
AFMT_S16_BE Unsigned, 16-bit audio, big-endian byte order
(as used by 68k, PowerPC, Sparc)
AFMT_S8 Signed, 8 bit audio
AFMT_U16_LE Signed, 16-bit little-endian audio
AFMT_U16_BE Signed, 16-bit big-endian audio

Note how the U:s and S:s are switched compared to
signed and unsigned, this should surely not be like this? 

Perhaps AFMT_AC3 and AFMT_S16_NE should be included as
well? (if anyone uses it?)


also, maybe this line:

write(  data)
Write the Python string data to the audio device
and return the number of bytes written.

could be subtituted with something like this:

write(  data)
Write the Python data to the audio device and
return the number of bytes written. The data should be
a string or a list (of amplitude values...something)


--

>Comment By: Greg Ward (gward)
Date: 2005-03-27 21:41

Message:
Logged In: YES 
user_id=14422

Oops, good catch on the signed/unsigned thing.  Thanks!

Fixed on release24-maint branch: Doc/lib/libossaudiodev.tex
rev 1.12.4.4.
Merged to trunk: Doc/lib/libossaudiodev.tex rev 1.15.

As for explaining the write() method: the ossaudiodev docs
are no place for a tutorial on audio encoding formats.  If
it's not immediately obvious what the string passed to
write() should be, the reader should consult OSS docs.

Hmmm... since AFMT_S16_NE may be defined by ossaudiodev, but
AFMT_U16_NE is not, I'll just leave the missing AFMT_*'s out
of the 2.4 docs and straighten things out on the trunk (for
2.5).  Specifically, I'll make ossaudiodev conditionally
define all AFMT_* macros currently documented by OSS.  Won't
bother adding everything to the docs, since the OSS ref
should be definitive.


--

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

[ python-Bugs-467924 ] Improve the ZipFile Interface

[SourceForge.net]

Bugs item #467924, was opened at 2001-10-04 11:54
Message generated for change (Settings changed) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=467924&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Improve the ZipFile Interface

Initial Comment:
There exist two methods to write to a ZipFile

 write(self, filename, arcname=None, compress_type=None)  
 writestr(self, zinfo, bytes)

but only one to read from it

 read(self, name)

Additionally, the two 'write's behave differently with respect to compression.

---
(a) 'read' does not fit to 'write', since 'write' takes a file and adds it to a 
ZipFile, 
 but 'read' is not the reverse operation. 'read' should be called 'readstr' 
since it 
 much better matches to 'writestr'.

(b) It is confusing what 'write' and 'read' actually mean. Does 'write' write a 
file, 
 or into the ZipFile? It would be more obvious if ZipFile has 4 methods 
which 
 pair-wise fit together:

 writestr (self, zinfo, bytes)
  # same as now
 readstr (self, name)
  # returns bytes (as string), currently called 'read'
  # 'read' could still live but should be deprecated
 add (self, filename, arcname=None, compress_type=None)
  # currently 'write'
  # 'write' could still live but should be deprecated
 extract (self, name, filename, arcname=None)
  # new, desired functionality

(c) BOTH, 'writestr' and 'add' should by default use the 'compress_type' that 
was 
 passed to the constructor of 'ZipFile'. Currently, 'write' does it, 
'writestr' via 
 zinfo does it not. 'ZipInfo' sets the compression strict to 'ZIP_STORED' 
:-( 
 It should not do that! It rather should:
 - allow more parameters in the signature of the constructor
to also pass the compression type (and some other attributes, too)
 - default to 'None', so that 'writestr' can see this, and then take 
the default from the 'ZipFile' instance.





--

Comment By: Myers Carpenter (myers_carpenter)
Date: 2004-05-09 14:23

Message:
Logged In: YES 
user_id=335935

The zipfile interface should match the tarfile interface. 
At the mininum is should work for this example:

import zipfile
zip = zipfile.open("sample.zip", "r")
for zipinfo in zip:
print tarinfo.name, "is", tarinfo.size, "bytes in size
and is",
zip.extract(zipinfo)
zip.close()

This closely matchs the 'tarfile' module.


--

Comment By: Matt Zimmerman (mzimmerman)
Date: 2003-07-31 10:22

Message:
Logged In: YES 
user_id=196786

It would also be very useful to be able to have ZipFile
read/write the uncompressed file data from/to a file-like
object, instead of just strings and files (respectively).

I would like to use this module to work with zip files
containing large files, but this is unworkable because the
current implementation would use excessive amounts of memory.

Currently, read() reads all of the compressed data into
memory, then uncompresses it into memory.  For files which
may be hundreds of megabytes compressed, this is undesirable.

Likewise for write(), I would like to be able to stream data
into a zip file, passing in a ZipInfo to specify the
metadata as is done with writestr().

The implementation of this functionality is quite
straightforward, but I am not sure whether (or how) the
interface should change.  Some other parts of the library
allow for a file object to be passed to the same interface
which accepts a filename.  The object is examined to see if
it has the necessary read/write methods and if not, it is
assumed to be a filename.  Would this be the correct way to
do it?

I, too, am a bit irked by the lack of symmetry exhibited by
read vs. write/writestr, and think that the interface
suggested above would be a significant improvement.

--

Comment By: Just van Rossum (jvr)
Date: 2003-01-05 15:54

Message:
Logged In: YES 
user_id=92689

In Python 2.3, writestr() has an enhanced signature: the
first arg may now also be an archive name, in which case the
correct default settings are used (ie. the compression value
is taken from the file). See patch #651621.

extract() could be moderately useful (although I don't
understand the 'arcname' arg, how's that different from
'name'?) but would have to deal with file modes (bin/text).
The file mode isn't in the archive so would have to
(optionally) be supplied by the caller.

--

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

[ python-Bugs-1163367 ] correct/clarify documentation for super

[SourceForge.net]

Bugs item #1163367, was opened at 2005-03-14 16:39
Message generated for change (Settings changed) made by bediviere
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163367&group_id=5470

Category: Documentation
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: correct/clarify documentation for super

Initial Comment:
The current documentation for super is confusing.  For
instance, it says that it returns "the superclass of
type" which is incorrect; it actually returns the next
type in type's MRO.  Well, to be truthful, it doesn't
even do that; it returns a proxy object which makes
that type's attributes available, but that's just
another reason to fix the documentation.

I suggest changing the wording to something like:

"""super(type[, object-or-type])

Return an object that exposes the attributes available
through the type's superclasses, without exposing the
attributes of the type itself.  Attributes will be
looked up using the normal resolution order, omitting
the first class in the MRO (that is, the type itself).

If the second argument is present, it should either be
an instance of object, in which case
isinstance(object-or-type, type) must be true, or it
should be an instance of type, in which case
issubclass(object-or-type, type) must be true.  The
typical use for this form of super is to call a
cooperative superclass method:

class C(B):
def meth(self, arg):
super(C, self).meth(arg)

If the second argument to super is omitted, the super
object returned will not expose any attributes
directly.  However,  attributes will be accessible
whenever the descriptor machinery is invoked, e.g.
though explicit invocation of __get__.

Note that super is undefined for implicit lookups using
statements or operators such as "super(C, self)[name]".
 These must be spelled out with their explicit lookup,
e.g. "super(C, self).__getitem__(name)". New in version
2.2. 
"""

It's not perfect and I welcome suggestions for
re-wording, but I think it's substantially more
accurate about what super actually does.  It also moves
the "second argument omitted" situation to the end,
since this is a vastly more uncommon use case.

--

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