[ python-Bugs-1709284 ] test_1686475 fails because pagefile.sys does not exist
Bugs item #1709284, was opened at 2007-04-28 14:54 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1709284&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: Platform-specific >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Calvin Spealman (ironfroggy) Assigned to: Nobody/Anonymous (nobody) Summary: test_1686475 fails because pagefile.sys does not exist Initial Comment: The file pagefile.sys is used as a test on stat'ing an open file, because previously we could rely on windows using it. It does not exist in newer versions, so the test fails. The attached patch uses a temporary file instead. -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-01 15:04 Message: Logged In: YES user_id=21627 Originator: NO As discussed on python-dev: this patch is incorrect. -- Comment By: Calvin Spealman (ironfroggy) Date: 2007-04-28 18:32 Message: Logged In: YES user_id=112166 Originator: YES File Added: os_open_stat.patch -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1709284&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1699853 ] locale.getlocale() output fails as setlocale() input
Bugs item #1699853, was opened at 2007-04-13 12:26
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1699853&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bernhard Reiter (ber)
Assigned to: Nobody/Anonymous (nobody)
Summary: locale.getlocale() output fails as setlocale() input
Initial Comment:
This problem report about the locale module
consists of three closely related parts
(this is why I have decided to put it in one report).
a) the example in the docs is wrong / missleading
b) under some locale settings python as a defect
c) a test case for the locale module, showing b)
but useful as general start for a test module.
Details:
a)
Section example:
The line
>>> loc = locale.getlocale(locale.LC_ALL) # get current locale
contradicts that getlocale should not be called with
LC_ALL, as stated in the description of getlocale.
Suggestion is to change the example to be more useful
as getting the locale as first action is not really useful.
It should be "C" anyway which will lead to (None, None)
so the value is already known. It would make more sense to
first set the default locale to the user preferences:
import locale
locale.setlocale(locale.LC_ALL,'')
loc = locale.getlocale(locale.LC_NUMERIC)
locale.setlocale(locale.LC_NUMERIC,"C")
# convert a string here
locale.setlocale(locale.LC_NUMERIC, loc)
_but_ this does not work, see problem b).
What does work is:
import
locale.setlocale(locale.LC_ALL,'')
loc = locale.setlocale(locale.LC_NUMERIC)
locale.setlocale(locale.LC_NUMERIC,"C")
# convert a string here
locale.setlocale(locale.LC_NUMERIC, loc)
Note that all_loc = locale.setlocale(locale.LC_ALL) might contain
several categories (see attached test_locale.py where I needed to decode
this).
'LC_CTYPE=de_DE.UTF-8;LC_NUMERIC=en_GB.utf8;LC_TIME=de_DE.UTF-8;LC_COLLATE=de_DE.UTF-8;LC_MONETARY=de_DE.UTF-8;LC_MESSAGES=de_DE.UTF-8;LC_PAPER=de_DE.UTF-8;LC_NAME=de_DE.UTF-8;LC_ADDRESS=de_DE.UTF-8;LC_TELEPHONE=de_DE.UTF-8;LC_MEASUREMENT=de_DE.UTF-8;LC_IDENTIFICATION=de_DE.UTF-8'
b)
The output of getlocale cannot be used as input to
setlocale sometimes.
Works with
* python2.5 und python2.4 on
Debian GNU/Linux Etch ppc, de_DE.utf8.
I had failures with
* python2.3, python2.4, python2.5
on Debian GNU/Linux Sarge ppc, [EMAIL PROTECTED]
* Windows XP SP2
python-2.4.4.msiGerman, see:
>>> import locale
>>> result = locale.setlocale(locale.LC_NUMERIC,"")
>>> print result
German_Germany.1252
>>> got = locale.getlocale(locale.LC_NUMERIC)
>>> print got
('de_DE', '1252')
>>> # works
... locale.setlocale(locale.LC_NUMERIC, result)
'German_Germany.1252'
>>> # fails
... locale.setlocale(locale.LC_NUMERIC, got)
Traceback (most recent call last):
File "", line 2, in ?
File "C:\Python24\lib\locale.py", line 381, in setlocale
return _setlocale(category, locale)
locale.Error: unsupported locale setting
>>>
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2007-05-02 14:03
Message:
Logged In: YES
user_id=38388
Originator: NO
I wrote that code, so let me comment on it:
The setlocale() function returns the setting that was previously active
(see the setlocale (3) man-page).
Unfortunately, there's no clear standard on the way locales are named. The
man-page says:
"""
A locale name is typically of the form
[EMAIL PROTECTED], where language is an ISO 639
language code, territory is an ISO 3166 country code, and codeset is a
character set
or encoding identifier like ISO-8859-1 or UTF-8. For a list of all
supported locales, try "locale -a", cf. locale(1).
"""
"Germany_Germany" is clearly not a locale name that fits the above
scheme.
If I do "locale -a" on my box, the "Germany_Germany" is not mentioned in
the resulting list, so there's no surprise that the function call
generates an error.
Note that you can set the locale without using setlocale(): all that is
needed is an environment variable and that is, of course, not subject to
any checks by setloca
[ python-Bugs-1699853 ] locale.getlocale() output fails as setlocale() input
Bugs item #1699853, was opened at 2007-04-13 12:26
Message generated for change (Comment added) made by ber
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1699853&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bernhard Reiter (ber)
Assigned to: Nobody/Anonymous (nobody)
Summary: locale.getlocale() output fails as setlocale() input
Initial Comment:
This problem report about the locale module
consists of three closely related parts
(this is why I have decided to put it in one report).
a) the example in the docs is wrong / missleading
b) under some locale settings python as a defect
c) a test case for the locale module, showing b)
but useful as general start for a test module.
Details:
a)
Section example:
The line
>>> loc = locale.getlocale(locale.LC_ALL) # get current locale
contradicts that getlocale should not be called with
LC_ALL, as stated in the description of getlocale.
Suggestion is to change the example to be more useful
as getting the locale as first action is not really useful.
It should be "C" anyway which will lead to (None, None)
so the value is already known. It would make more sense to
first set the default locale to the user preferences:
import locale
locale.setlocale(locale.LC_ALL,'')
loc = locale.getlocale(locale.LC_NUMERIC)
locale.setlocale(locale.LC_NUMERIC,"C")
# convert a string here
locale.setlocale(locale.LC_NUMERIC, loc)
_but_ this does not work, see problem b).
What does work is:
import
locale.setlocale(locale.LC_ALL,'')
loc = locale.setlocale(locale.LC_NUMERIC)
locale.setlocale(locale.LC_NUMERIC,"C")
# convert a string here
locale.setlocale(locale.LC_NUMERIC, loc)
Note that all_loc = locale.setlocale(locale.LC_ALL) might contain
several categories (see attached test_locale.py where I needed to decode
this).
'LC_CTYPE=de_DE.UTF-8;LC_NUMERIC=en_GB.utf8;LC_TIME=de_DE.UTF-8;LC_COLLATE=de_DE.UTF-8;LC_MONETARY=de_DE.UTF-8;LC_MESSAGES=de_DE.UTF-8;LC_PAPER=de_DE.UTF-8;LC_NAME=de_DE.UTF-8;LC_ADDRESS=de_DE.UTF-8;LC_TELEPHONE=de_DE.UTF-8;LC_MEASUREMENT=de_DE.UTF-8;LC_IDENTIFICATION=de_DE.UTF-8'
b)
The output of getlocale cannot be used as input to
setlocale sometimes.
Works with
* python2.5 und python2.4 on
Debian GNU/Linux Etch ppc, de_DE.utf8.
I had failures with
* python2.3, python2.4, python2.5
on Debian GNU/Linux Sarge ppc, [EMAIL PROTECTED]
* Windows XP SP2
python-2.4.4.msiGerman, see:
>>> import locale
>>> result = locale.setlocale(locale.LC_NUMERIC,"")
>>> print result
German_Germany.1252
>>> got = locale.getlocale(locale.LC_NUMERIC)
>>> print got
('de_DE', '1252')
>>> # works
... locale.setlocale(locale.LC_NUMERIC, result)
'German_Germany.1252'
>>> # fails
... locale.setlocale(locale.LC_NUMERIC, got)
Traceback (most recent call last):
File "", line 2, in ?
File "C:\Python24\lib\locale.py", line 381, in setlocale
return _setlocale(category, locale)
locale.Error: unsupported locale setting
>>>
--
>Comment By: Bernhard Reiter (ber)
Date: 2007-05-02 15:25
Message:
Logged In: YES
user_id=113859
Originator: YES
Marc-Andre,
thanks for your comment!
Note that setlocale() can also be used to query the current locale,
according to my manpage on a Debian GNU/Linux system and also
according to IEEE Std 1003.1, 2004 (POSIX).
This problem report is not invalid in both point.
You cannot deny a), the inconsistency having code that is not allowed a
few sections before in the description is appared.
b) also is a problem that occurss on a freshly installed Python
on a freshly installed German Windows version.
Same on Debian Sarge, depending on the default locale.
So if I use the functions according to the documentation,
this will just break in the real world which is not robust.
I know that it is probably hard to make this more robust,
but it is possible depeding on how the interface of this module
should look like.
Note that in your remark you believe that Germany_Germany
call fails,
but this is the one that succeeds because it is the locale
this Python ver
[ python-Bugs-1303614 ] Bypassing __dict__ readonlyness
Bugs item #1303614, was opened at 2005-09-24 23:40 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1303614&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: Fixed Priority: 5 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Bypassing __dict__ readonlyness Initial Comment: The __dict__ attribute of some objects is read-only, e.g. for type objects. However, there is a generic way to still access and modify it (without hacking with gc.get_referrents(), that is). This can lead to obscure crashes. Attached is an example that shows a potential "problem" involving putting strange keys in the __dict__ of a type. This is probably very minor anyway. If we wanted to fix this, we would need a __dict__ descriptor that looks more cleverly at the object to which it is applied. BTW the first person who understand why the attached program crashes gets a free coffee. -- >Comment By: Armin Rigo (arigo) Date: 2007-05-02 19:23 Message: Logged In: YES user_id=4771 Originator: YES Thanks zseil for the patch, which looks really good to me. For reference, it also contains the fix for #1174712. Checked in as r55080. -- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-19 16:40 Message: Logged In: YES user_id=1326842 Originator: NO Here is the updated patch. I also added a few more tests, and removed the news entry for revision 53997. File Added: modify_dict_bug2.diff -- Comment By: Armin Rigo (arigo) Date: 2007-04-19 14:46 Message: Logged In: YES user_id=4771 Originator: YES Reverted r53997 in revision 54875. zseil, could you update your patch for the new svn head? Thanks! It should mostly be a matter of simplifying it. -- Comment By: Armin Rigo (arigo) Date: 2007-04-18 09:22 Message: Logged In: YES user_id=4771 Originator: YES I'm skeptical about the whole revision 53997 which introduced not only the unneeded metaclass condition, but also the strange check when assigning to __bases__. I don't think that this check about __bases__ is correct or relevant or really fixes any crash. The link between the bases and the metaclass of a class is tenuous anyway: the bases are just used to compute the metaclass if none is specified explicitly. As I said on python-dev (with no answer) I am thinking about reverting r53997 completely. I'm going to check what I said above a bit more in-depth first. -- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-17 00:42 Message: Logged In: YES user_id=1326842 Originator: NO Here is a patch that shold fix the deldict bug. It also removes the new condition for metaclasses, because it isn't needed anymore, and fixes bug #1174712. These two changes were needed so that the patch could be properly tested. The patch does what Armin suggested; the __dict__ descriptor looks for a builtin base with tp_dictoffset != 0, and if one is found, it delegates to that base's __dict__ descriptor. File Added: modify_dict_bug.diff -- Comment By: Armin Rigo (arigo) Date: 2007-02-26 08:23 Message: Logged In: YES user_id=4771 Originator: YES 456? Now that's interesting. Not 579? I'm not sure if I ever thought about what the expected answer should be, but I'd say that you are correct: 'x.__dict__' should be empty in the end. Actually I don't really see how it manages *not* to be empty in IronPython; looks like either a very minor detail or a deeper bug... -- Comment By: Jeremy Hylton (jhylton) Date: 2007-02-25 22:36 Message: Logged In: YES user_id=31392 Originator: NO I tried test67.py in IronPython. It reports that x.hello has the value 456. Is that the correct behavior? It seems incorrect to me. If the __eq__ method is called, then the object should no longer have either the Strange() or hello attributes. They are cleared by reseting __dict__. Is that right? -- Comment By: Jeremy Hylton (jhylton) Date: 2007-02-25 22:23 Message: Logged In: YES user_id=31392 Originator: NO I tried test67.py in IronPython. It reports that x.hello has the value 456. Is that the correct behavior? It seems incorrect to me. If the __eq__ method is called, then the object should no longer have either the S
[ python-Bugs-1174712 ] subclassing ModuleType and another built-in type
Bugs item #1174712, was opened at 2005-04-01 09:22
Message generated for change (Comment added) made by arigo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1174712&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: Fixed
Priority: 5
Private: No
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: subclassing ModuleType and another built-in type
Initial Comment:
class X(types.ModuleType, str): pass
X('name')
-> segfault
This buggy subclassing goes through typeobject.c's checks because
PyModuleObject looks exactly like a user-defined subclass of 'object': it has a
PyObject_HEAD followed only by the dict, as specified by tp_dictoffset.
A fix would be to forbid any subclassing to move the tp_dictoffset of a
non-heap type.
--
>Comment By: Armin Rigo (arigo)
Date: 2007-05-02 19:25
Message:
Logged In: YES
user_id=4771
Originator: YES
Fixed by zseil's patch for #1303614, r55080.
--
Comment By: Armin Rigo (arigo)
Date: 2005-12-14 14:57
Message:
Logged In: YES
user_id=4771
The objection to the proposed fix is not valid in light
of the bug #1303614, which gives a general way to abuse
subclassing to allow the __dict__ of an instance to be
assigned to and deleted, even when it should not be allowed. So I
wouldn't worry too much about the case I pointed up, because it should be
fixed together with #1303614 (though I don't really know how). For now I
would be happy with just checking that subclassing a non-heap type doesn't
move the dict within the structure.
The same remark probably applies to the weakref field. Both cases could
be fixed by being more careful in typeobject.c:extra_ivars(): PyModule_Type
should be considered to have extra_ivars() when compared to
PyBaseObject_Type. This could be achieved by skipping the "t_size -= ..."
part if "type" is not a heap type. Indeed, for non-heap types we should
not try to consider that an extra dict or weakref slot is not important,
because the C code probably accesses this extra slot directly, as in the
case of moduleobject.c.
--
Comment By: Michael Hudson (mwh)
Date: 2005-04-03 13:39
Message:
Logged In: YES
user_id=6656
> This might point to the need for cleaning up typeobject.c's
> darker corners...
No kidding. Maybe Samuele, you and I can gang up on Guido at
EuroPython (is he sprinting? Perhaps we should ask).
--
Comment By: Armin Rigo (arigo)
Date: 2005-04-02 12:27
Message:
Logged In: YES
user_id=4771
The proposed fix is not good enough. If another built-in C type similar
to PyModuleObject is defined (say by a C extension module), then it would
become possible to subclass both this new type and ModuleType. This might
lead to unwanted behavior if e.g. one parent class allows rebinding
__dict__ and the other not (and crashes if __dict__ is rebound).
This might point to the need for cleaning up typeobject.c's darker
corners...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1174712&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1180193 ] broken pyc files
Bugs item #1180193, was opened at 2005-04-10 13:10 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180193&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: Open Resolution: None Priority: 5 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: broken pyc files Initial Comment: In a number of situations, the .pyc files can become "corrupted" in a subtle way: the co_filename attribute of the code objects it contains become wrong. This can occur if we move or rename directories, or if we access the same set of files from two different locations (e.g. over NFS). This corruption doesn't prevent the .pyc files from working, but the interpreter looses the reference to the source file. It causes trouble in tracebacks, in the inspect module, etc. A simple fix would be to use the following logic when importing a .py file: if there is a corresponding .pyc file, in addition to checking the timestamp, check the co_filename attribute of the loaded object. If it doesn't point to the original .py file, discard the code object and ignore the .pyc file. Alternatively, we could force all co_filenames to point to the .py file when loading the .pyc file. I'll write a patch for whichever alternative seems better. -- >Comment By: Armin Rigo (arigo) Date: 2007-05-02 19:42 Message: Logged In: YES user_id=4771 Originator: YES It's an obscure detail, but I think that the .pyc file should not be rewritten again after we fix the co_filenames. Fixing the co_filenames is a very very cheap operation, and I can imagine cases where the same .py files are accessed from what appears to be two different paths, e.g. over NFS - this would cause .pyc files to be rewritten all the time, which is particularly bad if we have the example of NFS in mind. Not to mention that two python processes trying to write *different* data to the same .pyc file at the same time are going to create a mess, ending in a segfault the next time the broken .pyc is loaded. It's overall a mess, so let's play it safe. -- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-24 10:01 Message: Logged In: YES user_id=1326842 Originator: NO Here is a patch that implements arigo's last suggestion. File Added: update_co_filename.diff -- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-03 13:46 Message: Logged In: YES user_id=1326842 Originator: NO Wouldn't your first solution be simpler? Changing all co_filenames would require either changing various marhal.c functions, or traversing the code object returned by import.c/read_compiled_module(). Discarding the compiled code when the file names don't match would be simpler and only require minor changes in import.c/load_source_module(). -- Comment By: Armin Rigo (arigo) Date: 2007-04-03 11:31 Message: Logged In: YES user_id=4771 Originator: YES If you ask me, I think that when the importing system finds both a .py and a .pyc for a module, then it should ignore all co_filename and replace them with the real path of the .py file. I can't see any point of not doing so. There are many other quirks caused by .pyc files accidentally remaining around, but we cannot fix them all as long as the .pyc files are at the same time a cache for performance reason and a redistributable program format (e.g. if "rm x.py" or "svn up" deletes a .py file, then the module is still importable via the .pyc left behind, a great way to oversee the fact that imports elsewhere in the project need to be updated). -- Comment By: Ziga Seilnacht (zseil) Date: 2007-04-03 07:16 Message: Logged In: YES user_id=1326842 Originator: NO This problem is reported quite often in the tracker, although it shows up in different places: http://www.python.org/sf/1666807 http://www.python.org/sf/1051638 I closed those bugs as duplicates of this one. The logging package is also affected: http://www.python.org/sf/1669498 http://www.python.org/sf/1633605 http://www.python.org/sf/1616422 -- Comment By: Armin Rigo (arigo) Date: 2007-03-28 13:40 Message: Logged In: YES user_id=4771 Originator: YES What I called "corruption" is the situation where both the .py and the .pyc files are present, but the filename stored in the .pyc co_filenames is no longer the valid absolute path of the corresponding .py file, for an
[ python-Bugs-1711605 ] CGIHttpServer leaves traces of previous requests in env
Bugs item #1711605, was opened at 2007-05-03 10:28
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=1711605&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: Extension Modules
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Steve Cassidy (stevecassidy)
Assigned to: Nobody/Anonymous (nobody)
Summary: CGIHttpServer leaves traces of previous requests in env
Initial Comment:
CGIHttpserver tries to reset the environment between calls to CGI scripts by
setting various variables to '' if they are not needed in the current request.
In some cases this is not the correct behaviour since the presence of a null
value can be interpreted by a CGI script as being significant.
For example, if HTTP_COOKIE has a null value then a script doing the standard
test:
if os.environ.has_key('HTTP_COOKIE'):
# get the cookie
will have trouble
The problem is that CGIHTTPserver.py resets the entries in the env array which
is then passed to os.environ.update(), this can only overwrite the env
variables, not remove them.
An alternative is to call
if os.environ.has_key(k):
del os.environ[k]
inside the loop that updates the empty keys, then these variables will not be
passed on to the CGI script.
Steve
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1711605&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1711608 ] CGIHttpServer fails if python exe has spaces
Bugs item #1711608, was opened at 2007-05-03 10: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=1711608&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: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Steve Cassidy (stevecassidy) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHttpServer fails if python exe has spaces Initial Comment: In addition to the problem noted in #1436206 with spaces in the file names of scripts being executed, if Python has been installed in a directory with spaces (C:\Program Files\Python) the server will fail to execute the script because the name of the executable is not quoted properly. My attempts to fix this have failed since just putting quotes around the exe name "C:\\Program Files\..." doesn't work, however we have found that just quoting the part of the path with spaces 'C:\\"Program Files"\\...' will work. It seems a bit odd that this bug has persisted for so long. A fix would be nice since this module is really good to give to my students (doing python web development for the first time) so they don't have to worry about server installation issues. Steve -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1711608&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
