From report at bugs.python.org  Wed Sep  1 00:29:18 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 31 Aug 2010 22:29:18 +0000
Subject: [New-bugs-announce] [issue9727] Add callbacks to be invoked when
	locale changes
In-Reply-To: <1283293758.47.0.775705269917.issue9727@psf.upfronthosting.co.za>
Message-ID: <1283293758.47.0.775705269917.issue9727@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

As part of the PEP 384 discussion, it was noted that one of the problems with mixed C runtimes on Windows is that each C runtime in the process has it's own idea of the current locale setting.

This can be addressed to some degree by having extension modules query and modify the Python interpreter's locale setting rather than the C runtime setting, but doesn't help those modules react to *changes* in the setting.

Would it be worth adding a callback registration mechanism to the locale module to allow modules to be notified when the locale changes? (It seems like this may be useful even outside the context of PEP 384, e.g. to dynamically update displays in GUI applications)

----------
components: Library (Lib)
messages: 115281
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Add callbacks to be invoked when locale changes
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9727>
_______________________________________

From report at bugs.python.org  Wed Sep  1 03:49:09 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 01 Sep 2010 01:49:09 +0000
Subject: [New-bugs-announce] [issue9728] Docs point to FAQ Section 3,
	but FAQs are not numbered
In-Reply-To: <1283305749.34.0.483172641002.issue9728@psf.upfronthosting.co.za>
Message-ID: <1283305749.34.0.483172641002.issue9728@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

In Doc/extending/windows.rst, there's the following text:

------------------------------------------------------------------------
If your module creates a new type, you may have trouble with this line::

   PyVarObject_HEAD_INIT(&PyType_Type, 0)

Change it to::

   PyVarObject_HEAD_INIT(NULL, 0)

and add the following to the module initialization function::

   MyObject_Type.ob_type = &PyType_Type;

Refer to section 3 of the `Python FAQ <http://www.python.org/doc/faq>`_ for
details on why you must do this.
------------------------------------------------------------------------

If I assume that Section 3 means, the third link on the FAQ page, I can't find the FAQ that's being alluded to here.  There's a comment in Include/pyport.h that I believe to be related:

            /* Under Cygwin, auto-import functions to prevent compilation */
            /* failures similar to http://python.org/doc/FAQ.html#3.24 */

However, that link no longer goes to a particular question and I can't tell which question it once referred to.

I ran into this because I'm trying to understand the cause of the issue which I suspect is related to Issue #6672.

----------
assignee: docs at python
components: Documentation
messages: 115285
nosy: brian.curtin, docs at python, stutzbach, tim.golden
priority: normal
severity: normal
stage: needs patch
status: open
title: Docs point to FAQ Section 3, but FAQs are not numbered

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9728>
_______________________________________

From report at bugs.python.org  Wed Sep  1 04:32:24 2010
From: report at bugs.python.org (Andrew Bennetts)
Date: Wed, 01 Sep 2010 02:32:24 +0000
Subject: [New-bugs-announce] [issue9729] Unconnected SSLSocket.{send,
	recv} raises TypeError: 'member_descriptor' object is not callable
In-Reply-To: <1283308344.48.0.527543460928.issue9729@psf.upfronthosting.co.za>
Message-ID: <1283308344.48.0.527543460928.issue9729@psf.upfronthosting.co.za>


New submission from Andrew Bennetts <spiv at users.sourceforge.net>:

ython 2.6.6 (r266:84292, Aug 24 2010, 21:47:18) 
[GCC 4.4.5 20100816 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket, ssl
>>> s = socket.socket()
>>> wrapped = ssl.wrap_socket(s)
>>> wrapped.recv(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/ssl.py", line 217, in recv
    return socket.recv(self, buflen, flags)
TypeError: 'member_descriptor' object is not callable


What I expected was a more helpful error, like the unwrapped socket gives:

>> s.recv(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
socket.error: [Errno 107] Transport endpoint is not connected


The full list of affected methods are all the _delegate_methods from socket.py:

_delegate_methods = ("recv", "recvfrom", "recv_into", "recvfrom_into",
                     "send", "sendto")

The cause is that the SSLSocket subclass is trying to upcall to the _socketobject base class, but the base does not have methods for those, just __slots__ for the instance to fill in with bound methods.

----------
messages: 115286
nosy: spiv
priority: normal
severity: normal
status: open
title: Unconnected SSLSocket.{send,recv} raises TypeError: 'member_descriptor' object is not callable
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9729>
_______________________________________

From report at bugs.python.org  Wed Sep  1 05:44:25 2010
From: report at bugs.python.org (JingCheng LIU)
Date: Wed, 01 Sep 2010 03:44:25 +0000
Subject: [New-bugs-announce] [issue9730] base64 encoding takes in bytes
	rather than string.
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>


New submission from JingCheng LIU <liuexp at gmail.com>:

http://docs.python.org/py3k/library/base64.html?highlight=base64
the examples given doesn't work

----------
assignee: docs at python
components: Documentation
messages: 115287
nosy: Dmitry.Jemerov, JingCheng.LIU, docs at python, ezio.melotti, orsenthil, pitrou
priority: normal
severity: normal
status: open
title: base64 encoding takes in bytes rather than string.
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9730>
_______________________________________

From report at bugs.python.org  Wed Sep  1 15:02:33 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 01 Sep 2010 13:02:33 +0000
Subject: [New-bugs-announce] [issue9731] ABCMeta.register should verify that
	methods are present
In-Reply-To: <1283346153.7.0.611629242062.issue9731@psf.upfronthosting.co.za>
Message-ID: <1283346153.7.0.611629242062.issue9731@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

In Issue 9212, I mused:

> I sort of wonder if .register() should verify that the concrete class
> provides all of the methods of the ABC.

?ric Araujo suggested I open that as an issue for consideration.  

I have found a few bugs in the standard library where a concrete class did not actually implement all of the methods of the ABC that it purported to implement.  Specifically:

dict's keys view claims to implement the Set ABC but doesn't provide the is_disjoint method (Issue 9212)

range objects claims to support the Sequence ABC but don't provide the count and index methods (Issue 9213)

Should ABCMeta.register verify that the type implements all of the appropriate methods?

On the one hand, that would prevent similar bugs from sneaking by.  On the other hand, it's extra code that would get executed every time Python started (site.py imports os.py which imports _abcoll.py).

Thoughts?

----------
components: Library (Lib)
messages: 115293
nosy: benjamin.peterson, eric.araujo, gvanrossum, stutzbach
priority: normal
severity: normal
status: open
title: ABCMeta.register should verify that methods are present
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9731>
_______________________________________

From report at bugs.python.org  Wed Sep  1 15:21:10 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 01 Sep 2010 13:21:10 +0000
Subject: [New-bugs-announce] [issue9732] Addition of getattr_static for
	inspect module
In-Reply-To: <1283347270.93.0.617041013711.issue9732@psf.upfronthosting.co.za>
Message-ID: <1283347270.93.0.617041013711.issue9732@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

As discussed on python-dev, a version of getattr that does static lookups - bypassing the descriptor protocol, __getattr__, and __getattribute__. Initial implementation by Nick Coghlan, amended and tests added by me.

Phillip Eby objects to this code existing at all as it doesn't play well with proxy objects.

The purpose of getattr_static is for "passive introspection" without triggering code execution (as hasattr and getattr both do). Use cases include debugging and fetching docstrings from objects.

Caveats with the current implementation are:

Cases that will break `getattr_static`, all pathological enough not
to worry about (i.e. if you do any of these then you deserve to
have everything break anyway):

* `__dict__` existing (e.g. as a property) but not returning a
  dictionary
* classes created with `__slots__` that then have the `__slots__`
  member deleted from the class (or otherwise monkeyed with)

Cases handled incorrectly:

1. where a descriptor with a `__set__` method is shadowed by an
   instance member we return the instance member in preference to
   the descriptor, unlike `getattr`
2. types implemented in C may have neither `__dict__` nor `__slots__`,
   in this case we will be unable to find instance members and return
   the attribute descriptor instead
3. classes that inherit from a class with `__slots__` (whether or not
   they use `__slots__` themselves) will return the slot descriptor
   for instance members 'owned' by a slot on a base class
4. objects that lie about being a type by having __class__ as a
   descriptor (we traverse the mro of whatever type `obj.__class__`
   returns instead of the real type)

1 could be fixed but the code would be annoying. Is it worth fixing?

2 could be detected and where fetching an attribute from an instance
fails but an attribute descriptor is found on the type we could try
it's __get__ method. Worth it?

3 could be detected if we find a slot descriptor on a type trying
its __get__ method. Worth it?

4 could be fixed by using type everywhere instead of __class__.
We also can't use isinstance that uses __class__. If an object
is lying about __class__ then it obviously *intends* us to look
at the 'faked' version. However, this breaks the 'no code
execution' purpose of getattr_static and is inconsistent with
the rest of our behaviour. Worth fixing?

Fixing *all* of these (or any) will significantly complicate the
implimentation. 

Fetching an uninitialized instance member from an instance of a class
with __slots__ returns the slot descriptor rather than raising an
AttributeError as the descriptor does. As the slot descriptor is
a Python implementation detail perhaps we are better off propagating
the exception here. (?) On the other hand, the descriptor is
available on the class and the job of this function is to fetch
members when they are available...

I'm not aware of any other caveats / potential pitfalls. Please
point them out to me. :-)Cases that will break `getattr_static`, all pathological enough not
to worry about (i.e. if you do any of these then you deserve to
have everything break anyway):

* `__dict__` existing (e.g. as a property) but not returning a
  dictionary
* classes created with `__slots__` that then have the `__slots__`
  member deleted from the class (or otherwise monkeyed with)

Cases handled incorrectly:

1. where a descriptor with a `__set__` method is shadowed by an
   instance member we return the instance member in preference to
   the descriptor, unlike `getattr`
2. types implemented in C may have neither `__dict__` nor `__slots__`,
   in this case we will be unable to find instance members and return
   the attribute descriptor instead
3. classes that inherit from a class with `__slots__` (whether or not
   they use `__slots__` themselves) will return the slot descriptor
   for instance members 'owned' by a slot on a base class
4. objects that lie about being a type by having __class__ as a
   descriptor (we traverse the mro of whatever type `obj.__class__`
   returns instead of the real type)

1 could be fixed but the code would be annoying. Is it worth fixing?

2 could be detected and where fetching an attribute from an instance
fails but an attribute descriptor is found on the type we could try
it's __get__ method. Worth it?

3 could be detected if we find a slot descriptor on a type trying
its __get__ method. Worth it?

4 could be fixed by using type everywhere instead of __class__.
We also can't use isinstance that uses __class__. If an object
is lying about __class__ then it obviously *intends* us to look
at the 'faked' version. However, this breaks the 'no code
execution' purpose of getattr_static and is inconsistent with
the rest of our behaviour. Worth fixing?

Fixing *all* of these (or any) will significantly complicate the
implimentation. 

Fetching an uninitialized instance member from an instance of a class
with __slots__ returns the slot descriptor rather than raising an
AttributeError as the descriptor does. As the slot descriptor is
a Python implementation detail perhaps we are better off propagating
the exception here. (?) On the other hand, the descriptor is
available on the class and the job of this function is to fetch
members when they are available...

I'm not aware of any other caveats / potential pitfalls. Please
point them out to me. :-)

----------
assignee: michael.foord
components: Library (Lib)
files: static.py
keywords: needs review
messages: 115296
nosy: benjamin.peterson, michael.foord, ncoghlan
priority: normal
severity: normal
status: open
title: Addition of getattr_static for inspect module
versions: Python 3.2
Added file: http://bugs.python.org/file18699/static.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9732>
_______________________________________

From report at bugs.python.org  Wed Sep  1 15:51:20 2010
From: report at bugs.python.org (=?utf-8?q?Juan_Jos=C3=A9_Conti?=)
Date: Wed, 01 Sep 2010 13:51:20 +0000
Subject: [New-bugs-announce] [issue9733] Can't iterate over
	multiprocessing.managers.DictProxy
In-Reply-To: <1283349080.83.0.871806054056.issue9733@psf.upfronthosting.co.za>
Message-ID: <1283349080.83.0.871806054056.issue9733@psf.upfronthosting.co.za>


New submission from Juan Jos? Conti <jjconti at gmail.com>:

I expected I could iterate over a DictProxy as I do over a regular dict.

>>> from multiprocessing import Manager
>>> m = Manager()
>>> d = m.dict()
>>> d
<DictProxy object, typeid 'dict' at 0x98a240c>
>>> for x in d:
...     print x
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 2, in __getitem__
  File "/usr/lib/python2.6/multiprocessing/managers.py", line 740, in _callmethod
    raise convert_to_error(kind, result)
KeyError: 0
>>> d['a'] = 1
>>> for x in d:
...     print x
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 2, in __getitem__
  File "/usr/lib/python2.6/multiprocessing/managers.py", line 740, in _callmethod
    raise convert_to_error(kind, result)
KeyError: 0

----------
components: Library (Lib)
messages: 115302
nosy: jjconti
priority: normal
severity: normal
status: open
title: Can't iterate over multiprocessing.managers.DictProxy
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9733>
_______________________________________

From report at bugs.python.org  Wed Sep  1 20:46:13 2010
From: report at bugs.python.org (Jim Fulton)
Date: Wed, 01 Sep 2010 18:46:13 +0000
Subject: [New-bugs-announce] [issue9734] ABC issubclass/isinstance leaks in
	Python 2
In-Reply-To: <1283366773.54.0.691168683166.issue9734@psf.upfronthosting.co.za>
Message-ID: <1283366773.54.0.691168683166.issue9734@psf.upfronthosting.co.za>


New submission from Jim Fulton <jim at zope.com>:

I assume ABCs use some sort of cache for issubclass checks.

I also assume the cache doesn't use weakrefs, leading to leaks in classes created on the fly (as is common in tests).

The attached script demonstrates the leak.

The leak doesn't seem to occur in Python 3.1.2.

----------
files: abc_issubclass_leak.py
messages: 115323
nosy: j1m
priority: normal
severity: normal
status: open
title: ABC issubclass/isinstance leaks in Python 2
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file18703/abc_issubclass_leak.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9734>
_______________________________________

From report at bugs.python.org  Wed Sep  1 20:58:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Sep 2010 18:58:38 +0000
Subject: [New-bugs-announce] [issue9735] cheatsheet outdated
In-Reply-To: <1283367518.76.0.51890574432.issue9735@psf.upfronthosting.co.za>
Message-ID: <1283367518.76.0.51890574432.issue9735@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The Misc/cheatsheet file is totally outdated (the title ?Python 2.3 Quick Reference? already gives you a hint).
It is also not clear if it is meant for plain text viewing, or should be formatted using an external program...

----------
assignee: docs at python
components: Documentation
messages: 115325
nosy: docs at python, pitrou, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: cheatsheet outdated
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9735>
_______________________________________

From report at bugs.python.org  Wed Sep  1 21:01:14 2010
From: report at bugs.python.org (Jim Fulton)
Date: Wed, 01 Sep 2010 19:01:14 +0000
Subject: [New-bugs-announce] [issue9736] doctest.DocTestSuite doesn't handle
	test globs correctly
In-Reply-To: <1283367674.32.0.228375766546.issue9736@psf.upfronthosting.co.za>
Message-ID: <1283367674.32.0.228375766546.issue9736@psf.upfronthosting.co.za>


New submission from Jim Fulton <jim at zope.com>:

We often run test suites repeatedly using a debug build of python
to look for memory leaks.

We also got in the bad habit of using a fork of doctest. Recently, we've switched away from our fork and have noticed a problem with the standard doctest's handling of test globs (globals).

DocTestSuite gets an initial set of globals from the module the doctest's came from.  After running the tests, it seems to clear these, leading to errors if the tests are run again.

I've attached a script that illustrates the problem.  The script runs a simple test twice and gets a spurious failure the second time.

----------
components: Library (Lib)
files: doctest_DocTestSuite_globs_breakage.py
messages: 115326
nosy: j1m
priority: normal
severity: normal
status: open
title: doctest.DocTestSuite doesn't handle test globs correctly
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file18704/doctest_DocTestSuite_globs_breakage.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9736>
_______________________________________

From report at bugs.python.org  Wed Sep  1 23:03:56 2010
From: report at bugs.python.org (Dino Viehland)
Date: Wed, 01 Sep 2010 21:03:56 +0000
Subject: [New-bugs-announce] [issue9737] Del on memoryview crashes CPython
In-Reply-To: <1283375036.96.0.490730881857.issue9737@psf.upfronthosting.co.za>
Message-ID: <1283375036.96.0.490730881857.issue9737@psf.upfronthosting.co.za>


New submission from Dino Viehland <dinov at microsoft.com>:

x = bytearray(b'abc')
y = memoryview(x)
del y[0:1]

This crashes CPython 3.1.1 and 2.7.

----------
components: Interpreter Core
messages: 115333
nosy: dino.viehland
priority: normal
severity: normal
status: open
title: Del on memoryview crashes CPython
type: crash
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9737>
_______________________________________

From report at bugs.python.org  Thu Sep  2 00:41:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Sep 2010 22:41:35 +0000
Subject: [New-bugs-announce] [issue9738] Document the encoding of functions
	bytes arguments of the	C API
In-Reply-To: <1283380895.91.0.777071955411.issue9738@psf.upfronthosting.co.za>
Message-ID: <1283380895.91.0.777071955411.issue9738@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Many C functions have bytes argument (char* type) but the encoding is not documented. If would not be a problem if the encoding was always the same, but it is not. Examples:
 - format of PyUnicode_FromFormat() should be encoded as ISO-8859-1
 - filename of PyParser_ASTFromString() should be encoded as utf-8
 - filename of PyErr_SetFromErrnoWithFilename() should be encoded to the filesystem encoding (with strict error handler, and not surrogateescape)
 - 's' argument of PyParser_ASTFromString() should be encoded as utf-8 if PyPARSE_IGNORE_COOKIE flag is set, otherwise the parser checks for #coding:xxx cookie (if there is no cookie, utf-8 is used)

Attached patch is a try to document most low level functions. I choosed to add the name of function arguments in the headers because I consider that a header can be used as a quick documentation. I only touched .c files to change argument names.

It is hard to get the right encoding, so I cannot ensure that my patch is correct. My patch is just a draft.

I don't know if "encoded to utf-8" is the right expression. Or should it be "decoded as utf-8"?

----------
assignee: docs at python
components: Documentation, Interpreter Core, Unicode
files: encodings.patch
keywords: patch
messages: 115339
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: Document the encoding of functions bytes arguments of the C API
versions: Python 3.2
Added file: http://bugs.python.org/file18705/encodings.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9738>
_______________________________________

From report at bugs.python.org  Thu Sep  2 07:01:40 2010
From: report at bugs.python.org (Case Van Horsen)
Date: Thu, 02 Sep 2010 05:01:40 +0000
Subject: [New-bugs-announce] [issue9739] Output of help(...) is wider than
	80 characters
In-Reply-To: <1283403700.53.0.514117826781.issue9739@psf.upfronthosting.co.za>
Message-ID: <1283403700.53.0.514117826781.issue9739@psf.upfronthosting.co.za>


New submission from Case Van Horsen <casevh at gmail.com>:

In several modules, the output of help(some_module) is wider than 80 characters. This results in extra line wrapping and incorrect formatting of the help text.

I've attached a single patch (doc_width1.diff) that corrects the issue for math, cmath, tuple, datetime, and time modules. I can continue to create patches for a few modules at a time, or I can create patches for individual modules.

I'm not changing any text, only adding \n as needed.

----------
components: Extension Modules
files: doc_width1.diff
keywords: patch
messages: 115359
nosy: casevh
priority: normal
severity: normal
status: open
title: Output of help(...) is wider than 80 characters
type: behavior
Added file: http://bugs.python.org/file18707/doc_width1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9739>
_______________________________________

From report at bugs.python.org  Thu Sep  2 13:56:51 2010
From: report at bugs.python.org (ipatrol)
Date: Thu, 02 Sep 2010 11:56:51 +0000
Subject: [New-bugs-announce] [issue9740] Support for HTTP 1.1 persistent
	connections throughout	the standard library
In-Reply-To: <1283428611.84.0.131704513964.issue9740@psf.upfronthosting.co.za>
Message-ID: <1283428611.84.0.131704513964.issue9740@psf.upfronthosting.co.za>


New submission from ipatrol <ipatrol6010 at yahoo.com>:

HTTP 1.1 introduced persistent connections nearly six years ago. Yet this resource saving and speed improving option is not available in the standard library. Can this be added?

----------
components: Library (Lib)
messages: 115365
nosy: ipatrol
priority: normal
severity: normal
status: open
title: Support for HTTP 1.1 persistent connections throughout the standard library
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9740>
_______________________________________

From report at bugs.python.org  Thu Sep  2 16:31:42 2010
From: report at bugs.python.org (Timothy Lee)
Date: Thu, 02 Sep 2010 14:31:42 +0000
Subject: [New-bugs-announce] [issue9741] msgfmt.py generates invalid mo
	because msgfmt.make() does	not clear dictionary
In-Reply-To: <1283437902.68.0.344684434437.issue9741@psf.upfronthosting.co.za>
Message-ID: <1283437902.68.0.344684434437.issue9741@psf.upfronthosting.co.za>


New submission from Timothy Lee <timothy.ty.lee at gmail.com>:

This bug can potentially lead to generation of invalid mo files when msgfmt.make() is invoked more than once.

The bug has always been present in the source code.  The included patch should be applied to all maintained branches.

----------
components: Demos and Tools
files: msgfmt-clear.diff
keywords: patch
messages: 115378
nosy: timothy.ty.lee
priority: normal
severity: normal
status: open
title: msgfmt.py generates invalid mo because msgfmt.make() does not clear dictionary
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file18710/msgfmt-clear.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9741>
_______________________________________

From report at bugs.python.org  Thu Sep  2 16:35:35 2010
From: report at bugs.python.org (Misael Henriquez)
Date: Thu, 02 Sep 2010 14:35:35 +0000
Subject: [New-bugs-announce] [issue9742] Python 2.7: math module fails to
	build on Solaris 9
In-Reply-To: <1283438135.42.0.361314007633.issue9742@psf.upfronthosting.co.za>
Message-ID: <1283438135.42.0.361314007633.issue9742@psf.upfronthosting.co.za>


New submission from Misael Henriquez <misael.henriquez at merchantlink.com>:

building 'math' extension$
gcc -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/usr/local/include -I/usr/local/src/python/Python-2.7/Include -I/usr/local/src/python/Python-2.7 -c /usr/local/src/python/Python-2.7/Modules/mathmodule.c -o build/temp.solaris-2.9-sun4u-2.7/usr/local/src/python/Python-2.7/Modules/mathmodule.o$
gcc -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/usr/local/include -I/usr/local/src/python/Python-2.7/Include -I/usr/local/src/python/Python-2.7 -c /usr/local/src/python/Python-2.7/Modules/_math.c -o build/temp.solaris-2.9-sun4u-2.7/usr/local/src/python/Python-2.7/Modules/_math.o$
gcc -shared build/temp.solaris-2.9-sun4u-2.7/usr/local/src/python/Python-2.7/Modules/mathmodule.obuild/temp.solaris-2.9-sun4u-2.7/usr/local/src/python/Python-2.7/Modules/_math.o -L/usr/local/lib -lm -o build/lib.solaris-2.9-sun4u-2.7/math.so$
*** WARNING: renaming "math" since importing it failed: ld.so.1: python: fatal: relocation error: file build/lib.solaris-2.9-sun4u-2.7/math.so: symbol round: referenced symbol not found$

----------
components: Extension Modules
messages: 115379
nosy: mhenriq
priority: normal
severity: normal
status: open
title: Python 2.7: math module fails to build on Solaris 9
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9742>
_______________________________________

From report at bugs.python.org  Thu Sep  2 16:36:34 2010
From: report at bugs.python.org (Lily)
Date: Thu, 02 Sep 2010 14:36:34 +0000
Subject: [New-bugs-announce] [issue9743] __call__.__call__ chain cause crash
	when long enough
In-Reply-To: <1283438194.03.0.720338364102.issue9743@psf.upfronthosting.co.za>
Message-ID: <1283438194.03.0.720338364102.issue9743@psf.upfronthosting.co.za>


New submission from Lily <2ch.owner at gmail.com>:

Recursively getting __call__ method from existing __call__ causes interpreter infinitely grow in memory and calling resulting __call__.__call__...__call__.__call__() chain results in crash.

Platform: Windows 7 (x64)
Version: Python 2.7 (r27:82525) win32

Suggested solution:
* let the obj.__call__.__call__ point to obj.__call__

----------
components: Interpreter Core
files: ###crasher.py
messages: 115380
nosy: modchan
priority: normal
severity: normal
status: open
title: __call__.__call__ chain cause crash when long enough
type: crash
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file18711/###crasher.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9743>
_______________________________________

From report at bugs.python.org  Thu Sep  2 16:48:04 2010
From: report at bugs.python.org (Lily)
Date: Thu, 02 Sep 2010 14:48:04 +0000
Subject: [New-bugs-announce] [issue9744] calling __getattribute__ with wrong
	instance causes hang	up
In-Reply-To: <1283438884.05.0.113900555872.issue9744@psf.upfronthosting.co.za>
Message-ID: <1283438884.05.0.113900555872.issue9744@psf.upfronthosting.co.za>


New submission from Lily <2ch.owner at gmail.com>:

Look for example file.

Current behaviour: one file is started, A.__getattribute__ will be called repeatedly. Entire application will not react on KeyboardInterrupt.

Expected behaviour: exception to be raised "TypeError: unbound method __getattribute__() must be called with A instance as first argument (got M instance instead)"

Platform: Windows 7 (x64)
Version: Python 2.7 (r27: 82525)

----------
components: Interpreter Core
files: ###hanger.py
messages: 115381
nosy: modchan
priority: normal
severity: normal
status: open
title: calling __getattribute__ with wrong instance causes hang up
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file18712/###hanger.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9744>
_______________________________________

From report at bugs.python.org  Thu Sep  2 17:52:15 2010
From: report at bugs.python.org (John Ehresman)
Date: Thu, 02 Sep 2010 15:52:15 +0000
Subject: [New-bugs-announce] [issue9745] MSVC .pdb files not created by
	python 2.7 distutils
In-Reply-To: <1283442735.74.0.917204488917.issue9745@psf.upfronthosting.co.za>
Message-ID: <1283442735.74.0.917204488917.issue9745@psf.upfronthosting.co.za>


New submission from John Ehresman <jpe at wingware.com>:

.pdb files are not created because /pdb:None is set as an option on line 415 of msvc9compiler.py.  Removing the /pdb:None works to write the .pdb file and allow symbols to be loaded in the VS 2008 debugger in the one extension I tried.  Anyone know why /pdb:None was added?

----------
components: Windows
messages: 115389
nosy: jpe
priority: normal
severity: normal
status: open
title: MSVC .pdb files not created by python 2.7 distutils
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9745>
_______________________________________

From report at bugs.python.org  Thu Sep  2 21:19:26 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 02 Sep 2010 19:19:26 +0000
Subject: [New-bugs-announce] [issue9746] All sequence types support .index
	and .count
In-Reply-To: <1283455166.89.0.79459833906.issue9746@psf.upfronthosting.co.za>
Message-ID: <1283455166.89.0.79459833906.issue9746@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

In the list of operations supported by all sequence types, the .index and .count methods should be included.  They are defined by the collections.Sequence ABC that all sequences support.

(except for range objects, but that will be fixed in Issue9213)

----------
assignee: docs at python
components: Documentation
messages: 115397
nosy: docs at python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: All sequence types support .index and .count
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9746>
_______________________________________

From report at bugs.python.org  Fri Sep  3 04:06:08 2010
From: report at bugs.python.org (Neil Tallim)
Date: Fri, 03 Sep 2010 02:06:08 +0000
Subject: [New-bugs-announce] [issue9747] os.getresgid() documentation
	mentions "user ids", not "group ids"
In-Reply-To: <1283479568.94.0.540639670687.issue9747@psf.upfronthosting.co.za>
Message-ID: <1283479568.94.0.540639670687.issue9747@psf.upfronthosting.co.za>


New submission from Neil Tallim <red.hamsterx at gmail.com>:

Super-low-priority (it's obvious from context and unlike to confuse anyone who knows what they're looking at), but the os module's description for getresgid() is "Return a tuple (rgid, egid, sgid) denoting the current process?s real, effective, and saved user ids."

It should be "Return a tuple (rgid, egid, sgid) denoting the current process?s real, effective, and saved group ids."

----------
assignee: docs at python
components: Documentation
messages: 115411
nosy: Red HamsterX, docs at python
priority: normal
severity: normal
status: open
title: os.getresgid() documentation mentions "user ids", not "group ids"
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9747>
_______________________________________

From report at bugs.python.org  Fri Sep  3 04:11:16 2010
From: report at bugs.python.org (stephenk)
Date: Fri, 03 Sep 2010 02:11:16 +0000
Subject: [New-bugs-announce] [issue9748] .inputrc magic-space breaks
	interactive mode
Message-ID: <1283479876.86.0.00626935361608.issue9748@psf.upfronthosting.co.za>


Changes by stephenk <krauth.spam1 at gmail.com>:


----------
components: None
nosy: stephenk
priority: normal
severity: normal
status: open
title: .inputrc magic-space breaks interactive mode
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9748>
_______________________________________

From report at bugs.python.org  Fri Sep  3 04:57:03 2010
From: report at bugs.python.org (=?utf-8?b?UHlyeSBTw6RpbMOk?=)
Date: Fri, 03 Sep 2010 02:57:03 +0000
Subject: [New-bugs-announce] [issue9749] tuple-to-list conversion
In-Reply-To: <1283482623.34.0.524181543079.issue9749@psf.upfronthosting.co.za>
Message-ID: <1283482623.34.0.524181543079.issue9749@psf.upfronthosting.co.za>


New submission from Pyry S?il? <roadrunnahz at gmail.com>:

As I am new to Python and programming as a whole, I do not have extensive knowledge of how to correctly report a bug. And as such I must apologize for the inconvenience.

My lack of knowledge makes this only an assumption, but...

---

>>>l
[(1, 4, 7), (2, 5, 8), (3, 6, 9)]
>>>q = r = s = []
>>>for i in range(len(l)):
...    for x in l[i]:
...        q.append(x)
...    s = q
...    q = []
...    print s,    # print used to increase clarity
...    r.append(s)
...    print r    # and the next is printed out as:
...
[1, 4, 7] [1, 4, 7, [...]]
[2, 5, 8] [1, 4, 7, [...], [2, 5, 8]]
[3, 6, 9] [1, 4, 7, [...], [2, 5, 8], [3, 6, 9]]
>>>r
[1, 4, 7, [...], [2, 5, 8], [3, 6, 9]]
>>>r[3]    # for extra
[1, 4, 7, [...], [2, 5, 8], [3, 6, 9]]

---

Supposed outcome for r being [[1, 4, 7], [2, 5, 8], [3, 6, 9]]

----------
components: None
messages: 115413
nosy: Pyry.S?il?
priority: normal
severity: normal
status: open
title: tuple-to-list conversion
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9749>
_______________________________________

From report at bugs.python.org  Fri Sep  3 08:15:26 2010
From: report at bugs.python.org (Marko Kohtala)
Date: Fri, 03 Sep 2010 06:15:26 +0000
Subject: [New-bugs-announce] [issue9750] sqlite3 iterdump fails on column
	with reserved name
In-Reply-To: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>
Message-ID: <1283494526.84.0.467033818097.issue9750@psf.upfronthosting.co.za>


New submission from Marko Kohtala <marko.kohtala at gmail.com>:

Sqlite3 fails to dump a database with column names that are keywords.

----------
components: Extension Modules
files: sqlite3bug.py
messages: 115420
nosy: Marko.Kohtala
priority: normal
severity: normal
status: open
title: sqlite3 iterdump fails on column with reserved name
type: behavior
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file18720/sqlite3bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9750>
_______________________________________

From report at bugs.python.org  Fri Sep  3 11:30:12 2010
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 03 Sep 2010 09:30:12 +0000
Subject: [New-bugs-announce] [issue9751] _PyInstance_Lookup() defeats its
	purpose
In-Reply-To: <1283506212.5.0.831864167364.issue9751@psf.upfronthosting.co.za>
Message-ID: <1283506212.5.0.831864167364.issue9751@psf.upfronthosting.co.za>


New submission from Armin Rigo <arigo at users.sourceforge.net>:

_PyInstance_Lookup() is documented as follows:

    The point of this routine is that it never calls arbitrary Python
    code, so is always "safe":  all it does is dict lookups.

But of course dict lookups can call arbitrary Python code.  This function has no purpose, because it's not possible to be "safe".  I checked in a crasher:

http://svn.python.org/projects/python/branches/release27-maint/Lib/test/crashers/gc_has_finalizer.py

----------
components: Interpreter Core
messages: 115426
nosy: arigo
priority: low
severity: normal
stage: needs patch
status: open
title: _PyInstance_Lookup() defeats its purpose
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9751>
_______________________________________

From report at bugs.python.org  Fri Sep  3 11:42:33 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 03 Sep 2010 09:42:33 +0000
Subject: [New-bugs-announce] [issue9752] MSVC Compiler warning in
	Python\import.c
In-Reply-To: <1283506953.44.0.610647618308.issue9752@psf.upfronthosting.co.za>
Message-ID: <1283506953.44.0.610647618308.issue9752@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

7>..\Python\import.c(1158) : warning C4013: 'mkdir' undefined; assuming extern returning int

----------
assignee: stutzbach
components: Interpreter Core, Windows
keywords: easy
messages: 115428
nosy: stutzbach
priority: low
severity: normal
stage: needs patch
status: open
title: MSVC Compiler warning in Python\import.c
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9752>
_______________________________________

From report at bugs.python.org  Fri Sep  3 12:16:06 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 03 Sep 2010 10:16:06 +0000
Subject: [New-bugs-announce] [issue9753] test_socket.testDup,
	testFromFd fail on Windows
In-Reply-To: <1283508966.85.0.609620029281.issue9753@psf.upfronthosting.co.za>
Message-ID: <1283508966.85.0.609620029281.issue9753@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

The errors below show up on my XP machine in Python 3.1 as well as a recent build from the py3k branch.  I'm not sure why they *don't* show up on the XP buildbot.

fromfd() ultimately calls dup(), so the underlying problem is likely the same for all the failures.  dup() support was added for Windows in issue1378.

======================================================================
ERROR: testDup (test.test_socket.BasicTCPTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python31\lib\test\test_socket.py", line 628, in testDup
    msg = sock.recv(1024)
socket.error: [Errno 10038] An operation was attempted on something that is not a socket

======================================================================
ERROR: testFromFd (test.test_socket.BasicTCPTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python31\lib\test\test_socket.py", line 619, in testFromFd
    msg = sock.recv(1024)
socket.error: [Errno 10038] An operation was attempted on something that is not a socket

======================================================================
ERROR: testDup (test.test_socket.BasicTCPTest2)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python31\lib\test\test_socket.py", line 628, in testDup
    msg = sock.recv(1024)
socket.error: [Errno 10045] The attempted operation is not supported for the type of object referenced

======================================================================
ERROR: testFromFd (test.test_socket.BasicTCPTest2)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python31\lib\test\test_socket.py", line 619, in testFromFd
    msg = sock.recv(1024)
socket.error: [Errno 10038] An operation was attempted on something that is not a socket

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

----------
components: Library (Lib), Windows
messages: 115432
nosy: brian.curtin, christian.heimes, roudkerk, stutzbach, tim.golden
priority: normal
severity: normal
status: open
title: test_socket.testDup, testFromFd fail on Windows
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9753>
_______________________________________

From report at bugs.python.org  Fri Sep  3 12:50:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 10:50:17 +0000
Subject: [New-bugs-announce] [issue9754] assertWarns and assertWarnsRegexp
In-Reply-To: <1283511017.36.0.0507272422338.issue9754@psf.upfronthosting.co.za>
Message-ID: <1283511017.36.0.0507272422338.issue9754@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Similar to assertRaises and assertRaisesRegexp, unittest should provide assertWarns and assertWarnsRegexp, to check that a given callable (or piece of code) triggers a particular warning.

Currently, you have to do that manually using a mixture of warnings.catch_warnings and warnings.filterwarnings, which is pretty annoying.

----------
components: Library (Lib)
messages: 115434
nosy: brett.cannon, michael.foord, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: assertWarns and assertWarnsRegexp
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9754>
_______________________________________

From report at bugs.python.org  Fri Sep  3 13:43:44 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 03 Sep 2010 11:43:44 +0000
Subject: [New-bugs-announce] [issue9755] Fix refcounting details in Py3k C
	API documentation
In-Reply-To: <1283514224.53.0.325600320074.issue9755@psf.upfronthosting.co.za>
Message-ID: <1283514224.53.0.325600320074.issue9755@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

As noted in [1] the refcount data for the C API documentation is contained in a separate file at Doc/data/refcounts.dat.

This file is not mentioned in "Documenting Python" and hence has not been correctly updated for Py3k (e.g. none of the PyString methods have been renamed to PyUnicode in that file, so the relevant refcount changes are not documented correctly).

There are several possible improvements to be considered in this area
1. Mention this file and its purpose in "Documenting Python"
2. Update the Sphinx extension to warn if a C API function is not found in this file
3. Update the Sphinx extension to allow this information to be expressed inline in the function definition rather than off in a separate file (if practical)
4. Address Skip's comment from that file by allowing "-0" to indicate stolen references for arguments and "+0" for borrowed references as return values
5. Perhaps add a mechanism to indicate when PyMem_Free needs to be called on a return value or pointer output value.

[1] http://mail.python.org/pipermail/python-dev/2010-September/103429.html

----------
messages: 115441
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Fix refcounting details in Py3k C API documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9755>
_______________________________________

From report at bugs.python.org  Fri Sep  3 14:13:04 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 03 Sep 2010 12:13:04 +0000
Subject: [New-bugs-announce] [issue9756] Crash with custom __getattribute__
In-Reply-To: <1283515984.36.0.673218996521.issue9756@psf.upfronthosting.co.za>
Message-ID: <1283515984.36.0.673218996521.issue9756@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

I found this crash while playing with proxies (thanks haypo).
http://code.activestate.com/recipes/496741-object-proxying/


class MyClass(object):

    def __init__(self):
        self.pwn = None

    def __getattribute__(self, name):
        print('MyClass.__getattribute__(self, %r)' % name)
        return getattr('abc', name)

instance = MyClass()
str.strip(instance)

----------
components: Interpreter Core
messages: 115446
nosy: flox, haypo
priority: normal
severity: normal
stage: needs patch
status: open
title: Crash with custom __getattribute__
type: crash
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9756>
_______________________________________

From report at bugs.python.org  Fri Sep  3 17:11:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 15:11:04 +0000
Subject: [New-bugs-announce] [issue9757] Add context manager protocol to
	memoryviews
In-Reply-To: <1283526664.21.0.538599282287.issue9757@psf.upfronthosting.co.za>
Message-ID: <1283526664.21.0.538599282287.issue9757@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This adds the context manager protocol to memoryview objects, as proposed on python-dev. Once the `with` block has finished, the underlying buffer is released and any operation on the memoryview raises a ValueError.

----------
components: Interpreter Core
files: memcontext.patch
keywords: patch
messages: 115459
nosy: pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Add context manager protocol to memoryviews
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file18729/memcontext.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9757>
_______________________________________

From report at bugs.python.org  Fri Sep  3 18:54:12 2010
From: report at bugs.python.org (Grzegorz Kulewski)
Date: Fri, 03 Sep 2010 16:54:12 +0000
Subject: [New-bugs-announce] [issue9758] ioctl mutable buffer copying problem
In-Reply-To: <1283532852.64.0.959169848478.issue9758@psf.upfronthosting.co.za>
Message-ID: <1283532852.64.0.959169848478.issue9758@psf.upfronthosting.co.za>


New submission from Grzegorz Kulewski <grzegorz at kulewski.pl>:

Hello,

It looks like something is broken in ioctl in 3.2 when the supplied (mutable) bytearray is exactly 1024 bytes long - the result is not copied into the buffer after the ioctl succedes:

def open_tuntap(type, name):
        TUN_TYPE = {
                'TUN' : 0x0001,
                'TAP' : 0x0002
        }

        TUNSETIFF = 0x400454ca

        dev = os.open('/dev/net/tun', os.O_RDWR)
        buf = bytearray(SET_LEN_HERE)
        name = name[:16]
        buf[:len(name)] = name
        buf[16:18] = TUN_TYPE[type].to_bytes(2, sys.byteorder)
        fcntl.ioctl(dev, TUNSETIFF, buf, True)
        print(buf)
        print(len(buf))

open_tuntap('TAP', b'madtun%d')

Now try it with SET_LEN_HERE = 1024, 1023, 1025 and any other values. For < 1024 it copies to the static buffer and back, for > 1024 it operates on the buffer itself (hopefully) and for 1024 it ignores the modified buffer completely. It's probably some corner case bug.

The example was tested under Linux 2.6.35.

Python 3.2a1+ (py3k:84054, Sep  3 2010, 01:45:35) 
[GCC 4.4.2] on linux2

----------
components: Library (Lib)
messages: 115467
nosy: gkulewski
priority: normal
severity: normal
status: open
title: ioctl mutable buffer copying problem
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9758>
_______________________________________

From report at bugs.python.org  Fri Sep  3 19:36:31 2010
From: report at bugs.python.org (Alain Kalker)
Date: Fri, 03 Sep 2010 17:36:31 +0000
Subject: [New-bugs-announce] [issue9759] GzipFile object should raise
	ValueError on .read() after	.close()
In-Reply-To: <1283535391.41.0.374921176114.issue9759@psf.upfronthosting.co.za>
Message-ID: <1283535391.41.0.374921176114.issue9759@psf.upfronthosting.co.za>


New submission from Alain Kalker <miki at dds.nl>:

>>> f = open("test2.gz")
>>> d = f.read()
>>> f.close()
>>> e = f.read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: I/O operation on closed file
import gzip
>>> f = gzip.open("test2.gz")
>>> d = f.read()
>>> f.close()
>>> e = f.read()
>>> e
''

To remain consistent with other file(-like) objects, I think 'GzipFile's should also raise a ValueError in cases like this.

----------
components: Library (Lib)
messages: 115473
nosy: ack
priority: normal
severity: normal
status: open
title: GzipFile object should raise ValueError on .read() after .close()
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9759>
_______________________________________

From report at bugs.python.org  Fri Sep  3 19:51:35 2010
From: report at bugs.python.org (Jason Baker)
Date: Fri, 03 Sep 2010 17:51:35 +0000
Subject: [New-bugs-announce] [issue9760] Suggestion for improving with
	documentation
In-Reply-To: <1283536295.47.0.948659460721.issue9760@psf.upfronthosting.co.za>
Message-ID: <1283536295.47.0.948659460721.issue9760@psf.upfronthosting.co.za>


New submission from Jason Baker <amnorvend at gmail.com>:

http://docs.python.org/reference/compound_stmts.html#with

This documentation refers to "context expressions" in two places.  However, it never really defines what a context expression is.  The formal syntax that's presented is this:

with_stmt ::=  "with" with_item ("," with_item)* ":" suite
with_item ::=  expression ["as" target]

As best I can tell, the context expression is essentially the with_item.  If that's the case, I propose one of the following:

 1) The formal syntax is changed so that "with_item" becomes "context_expression".
 2) References to "context expression" change to "with item".
 3) The "context expression" is defined to be the with_item in the formal syntax at some point in the documentation.

----------
assignee: docs at python
components: Documentation
messages: 115478
nosy: Jason.Baker, docs at python
priority: normal
severity: normal
status: open
title: Suggestion for improving with documentation
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9760>
_______________________________________

From report at bugs.python.org  Fri Sep  3 21:33:04 2010
From: report at bugs.python.org (Steve Thompson)
Date: Fri, 03 Sep 2010 19:33:04 +0000
Subject: [New-bugs-announce] [issue9761] stale .pyc files aren't cleaned out
In-Reply-To: <1283542384.36.0.244541121538.issue9761@psf.upfronthosting.co.za>
Message-ID: <1283542384.36.0.244541121538.issue9761@psf.upfronthosting.co.za>


New submission from Steve Thompson <steve.f.thompson at gmail.com>:

I'm running pythong 2.6.1 on Windows XP SP3.

On many occasions I have ran into cases where I've installed a new package via the package's setup.py (pylint, logilab-common, etc) and new .pyc files don't get generated when I attempt to run the tools/packages.  I'm not sure if this should be considered a package issue or an interpreter issue.  I'd like to see the interpreter regenerate the .pyc file as expected so my colleagues and I don't burn time on "broken" packages we know nothing about only to find out it was due to some stale .pyc files.  A quick fix would be to make the packages in question clean out their installation directories or regenerate all the pyc files manually.

How should this issue be handled?

----------
components: Interpreter Core, Windows
messages: 115488
nosy: Steve.Thompson
priority: normal
severity: normal
status: open
title: stale .pyc files aren't cleaned out
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9761>
_______________________________________

From report at bugs.python.org  Fri Sep  3 21:40:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 19:40:17 +0000
Subject: [New-bugs-announce] [issue9762] build failures
In-Reply-To: <1283542817.2.0.95523590272.issue9762@psf.upfronthosting.co.za>
Message-ID: <1283542817.2.0.95523590272.issue9762@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

After a `make distclean` and a whole recompile I still get these:

building 'crypt' extension
gcc -pthread -fPIC -g -O0 -Wall -Wstrict-prototypes -I. -I./Include -I/usr/local/include -IInclude -I/home/antoine/py3k/debug -c /home/antoine/py3k/debug/Modules/cryptmodule.c -o build/temp.linux-x86_64-3.2-pydebug/home/antoine/py3k/debug/Modules/cryptmodule.o
gcc -pthread -shared build/temp.linux-x86_64-3.2-pydebug/home/antoine/py3k/debug/Modules/cryptmodule.o -L/usr/local/lib -o build/lib.linux-x86_64-3.2-pydebug/crypt.cpython-32dm.so
*** WARNING: renaming "crypt" since importing it failed: build/lib.linux-x86_64-3.2-pydebug/crypt.cpython-32dm.so: undefined symbol: crypt

building 'nis' extension
gcc -pthread -fPIC -g -O0 -Wall -Wstrict-prototypes -I. -I./Include -I/usr/local/include -IInclude -I/home/antoine/py3k/debug -c /home/antoine/py3k/debug/Modules/nismodule.c -o build/temp.linux-x86_64-3.2-pydebug/home/antoine/py3k/debug/Modules/nismodule.o
gcc -pthread -shared build/temp.linux-x86_64-3.2-pydebug/home/antoine/py3k/debug/Modules/nismodule.o -L/usr/local/lib -o build/lib.linux-x86_64-3.2-pydebug/nis.cpython-32dm.so
*** WARNING: renaming "nis" since importing it failed: build/lib.linux-x86_64-3.2-pydebug/nis.cpython-32dm.so: undefined symbol: yp_get_default_domain

Failed to build these modules:
crypt              nis

----------
assignee: barry
components: Build
messages: 115489
nosy: barry, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: build failures
type: compile error
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9762>
_______________________________________

From report at bugs.python.org  Fri Sep  3 21:42:53 2010
From: report at bugs.python.org (William Barr)
Date: Fri, 03 Sep 2010 19:42:53 +0000
Subject: [New-bugs-announce] [issue9763] Crashes upon run after syntax error
	encountered in OSX	10.5.8
In-Reply-To: <1283542973.95.0.133487128669.issue9763@psf.upfronthosting.co.za>
Message-ID: <1283542973.95.0.133487128669.issue9763@psf.upfronthosting.co.za>


New submission from William Barr <webmaster961 at gmail.com>:

Steps for reproduction:
1.  Open a new code window
2.  Enter python code which contains a syntax error
3.  F5 and attempt to run the file (This was done without saving first)
4.  Close the syntax error dialog.  
5.  Fix the syntax error and try to F5 again without saving again.  
6.  IDLE will encounter an error and unexpectedly close.  

I'm reporting this after having tested this on 4 different OSX 10.5.8 machines.  I'm not sure if other versions of Python are also susceptible to this as well.

----------
components: IDLE
messages: 115491
nosy: Webs961
priority: normal
severity: normal
status: open
title: Crashes upon run after syntax error encountered in OSX 10.5.8
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9763>
_______________________________________

From report at bugs.python.org  Fri Sep  3 22:44:20 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 03 Sep 2010 20:44:20 +0000
Subject: [New-bugs-announce] [issue9764] Tools/buildbot/external.bat should
	download and built tix
In-Reply-To: <1283546660.96.0.0013695103683.issue9764@psf.upfronthosting.co.za>
Message-ID: <1283546660.96.0.0013695103683.issue9764@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

external.bat and external-common.bat take care of downloading most external packages such as tcl, tk, and openssl.  However, the tix package is missing, but needed to build the msi.

----------
components: Build, Windows
messages: 115503
nosy: loewis, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: Tools/buildbot/external.bat should download and built tix
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9764>
_______________________________________

From report at bugs.python.org  Fri Sep  3 22:46:17 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 03 Sep 2010 20:46:17 +0000
Subject: [New-bugs-announce] [issue9765] tcl-8 vs tcl8
In-Reply-To: <1283546777.07.0.320688875982.issue9765@psf.upfronthosting.co.za>
Message-ID: <1283546777.07.0.320688875982.issue9765@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

Tools/buildbot/external-common.bat creates tcl-8.5.2.1, but Tools/msi/msi.py looks for tcl8*.  Consequently, Tools/buildbot/buildmsi.py does not work on a fresh machine.

tk has the same problem.

I encountered this on the py3k branch but have not checked other branches.

Attached is a simple patch to Tools/msi/msi.py.

----------
components: Build, Windows
files: tcl.patch
keywords: patch
messages: 115504
nosy: loewis, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: tcl-8 vs tcl8
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file18740/tcl.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9765>
_______________________________________

From report at bugs.python.org  Fri Sep  3 22:48:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 20:48:55 +0000
Subject: [New-bugs-announce] [issue9766] warnings has "onceregistry" and
	"once_registry"
In-Reply-To: <1283546935.08.0.780554208103.issue9766@psf.upfronthosting.co.za>
Message-ID: <1283546935.08.0.780554208103.issue9766@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The warnings module has both "onceregistry" and "once_registry", while _warnings only has the latter. There's probably a typo.

----------
assignee: brett.cannon
components: Library (Lib)
messages: 115505
nosy: brett.cannon, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: warnings has "onceregistry" and "once_registry"
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9766>
_______________________________________

From report at bugs.python.org  Fri Sep  3 23:32:52 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Sep 2010 21:32:52 +0000
Subject: [New-bugs-announce] [issue9767] Failures in json doc examples
In-Reply-To: <1283549572.36.0.344374385965.issue9767@psf.upfronthosting.co.za>
Message-ID: <1283549572.36.0.344374385965.issue9767@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

I ran doctest on LibRef 17.2 json saved as .txt. There are 4 failures: 2 are clearly doc issues, the other 2 I do not know. I hope someone reads this who is already familiar

DOC PATCHES
    dumps(2 + 1j, cls=ComplexEncoder)
should be
    json.dumps(2 + 1j, cls=ComplexEncoder)
and
    JSONEncoder().encode({"foo": ["bar", "baz"]})
should be
    json.JSONEncoder().encode({"foo": ["bar", "baz"]})

Needing similar additions in example code (not caught by doctest) are
           return JSONEncoder.default(self, o)
        for chunk in JSONEncoder().iterencode(bigobject):

Those fixes leave 2 failures I an unclear about and hope a json expert will comment on.

1.'''
Failed example:
    print(json.dumps({'4': 5, '6': 7}, sort_keys=True, indent=4))
Expected:
    {
        "4": 5,
        "6": 7
    }
Got:
    {
        "4": 5, 
        "6": 7
    }
'''
The difference is that json puts a trailing space after '5,'. Should it? or should one be added to the doc?

2. '''
Failed example:
    list(ComplexEncoder().iterencode(2 + 1j))
Expected:
    ['[', '2.0', ', ', '1.0', ']']
Got:
    ['[2.0', ', 1.0', ']']
'''
Without knowing how the default iterencode interacts with the overwridden .default() method, I have no idea.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 115512
nosy: docs at python, terry.reedy
priority: normal
severity: normal
status: open
title: Failures in json doc examples
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9767>
_______________________________________

From report at bugs.python.org  Sat Sep  4 00:09:34 2010
From: report at bugs.python.org (Kristoffer F)
Date: Fri, 03 Sep 2010 22:09:34 +0000
Subject: [New-bugs-announce] [issue9768] IDLE / Black frame in active window
In-Reply-To: <1283551774.16.0.36540025292.issue9768@psf.upfronthosting.co.za>
Message-ID: <1283551774.16.0.36540025292.issue9768@psf.upfronthosting.co.za>


New submission from Kristoffer F <kkf628 at gmail.com>:

Hi 

I am new to python and have installed python 3.1.2. I have began using 
IDLE and like it very good. 

But when an IDLE window is active. There is a "thick" black frame around 
the white text field. Is this a know issue? And is there some way I can get rid of this frame? 

The frame is very distracting when I write. 

Kristoffer

----------
components: IDLE
messages: 115516
nosy: kfollesdal
priority: normal
severity: normal
status: open
title: IDLE / Black frame in active window
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9768>
_______________________________________

From report at bugs.python.org  Sat Sep  4 01:53:01 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Sep 2010 23:53:01 +0000
Subject: [New-bugs-announce] [issue9769] PyUnicode_FromFormatV() doesn't
	handle non-ascii text	correctly
In-Reply-To: <1283557981.28.0.85027629308.issue9769@psf.upfronthosting.co.za>
Message-ID: <1283557981.28.0.85027629308.issue9769@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

I'm trying to document the encoding of all bytes argument of the C API: see #9738. I tried to understand which encoding is used by PyUnicode_FromFormat*() (and PyErr_Format() which calls PyUnicode_FromFormatV()). It looks like ISO-8859-1, see unicodeobject.c near line 1106:

    for (f = format; *f; f++) {
        if (*f == '%') {
            ...
        } else
            *s++ = *f; <~~~~ here
    }

... oh wait, it doesn't work for non-ascii text! Test in gdb:

(gdb) print _PyObject_Dump(PyUnicodeUCS2_FromFormat("iso-8859-1:\xd0\xff"))
object  : 'iso-8859-1:\uffd0\uffff'
type    : str
refcount: 1
address : 0x83d5d80

b'\xd0\xff' is decoded '\uffd0\xffff' :-( It's a bug.

--

PyUnicode_FromFormatV() should raise an error on non-ascii format character, or decode it correctly as... ISO-8859-1 or something else. It's difficult to support multi byte encodings (like utf-8), ISO-8859-1 is fine. If we choose to raise an error, how can the user format a non-ascii string? Using its_unicode_format.format(...arguments...) or its_unicode_format % arguments? Is it easy to call these methods in C?

----------
components: Interpreter Core, Unicode
messages: 115542
nosy: haypo
priority: normal
severity: normal
status: open
title: PyUnicode_FromFormatV() doesn't handle non-ascii text correctly
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9769>
_______________________________________

From report at bugs.python.org  Sat Sep  4 02:01:49 2010
From: report at bugs.python.org (Kevin Thibedeau)
Date: Sat, 04 Sep 2010 00:01:49 +0000
Subject: [New-bugs-announce] [issue9770] curses.isblank function doesn't
	match ctype.h
In-Reply-To: <1283558509.74.0.494754089018.issue9770@psf.upfronthosting.co.za>
Message-ID: <1283558509.74.0.494754089018.issue9770@psf.upfronthosting.co.za>


New submission from Kevin Thibedeau <kevinpt at yahoo.com>:

The isblank() function defined in curses.ascii is incorrect and doesn't match the output from C's isblank() from ctype.h

Incorrect definition:
  def isblank(c): return _ctoi(c) in (8,32)

Should be:
  def isblank(c): return _ctoi(c) in (9,32)

This most likely affects all versions of Python, not just 2.7.

----------
components: Library (Lib)
messages: 115544
nosy: kevinpt
priority: normal
severity: normal
status: open
title: curses.isblank function doesn't match ctype.h
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9770>
_______________________________________

From report at bugs.python.org  Sat Sep  4 13:32:10 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 04 Sep 2010 11:32:10 +0000
Subject: [New-bugs-announce] [issue9771] add an optional "default" argument
	to	tokenize.detect_encoding
In-Reply-To: <1283599930.65.0.476914851505.issue9771@psf.upfronthosting.co.za>
Message-ID: <1283599930.65.0.476914851505.issue9771@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

The function tokenize.detect_encoding() detects the encoding either in the coding cookie or in the BOM.  If no encoding is found, it returns 'utf-8':

When result is 'utf-8', there's no (easy) way to know if the encoding was really detected in the file, or if it falls back to the default value.

Cases (with utf-8):

 - UTF-8 BOM found, returns ('utf-8-sig', [])
 - cookie on 1st line, returns ('utf-8', [line1])
 - cookie on 2nd line, returns ('utf-8', [line1, line2])
 - no cookie found, returns ('utf-8', [line1, line2])


The proposal is to allow to call the function with a different default value (None or ''), in order to know if the encoding is really detected.

For example, this function could be used by the Tools/scripts/findnocoding.py script.

Patch attached.

----------
components: Library (Lib)
files: detect_encoding_default.diff
keywords: patch
messages: 115567
nosy: flox
priority: normal
severity: normal
stage: patch review
status: open
title: add an optional "default" argument to tokenize.detect_encoding
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file18745/detect_encoding_default.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9771>
_______________________________________

From report at bugs.python.org  Sat Sep  4 14:01:25 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 04 Sep 2010 12:01:25 +0000
Subject: [New-bugs-announce] [issue9772] test_pep277 failure on AMD64 debian
	parallel buildbot
In-Reply-To: <1283601685.6.0.819525034936.issue9772@psf.upfronthosting.co.za>
Message-ID: <1283601685.6.0.819525034936.issue9772@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

This failure occurs on AMD64 debian parallel buildbot.
It is not the same failure as OS X Tiger buildbot (issue 8423).


======================================================================
FAIL: test_listdir (test.test_pep277.UnicodeFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/test_pep277.py", line 157, in test_listdir
    self.assertEqual(sf0, sf2)
AssertionError: Items in the first set but not the second:
'@test_21179_tmp/Gr????-Gott'
Items in the second set but not the first:
'@test_21179_tmp/Gr\udcfc\udcdf-Gott'

======================================================================
FAIL: test_listdir (test.test_pep277.UnicodeNFCFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/test_pep277.py", line 157, in test_listdir
    self.assertEqual(sf0, sf2)
AssertionError: Items in the first set but not the second:
'@test_21179_tmp/Gr????-Gott'
Items in the second set but not the first:
'@test_21179_tmp/Gr\udcfc\udcdf-Gott'

======================================================================
FAIL: test_listdir (test.test_pep277.UnicodeNFKCFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/test_pep277.py", line 157, in test_listdir
    self.assertEqual(sf0, sf2)
AssertionError: Items in the first set but not the second:
'@test_21179_tmp/Gr????-Gott'
Items in the second set but not the first:
'@test_21179_tmp/Gr\udcfc\udcdf-Gott'

----------------------------------------------------------------------
Ran 30 tests in 1.576s


http://www.python.org/dev/buildbot/builders/AMD64%20debian%20parallel%203.x/builds/94/steps/test/logs/stdio

----------
components: Tests, Unicode
keywords: buildbot
messages: 115568
nosy: flox
priority: normal
severity: normal
stage: needs patch
status: open
title: test_pep277 failure on AMD64 debian parallel buildbot
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9772>
_______________________________________

From report at bugs.python.org  Sat Sep  4 14:13:19 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 04 Sep 2010 12:13:19 +0000
Subject: [New-bugs-announce] [issue9773] test_tarfile fails because of
	inaccurate mtime on AMD64	debian parallel buildbot
In-Reply-To: <1283602399.09.0.660649968872.issue9773@psf.upfronthosting.co.za>
Message-ID: <1283602399.09.0.660649968872.issue9773@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

Occurs repeatedly on AMD64 debian parallel.

======================================================================
FAIL: test_extractall (test.test_tarfile.MiscReadTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/test_tarfile.py", line 331, in test_extractall
    self.assertEqual(tarinfo.mtime, os.path.getmtime(path))
AssertionError: 1041808783 != 1041808783.000001

======================================================================
FAIL: test_extractall (test.test_tarfile.GzipMiscReadTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/test_tarfile.py", line 331, in test_extractall
    self.assertEqual(tarinfo.mtime, os.path.getmtime(path))
AssertionError: 1041808783 != 1041808783.000003

======================================================================
FAIL: test_extractall (test.test_tarfile.Bz2MiscReadTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/test_tarfile.py", line 331, in test_extractall
    self.assertEqual(tarinfo.mtime, os.path.getmtime(path))
AssertionError: 1041808783 != 1041808783.000005

----------------------------------------------------------------------
Ran 230 tests in 6.681s

FAILED (failures=3)
test test_tarfile crashed -- <class 'OSError'>: [Errno 16] Device or resource busy: '/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/build/test_python_21179/@test_21179_tmp/.nfs000000000004f3b30000060b'
Traceback (most recent call last):
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/test_tarfile.py", line 1560, in test_main
    support.run_unittest(*tests)
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/support.py", line 1078, in run_unittest
    _run_suite(suite)
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/support.py", line 1061, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: multiple errors occurred

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 942, in runtest_inner
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/test_tarfile.py", line 1563, in test_main
    shutil.rmtree(TEMPDIR)
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/shutil.py", line 283, in rmtree
    onerror(os.remove, fullname, sys.exc_info())
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/shutil.py", line 281, in rmtree
    os.remove(fullname)
OSError: [Errno 16] Device or resource busy: '/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/build/test_python_21179/@test_21179_tmp/.nfs000000000004f3b30000060b'

http://www.python.org/dev/buildbot/builders/AMD64%20debian%20parallel%203.x/builds/94

----------
components: Tests
keywords: buildbot
messages: 115569
nosy: flox
priority: normal
severity: normal
stage: needs patch
status: open
title: test_tarfile fails because of inaccurate mtime on AMD64 debian parallel buildbot
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9773>
_______________________________________

From report at bugs.python.org  Sat Sep  4 14:22:07 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 04 Sep 2010 12:22:07 +0000
Subject: [New-bugs-announce] [issue9774] test_smtpnet fails with "[110]
	Connection timed out" on	AMD64 debian parallel buildbot
In-Reply-To: <1283602927.92.0.540080511811.issue9774@psf.upfronthosting.co.za>
Message-ID: <1283602927.92.0.540080511811.issue9774@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

Repeated failure on AMD64 debian parallel buildbot.

[329/346] test_smtpnet
test test_smtpnet failed -- Traceback (most recent call last):
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/test_smtpnet.py", line 15, in test_connect
    server = smtplib.SMTP_SSL(self.testServer, self.remotePort)
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/smtplib.py", line 758, in __init__
    SMTP.__init__(self, host, port, local_hostname, timeout)
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/smtplib.py", line 239, in __init__
    (code, msg) = self.connect(host, port)
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/smtplib.py", line 295, in connect
    self.sock = self._get_socket(host, port, self.timeout)
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/smtplib.py", line 763, in _get_socket
    new_socket = socket.create_connection((host, port), timeout)
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/socket.py", line 319, in create_connection
    raise error(msg)
socket.error: [Errno 110] Connection timed out

http://www.python.org/dev/buildbot/builders/AMD64%20debian%20parallel%203.x/builds/94

----------
components: Tests
messages: 115570
nosy: flox
priority: normal
severity: normal
stage: needs patch
status: open
title: test_smtpnet fails with "[110] Connection timed out" on AMD64 debian parallel buildbot
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9774>
_______________________________________

From report at bugs.python.org  Sat Sep  4 17:32:09 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Sat, 04 Sep 2010 15:32:09 +0000
Subject: [New-bugs-announce] [issue9775] Multiprocessing,
	logging and atexit play not well together
In-Reply-To: <1283614329.92.0.49636905905.issue9775@psf.upfronthosting.co.za>
Message-ID: <1283614329.92.0.49636905905.issue9775@psf.upfronthosting.co.za>


New submission from Armin Ronacher <armin.ronacher at active-4.com>:

It's hard to say what exactly is to blame here, but I will try to outline the problem as good as I can and try to track it down:

A library of mine is using a Thread that is getting entries from a multiprocessing.Queue periodically.  What I find when the python interpreter is shutting down is this on stderr:

Error in sys.exitfunc:
Traceback (most recent call last):
  File "python2.6/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "python2.6/multiprocessing/util.py", line 270, in _exit_function
    info('process shutting down')
TypeError: 'NoneType' object is not callable

Tracking down the issue shows that something has a __del__ [i have not found the object, i was under the impression the ProcessAwareLogger monkeypatch was, but apprently it's not the culprit] and clears out the module.  When the exit handler is running info is already set to None.  It can be easily checked if that is the issue when a weird monkepatch is added:

def fix_logging_in_multiprocesing():
    from multiprocessing import util, process
    import logging
    util._check_logger_class()
    old_class = logging.getLoggerClass()
    def __del__(self):
        util.info = util.debug = lambda *a, **kw: None
        process._cleanup = lambda *a, **kw: None
    old_class.__del__ = __del__
  
I originally thought that the destructor of the ProcessAwareLogger class was the issue, but apparently not so because it does not have one.

Interestingly if one looks into the util.py module the following comment can be found:

def _check_logger_class():
    '''
    Make sure process name is recorded when loggers are used
    '''
    # XXX This function is unnecessary once logging is patched
    import logging
    if hasattr(logging, 'multiprocessing'):
        return
    ...

This is interesting because the logging monkeypatch is unused if logging is multiprocessing aware (which it should be in 2.6 at least).  However apparently at one point the toplevel multiprocessing import was removed which makes this test fall all the time.  Looking at the current 26 branch it appears that the monkeypatch was removed by jesse noller in [68737] over a year ago.

With the current development version (and I suppose a later release than 2.6.1 which I am currently testing) the error disappears as well.

However the core issue would come back as soon as the atexit call moves past a destructor again I suppose.  Because of that I would recommend aliasing info to _info and debug to _debug and then calling the underscored methods in the atexit handler.

Any reasons for not doing that?  Otherwise I would like to propose committing that patch.

----------
components: Library (Lib)
messages: 115578
nosy: aronacher
priority: normal
severity: normal
status: open
title: Multiprocessing, logging and atexit play not well together
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9775>
_______________________________________

From report at bugs.python.org  Sat Sep  4 17:57:08 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 04 Sep 2010 15:57:08 +0000
Subject: [New-bugs-announce] [issue9776] Inconsistent spacing in fcntl.fcntl
	docstring
In-Reply-To: <1283615828.17.0.964870505124.issue9776@psf.upfronthosting.co.za>
Message-ID: <1283615828.17.0.964870505124.issue9776@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

The spacing in fcntl.fcntl's docstring isn't consistent, the attached patch fixes this.

----------
assignee: docs at python
components: Documentation
files: fcntl_docstring_spacing.patch
keywords: patch
messages: 115582
nosy: bbrazil, docs at python
priority: normal
severity: normal
status: open
title: Inconsistent spacing in fcntl.fcntl docstring
versions: Python 3.2
Added file: http://bugs.python.org/file18749/fcntl_docstring_spacing.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9776>
_______________________________________

From report at bugs.python.org  Sat Sep  4 20:10:18 2010
From: report at bugs.python.org (David Watson)
Date: Sat, 04 Sep 2010 18:10:18 +0000
Subject: [New-bugs-announce] [issue9777]
	test_socket.GeneralModuleTests.test_idna should require	the
	"network" resource
In-Reply-To: <1283623818.68.0.121585037056.issue9777@psf.upfronthosting.co.za>
Message-ID: <1283623818.68.0.121585037056.issue9777@psf.upfronthosting.co.za>


New submission from David Watson <baikie at users.sourceforge.net>:

This test requires network access as it tries to resolve a domain name at python.org.  Patch attached.

----------
components: Tests
files: idna-test-resource.diff
keywords: patch
messages: 115593
nosy: baikie
priority: normal
severity: normal
status: open
title: test_socket.GeneralModuleTests.test_idna should require the "network" resource
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file18751/idna-test-resource.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9777>
_______________________________________

From report at bugs.python.org  Sun Sep  5 00:11:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 22:11:31 +0000
Subject: [New-bugs-announce] [issue9778] Make hash values the same width as
	a pointer (or	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Currently, Python produces hash values with fit in a C "long". This is fine at first sight, but in the context of dict and set implementations, it means that
1) holding hashes and indices in the same field of a structure requires some care (see issue1646068)
2) on platforms where a long is smaller than a Py_ssize_t (e.g. Win64), very big hash tables could suffer from lots of artificial collisions (the hash table being bigger than the range of possible hash values)
3) when a long is smaller than Py_ssize_t, we don't save any size anyway, since having some pointers follow a C "long" in a structure implies some padding to keep all fields naturally aligned

A future-proof option would be to change all hash values to be of Py_ssize_t values rather than C longs. Either directly, or by defining a new dedicated alias Py_hash_t. This would also impact the ABI, I suppose.

----------
components: Interpreter Core
messages: 115617
nosy: belopolsky, georg.brandl, jimjjewett, ked-tao, loewis, mark.dickinson, pitrou, rhettinger, tim_one
priority: normal
severity: normal
status: open
title: Make hash values the same width as a pointer (or Py_ssize_t)
type: feature request
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Sun Sep  5 09:36:10 2010
From: report at bugs.python.org (gkraser)
Date: Sun, 05 Sep 2010 07:36:10 +0000
Subject: [New-bugs-announce] [issue9779] argparse.ArgumentParser not support
	unicode in print help
In-Reply-To: <1283672170.42.0.322683308746.issue9779@psf.upfronthosting.co.za>
Message-ID: <1283672170.42.0.322683308746.issue9779@psf.upfronthosting.co.za>


New submission from gkraser <gkraser at gmail.com>:

argparse.ArgumentParser not support unicode in print help.

Example:

# -*- coding: utf-8 -*-
import argparse
import unittest

class Test1(unittest.TestCase):
    def test_unicode_desc(self):
        h = u'Rus ???'      # unicode
        print h             # ok
        parser = argparse.ArgumentParser(description=h)
        parser.print_help() # error

----------
components: Library (Lib)
files: test_ap.py
messages: 115630
nosy: gkraser
priority: normal
severity: normal
status: open
title: argparse.ArgumentParser not support unicode in print help
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file18757/test_ap.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9779>
_______________________________________

From report at bugs.python.org  Mon Sep  6 02:11:23 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 06 Sep 2010 00:11:23 +0000
Subject: [New-bugs-announce] [issue9780] fill character cannot be '{'
In-Reply-To: <1283731883.01.0.461973913755.issue9780@psf.upfronthosting.co.za>
Message-ID: <1283731883.01.0.461973913755.issue9780@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

According to the documentation:
"The fill character can be any character other than ?}? (which signifies the end of the field)."
http://docs.python.org/dev/library/string.html#format-specification-mini-language


However the format() builtin accepts both '{' and '}' characters:

>>> format(42, '}^6')
'}}42}}'

>>> format(42, '{^6')
'{{42{{'


And the string method rejects both characters.

>>> '{:}^6}'.format(42)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Single '}' encountered in format string

>>> '{:{^6}'.format(42)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: unmatched '{' in format

----------
assignee: docs at python
components: Documentation
messages: 115678
nosy: docs at python, flox
priority: normal
severity: normal
stage: needs patch
status: open
title: fill character cannot be '{'
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9780>
_______________________________________

From report at bugs.python.org  Mon Sep  6 14:41:02 2010
From: report at bugs.python.org (Arialdo Martini)
Date: Mon, 06 Sep 2010 12:41:02 +0000
Subject: [New-bugs-announce] [issue9781] Dead link
In-Reply-To: <1283776862.85.0.667935106717.issue9781@psf.upfronthosting.co.za>
Message-ID: <1283776862.85.0.667935106717.issue9781@psf.upfronthosting.co.za>


New submission from Arialdo Martini <arialdo.martini at gmail.com>:

In the Italian version of the Official  Turorial, the link to  Python Bug Tracker is dead.

----------
assignee: docs at python
components: Documentation
messages: 115698
nosy: Arialdo.Martini, docs at python
priority: normal
severity: normal
status: open
title: Dead link
type: resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9781>
_______________________________________

From report at bugs.python.org  Mon Sep  6 14:43:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Sep 2010 12:43:05 +0000
Subject: [New-bugs-announce] [issue9782] _multiprocessing.c warnings under
	64-bit Windows
In-Reply-To: <1283776985.14.0.464453735202.issue9782@psf.upfronthosting.co.za>
Message-ID: <1283776985.14.0.464453735202.issue9782@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

There are various warnings when compiling the _multiprocessing extension in 64-bit mode under Windows. Many seem related to the fact that read() and friends under Windows take "int" size arguments rather than "size_t".

20>------ Build started: Project: _multiprocessing, Configuration: Release x64 ------
20>Compiling...
20>multiprocessing.c
20>win32_functions.c
20>socket_connection.c
20>..\Modules\_multiprocessing\socket_connection.c(32) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
20>..\Modules\_multiprocessing\socket_connection.c(54) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data
20>..\Modules\_multiprocessing\socket_connection.c(126) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>..\Modules\_multiprocessing\socket_connection.c(137) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>..\Modules\_multiprocessing\socket_connection.c(145) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(139) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(183) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(237) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(285) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(323) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>semaphore.c
20>pipe_connection.c
20>..\Modules\_multiprocessing\pipe_connection.c(24) : warning C4267: 'function' : conversion from 'size_t' to 'DWORD', possible loss of data
20>..\Modules\_multiprocessing\pipe_connection.c(50) : warning C4267: 'function' : conversion from 'size_t' to 'DWORD', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(139) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(183) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(237) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(285) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>z:\py3k\__svn__\modules\_multiprocessing\connection.h(323) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
20>Linking...
20>   Creating library Z:\py3k\__svn__\PCbuild\\amd64\\_multiprocessing.lib and object Z:\py3k\__svn__\PCbuild\\amd64\\_multiprocessing.exp
20>Generating code
20>Finished generating code
20>Build log was saved at "file://Z:\py3k\__svn__\PCbuild\x64-temp-Release\_multiprocessing\BuildLog.htm"
20>_multiprocessing - 0 error(s), 17 warning(s)

----------
components: Extension Modules, Windows
messages: 115699
nosy: brian.curtin, jnoller, pitrou, tim.golden
priority: normal
severity: normal
stage: needs patch
status: open
title: _multiprocessing.c warnings under 64-bit Windows
type: compile error
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9782>
_______________________________________

From report at bugs.python.org  Mon Sep  6 14:49:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Sep 2010 12:49:53 +0000
Subject: [New-bugs-announce] [issue9783] _elementtree.c warnings under
	64-bit Windows
In-Reply-To: <1283777393.95.0.65520363014.issue9783@psf.upfronthosting.co.za>
Message-ID: <1283777393.95.0.65520363014.issue9783@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Some of these warnings could be serious (e.g. the one where the 64-bit "self" is converted to a 32-bit "long"):

13>..\Modules\_elementtree.c(696) : warning C4244: 'function' : conversion from 'Py_uintptr_t' to 'long', possible loss of data
13>..\Modules\_elementtree.c(1239) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
13>..\Modules\_elementtree.c(1372) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
13>..\Modules\_elementtree.c(1414) : warning C4244: '+=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
13>..\Modules\_elementtree.c(2076) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
13>..\Modules\_elementtree.c(2663) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data

----------
components: Extension Modules, Windows
messages: 115700
nosy: effbot, flox, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: _elementtree.c warnings under 64-bit Windows
type: compile error
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9783>
_______________________________________

From report at bugs.python.org  Mon Sep  6 14:55:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 06 Sep 2010 12:55:42 +0000
Subject: [New-bugs-announce] [issue9784] _msi.c warnings under 64-bit Windows
In-Reply-To: <1283777742.83.0.840213462008.issue9784@psf.upfronthosting.co.za>
Message-ID: <1283777742.83.0.840213462008.issue9784@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I'm posting this in case it is a sign of a problem. Apparently some variable named "hf" is an INT_PTR used as an int (according to Visual Studio), but "hf" doesn't seem to be defined or declared in _msi.c at all.

12>..\PC\_msi.c(66) : warning C4244: 'function' : conversion from 'INT_PTR' to 'int', possible loss of data
12>..\PC\_msi.c(74) : warning C4244: 'function' : conversion from 'INT_PTR' to 'int', possible loss of data
12>..\PC\_msi.c(82) : warning C4244: 'function' : conversion from 'INT_PTR' to 'int', possible loss of data
12>..\PC\_msi.c(90) : warning C4244: 'function' : conversion from 'INT_PTR' to 'int', possible loss of data

----------
components: Extension Modules
messages: 115701
nosy: loewis, pitrou
priority: normal
severity: normal
status: open
title: _msi.c warnings under 64-bit Windows
type: compile error
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9784>
_______________________________________

From report at bugs.python.org  Mon Sep  6 15:25:11 2010
From: report at bugs.python.org (Trigve Siver)
Date: Mon, 06 Sep 2010 13:25:11 +0000
Subject: [New-bugs-announce] [issue9785] _PyUnicode_New(),
	throw and memory problem
In-Reply-To: <1283779511.86.0.882093197661.issue9785@psf.upfronthosting.co.za>
Message-ID: <1283779511.86.0.882093197661.issue9785@psf.upfronthosting.co.za>


New submission from Trigve Siver <trigves at gmail.com>:

I'm using C++ with python embeding.
I'm creating a couple of unicode objects and then some
exception is thrown. While handling exception I create othet unicode objects. Then when creating some unicode object crash occurs. The problem is in _PyUnicode_New():325 on line (1):

if (free_list) {
    unicode = free_list; /*<- (1)*/
    free_list = *(PyUnicodeObject **)unicode;

In statement "unicode = free_list;" "unicode" pointer is bad pointer, in fact it's address is 5 bytes "lower" (i.e. should be 0x030bc3ff but is 0x030bc3fa).

It looks like this only happens when exception is thrown.

When python exception is set I throw C++ exception to signal C++ code that py exception was set. Next in C++ exception handler I format the python exception using some python unicode objects and then the problem occurs.
Without the C++ throw (Only python exception formatting) it looks like everything is working OK.

I'm using python 3.1.2 on Vista with MSVS 2010. I've also tried python 3.2a2 but it was the same.

I've tried to isolate the problem in some simple example but haven't been successful yet.

----------
components: Library (Lib)
messages: 115702
nosy: Trigve.Siver
priority: normal
severity: normal
status: open
title: _PyUnicode_New(), throw and memory problem
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9785>
_______________________________________

From report at bugs.python.org  Tue Sep  7 07:28:56 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 07 Sep 2010 05:28:56 +0000
Subject: [New-bugs-announce] [issue9786] Native TLS support for pthreads
In-Reply-To: <1283837336.62.0.212146968868.issue9786@psf.upfronthosting.co.za>
Message-ID: <1283837336.62.0.212146968868.issue9786@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

The following patch adds native TLS implementation for pthreads, avoiding the relatively slow and clunky default tls implemented in thread.c

----------
components: Interpreter Core
files: pthread_tls.patch
keywords: needs review, patch, patch
messages: 115742
nosy: krisvale
priority: normal
severity: normal
status: open
title: Native TLS support for pthreads
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file18781/pthread_tls.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9786>
_______________________________________

From report at bugs.python.org  Tue Sep  7 08:03:06 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 07 Sep 2010 06:03:06 +0000
Subject: [New-bugs-announce] [issue9787] Release the TLS lock during
	allocations
In-Reply-To: <1283839386.17.0.522591872287.issue9787@psf.upfronthosting.co.za>
Message-ID: <1283839386.17.0.522591872287.issue9787@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

Holding the "keymutex" lock during malloc and free operations is not a good idea.  The reason is, that custom implementations of malloc and free, can use the TLS themselves.  This is, for example, true in embedded situations, where one wants to replace malloc with, e.g. appMalloc, (to monitor the memory useage of Python) and appMalloc itself uses python TLS to find the current python State.

This change makes the malloc and free calls outside the lock.  The change in PyThread_set_key_value, requiring an extra lock allocate, has no significant performance impact since this is a rare api.

----------
components: Interpreter Core
files: tlspatch.patch
keywords: patch, patch
messages: 115743
nosy: krisvale
priority: normal
severity: normal
status: open
title: Release the TLS lock during allocations
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file18782/tlspatch.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9787>
_______________________________________

From report at bugs.python.org  Tue Sep  7 12:27:14 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 07 Sep 2010 10:27:14 +0000
Subject: [New-bugs-announce] [issue9788] atexit and execution order
In-Reply-To: <1283855234.53.0.604946356676.issue9788@psf.upfronthosting.co.za>
Message-ID: <1283855234.53.0.604946356676.issue9788@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

import atexit

@atexit.register
def goodbye1():
    print(1)
    
@atexit.register
def goodbye2():
    print(2)

The code above prints:

2
1

...that is, the last registered function is executed first.
Wouldn't the contrary be better?

----------
components: Library (Lib)
messages: 115747
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: atexit and execution order
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9788>
_______________________________________

From report at bugs.python.org  Tue Sep  7 14:53:15 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 07 Sep 2010 12:53:15 +0000
Subject: [New-bugs-announce] [issue9789] Explicit buffer release for
	memoryview objects
In-Reply-To: <1283863995.38.0.252730681612.issue9789@psf.upfronthosting.co.za>
Message-ID: <1283863995.38.0.252730681612.issue9789@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

memoryview objects currently offer no way to explicitly release the underlying buffer.

This may cause problems for mutable objects that are locked while PEP 3118 buffer references remain unreleased (e.g. in 3.2, io.BytesIO supports getbuffer() for direct access to the underlying memory, but disallows resizing until the associated memoryview goes away).

This isn't too bad in CPython due to explicit refcounting, but may be an issue when using other implementations since the time between release of the last reference and actual garbage collection is indeterminate. For example, the new test_getbuffer in the BytesIOMixin class in the test suite relies on "del buf" promptly releasing the underlying PEP 3118 buffer, which may not be the case on other implementations.

So there are two separate questions here:
1. Whether or not to add an explicit "release()" method to memoryview objects (this would be sufficient to address the problem)
2. Whether or not to add direct context management support to memoryview objects (this isn't really necessary, since a short context manager can do the same thing, but may be a nice convenience)

Nosy list members added based on relevant python-dev discussion where GvR previously nixed part 2 of the idea. At the time, I hadn't really separated the two questions properly in my mind, but I suspect the failing to do something about the first one will prove problematic in the long run (or even the short run, as the test suite issue suggests).

----------
messages: 115753
nosy: gvanrossum, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: Explicit buffer release for memoryview objects
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9789>
_______________________________________

From report at bugs.python.org  Tue Sep  7 15:44:03 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 07 Sep 2010 13:44:03 +0000
Subject: [New-bugs-announce] [issue9790] ntpath contains imports inside
	functions
In-Reply-To: <1283867043.1.0.607515525376.issue9790@psf.upfronthosting.co.za>
Message-ID: <1283867043.1.0.607515525376.issue9790@psf.upfronthosting.co.za>


New submission from Brian Curtin <curtin at acm.org>:

As pointed out by Nick Coghlan on python-dev, ntpath.samefile and ntpath.sameopenfile are vulnerable to deadlock because they contain imports.

----------
assignee: brian.curtin
components: Extension Modules, Windows
files: review_email.txt
messages: 115761
nosy: brian.curtin
priority: normal
severity: normal
stage: needs patch
status: open
title: ntpath contains imports inside functions
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file18783/review_email.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9790>
_______________________________________

From report at bugs.python.org  Tue Sep  7 20:47:29 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 07 Sep 2010 18:47:29 +0000
Subject: [New-bugs-announce] [issue9791] nntplib.py lacks a test suite
In-Reply-To: <1283885249.67.0.188742256424.issue9791@psf.upfronthosting.co.za>
Message-ID: <1283885249.67.0.188742256424.issue9791@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

A very simple test suite which tests at least basic features and methods should be written.
test_ftplib.py and test_smtplib.py can be taken as an example.
Assigning this to me as a reminder.

----------
assignee: giampaolo.rodola
components: Tests
messages: 115792
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: nntplib.py lacks a test suite
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9791>
_______________________________________

From report at bugs.python.org  Tue Sep  7 21:50:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Sep 2010 19:50:14 +0000
Subject: [New-bugs-announce] [issue9792] create_connection() recasts timeout
	errors
In-Reply-To: <1283889014.5.0.630828935384.issue9792@psf.upfronthosting.co.za>
Message-ID: <1283889014.5.0.630828935384.issue9792@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

When you call socket.create_connection() and it fails because it hits the socket timeout, the socket.timeout error is recast as a generic socket.error, which makes analyzing the failure more difficult (also, it means the "errno" attribute is lost for other types of errors):

>>> socket.setdefaulttimeout(0.000001)
>>> s = socket.socket()
>>> s.connect(("www.yahoo.fr", 80))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
socket.timeout: timed out
>>> socket.create_connection(("www.yahoo.fr", 80))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/py3k/__svn__/Lib/socket.py", line 319, in create_connection
    raise err
socket.error: timed out

----------
components: Library (Lib)
messages: 115798
nosy: exarkun, facundobatista, giampaolo.rodola, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: create_connection() recasts timeout errors
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9792>
_______________________________________

From report at bugs.python.org  Tue Sep  7 22:14:25 2010
From: report at bugs.python.org (Dag Odenhall)
Date: Tue, 07 Sep 2010 20:14:25 +0000
Subject: [New-bugs-announce] [issue9793] Typo fix in What's New for 3.2:
	dynmaic -> dynamic
In-Reply-To: <1283890465.04.0.275401316638.issue9793@psf.upfronthosting.co.za>
Message-ID: <1283890465.04.0.275401316638.issue9793@psf.upfronthosting.co.za>


New submission from Dag Odenhall <dag.odenhall at gmail.com>:

Spotted a typo reading the What's New for 3.2a2 and thought I should give contributing a fix a try. Please excuse me if I failed to follow some procedure; this is my first contribution to the core source tree.

----------
assignee: docs at python
components: Documentation
files: dynmaic.patch
keywords: patch
messages: 115800
nosy: dag.odenhall, docs at python
priority: normal
severity: normal
status: open
title: Typo fix in What's New for 3.2: dynmaic -> dynamic
versions: Python 3.2
Added file: http://bugs.python.org/file18786/dynmaic.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9793>
_______________________________________

From report at bugs.python.org  Wed Sep  8 00:23:55 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 07 Sep 2010 22:23:55 +0000
Subject: [New-bugs-announce] [issue9794] socket.create_connection context
	manager
In-Reply-To: <1283898235.48.0.353601830008.issue9794@psf.upfronthosting.co.za>
Message-ID: <1283898235.48.0.353601830008.issue9794@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

Patch in attachment adds a context manager to socket.socket class so that  socket.create_connection() can be used with "with" statement.

----------
components: Library (Lib)
files: socket_ctx_mgr.patch
keywords: patch
messages: 115812
nosy: amaury.forgeotdarc, giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: socket.create_connection context manager
versions: Python 3.2
Added file: http://bugs.python.org/file18789/socket_ctx_mgr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9794>
_______________________________________

From report at bugs.python.org  Wed Sep  8 00:42:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 07 Sep 2010 22:42:55 +0000
Subject: [New-bugs-announce] [issue9795] nntplib.NNTP should support the
	context protocol
In-Reply-To: <1283899375.28.0.82339837152.issue9795@psf.upfronthosting.co.za>
Message-ID: <1283899375.28.0.82339837152.issue9795@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

As the title says. __exit__() simply has to call self.quit(), AFAICT.

----------
components: Library (Lib)
messages: 115815
nosy: pitrou
priority: normal
severity: normal
status: open
title: nntplib.NNTP should support the context protocol
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9795>
_______________________________________

From report at bugs.python.org  Wed Sep  8 02:43:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 00:43:41 +0000
Subject: [New-bugs-announce] [issue9796] Add summary tables for unittest API
In-Reply-To: <1283906621.68.0.367606257735.issue9796@psf.upfronthosting.co.za>
Message-ID: <1283906621.68.0.367606257735.issue9796@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Suggestion from Raymond: Add a table summarizing all assert* methods of TestCase. I will make a patch in some days or weeks. I think I?ll also add one table for the most useful objects from a user viewpoint (Loader, TestCase, main). See the docs of itertools and collections for examples of such summary tables.

----------
assignee: eric.araujo
components: Documentation
messages: 115833
nosy: eric.araujo, michael.foord, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Add summary tables for unittest API
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9796>
_______________________________________

From peter.mcclintock at att.net  Fri Sep  3 22:24:34 2010
From: peter.mcclintock at att.net (Peter McClintock)
Date: Fri, 3 Sep 2010 13:24:34 -0700
Subject: [New-bugs-announce] [issue7549] 2.6.4 Win32 linked to debug
	DLLs?
In-Reply-To: <1261267523.81.0.700619941365.issue7549@psf.upfronthosting.co.za>
Message-ID: <3458A6EC4BA041518B24CD19A46A12A3@e9180f>

I have an HP 64bit system running Windows 7 and it has logged 136 SideBySide event 33's over the past 9 months related to :\program files (x86)\Python\Lib\distutils\command\wininst-8_d.exe.

Who are Python and what is SideBySide?

Thanks
        

        

        

        

        

        

        

        

        
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20100903/ccb17b36/attachment.html>

From report at bugs.python.org  Wed Sep  8 13:11:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Sep 2010 11:11:21 +0000
Subject: [New-bugs-announce] [issue9797] wrong assumption in pystate.c
In-Reply-To: <1283944281.59.0.280980525234.issue9797@psf.upfronthosting.co.za>
Message-ID: <1283944281.59.0.280980525234.issue9797@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

pystate.c assumes that when autoTLSkey is 0, it hasn't been created yet. However, some TLS implementations can return 0 as a valid key value. Lots of interesting things then happen.

Here is a patch.

----------
files: autotlskey.patch
keywords: patch
messages: 115858
nosy: amaury.forgeotdarc, krisvale, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: wrong assumption in pystate.c
type: crash
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file18794/autotlskey.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9797>
_______________________________________

From report at bugs.python.org  Wed Sep  8 14:41:36 2010
From: report at bugs.python.org (Peter Simons)
Date: Wed, 08 Sep 2010 12:41:36 +0000
Subject: [New-bugs-announce] [issue9798] time.tzset() doesn't properly reset
	the time.timezone	variable
In-Reply-To: <1283949696.36.0.623259626087.issue9798@psf.upfronthosting.co.za>
Message-ID: <1283949696.36.0.623259626087.issue9798@psf.upfronthosting.co.za>


New submission from Peter Simons <simons at cryp.to>:

Attached are two programs that I would expect to produce the same output, but they don't.

$ python --version
Python 2.6.5

$ cat test-timezone-1.py 
import os, time

os.environ["TZ"] = "Europe/Berlin"
time.tzset()
print "time.timezone =", time.timezone

os.environ["TZ"] = "Egypt"
time.tzset()
print "time.timezone =", time.timezone

$ cat test-timezone-2.py 
import os
from time import tzset, timezone

os.environ["TZ"] = "Europe/Berlin"
tzset()
print "timezone =", timezone

os.environ["TZ"] = "Egypt"
tzset()
print "timezone =", timezone

$ python test-timezone-1.py 
time.timezone = -3600
time.timezone = -7200

$ python test-timezone-2.py 
timezone = -3600
timezone = -3600

----------
components: Library (Lib)
messages: 115864
nosy: simons
priority: normal
severity: normal
status: open
title: time.tzset() doesn't properly reset the time.timezone variable
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9798>
_______________________________________

From report at bugs.python.org  Wed Sep  8 16:23:38 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 08 Sep 2010 14:23:38 +0000
Subject: [New-bugs-announce] [issue9799] Compilation error for branch py3k
	on AIX 6
In-Reply-To: <1283955818.3.0.940664068867.issue9799@psf.upfronthosting.co.za>
Message-ID: <1283955818.3.0.940664068867.issue9799@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

I have the following error when compiling the last rev of branch py3k on an AIX 6 system:

./Modules/makexp_aix Modules/python.exp . libpython3.2.a;  xlc_r -L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib -L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib -L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib -L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib  -L/sgbd_product/oracle/10.2.0/lib32 -L/sgbd_product/oracle/10.2.0/lib32 -L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib -L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib -L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib -L/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/target/support/lib  -L/sgbd_product/oracle/10.2.0/lib32 -L/sgbd_product/oracle/10.2.0/lib32 -Wl,-bE:Modules/python.exp -lld -o python Modules/python.o libpython3.2.a -lintl -ldl    -lm  
ld: 0711-596 SEVERE ERROR: Object libpython3.2.a[ceval.o]
        An RLD for section 2 (.data) refers to symbol 0,
        but the storage class of the symbol is not C_EXT or C_HIDEXT.

Python 3.1.2 or Python 2.7 both compile fine.

I also tried rev 73580 of this branch which compiled fine also.

I will try to find the rev number where this problem started.

----------
messages: 115875
nosy: sable
priority: normal
severity: normal
status: open
title: Compilation error for branch py3k on AIX 6
type: compile error
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9799>
_______________________________________

From rdmurray at bitdance.com  Wed Sep  8 17:27:35 2010
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 08 Sep 2010 11:27:35 -0400
Subject: [New-bugs-announce] bug in Python?
In-Reply-To: <176597.89083.qm@web29006.mail.ird.yahoo.com>
References: <176597.89083.qm@web29006.mail.ird.yahoo.com>
Message-ID: <20100908152735.8D4C01FBE55@kimball.webabinitio.net>

Please set up a account on the python bug tracker
(http://bugs.python.org) and submit your bug report
there as plain text.  This mailing list just notifies
us of new bug reports that are submitted to the tracker,
and posting a bug report here doesn't enter it into the
tracker where it can be handled.

--David

From report at bugs.python.org  Wed Sep  8 20:07:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Sep 2010 18:07:10 +0000
Subject: [New-bugs-announce] [issue9800] Fast path for small int-indexing of
	lists and tuples
In-Reply-To: <1283969230.58.0.425189432441.issue9800@psf.upfronthosting.co.za>
Message-ID: <1283969230.58.0.425189432441.issue9800@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is an experiment which turns out to yield little benefits, except on micro-benchmarks such as:

$ ./python -m timeit -s "a=[1,2,3]" "a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];a[0];a[1];a[-1];"

-> before: 1000000 loops, best of 3: 1.14 usec per loop
-> after: 1000000 loops, best of 3: 0.759 usec per loop

On IRC, Raymond pointed out that the long representation is not very friendly to direct manipulation for small ints, but even then it's not obvious it would benefit a lot: a large amount of time is certainly spent accessing the Python stack, manipulating reference counts, decoding opcodes and checking array bounds.

The conclusion could be that such special-casing is futile when the body of code it avoids executing isn't big enough. Also, adding runtime checks has its own performance cost (more CPU instructions to execute, possible pipeline flushes due to branch misprediction, and pollution of branch prediction caches).

----------
components: Interpreter Core
files: evalsubscr.patch
keywords: patch
messages: 115888
nosy: mark.dickinson, pitrou, rhettinger
priority: low
severity: normal
status: open
title: Fast path for small int-indexing of lists and tuples
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file18799/evalsubscr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9800>
_______________________________________

From report at bugs.python.org  Wed Sep  8 21:23:22 2010
From: report at bugs.python.org (James Hutchison)
Date: Wed, 08 Sep 2010 19:23:22 +0000
Subject: [New-bugs-announce] [issue9801] Can not use append/extend to lists
	in a multiprocessing	manager dict
In-Reply-To: <1283973802.38.0.869176624785.issue9801@psf.upfronthosting.co.za>
Message-ID: <1283973802.38.0.869176624785.issue9801@psf.upfronthosting.co.za>


New submission from James Hutchison <jamesghutchison at gmail.com>:

tested python 3.1.2

Man = multiprocessing.Manager();
d = man.dict();
d['l'] = list();
d['l'].append("hey");
print(d['l']);
>>> []

using debugger reveals a KeyError. Extend also does not work. Only thing that works is += which means you can't insert actual tuples or lists into the list. This was all done on a single process

----------
components: Library (Lib)
messages: 115891
nosy: Jimbofbx
priority: normal
severity: normal
status: open
title: Can not use append/extend to lists in a multiprocessing manager dict
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9801>
_______________________________________

From report at bugs.python.org  Wed Sep  8 21:30:31 2010
From: report at bugs.python.org (Matthew Woodcraft)
Date: Wed, 08 Sep 2010 19:30:31 +0000
Subject: [New-bugs-announce] [issue9802] Document 'stability' of builtin
	min() and max()
In-Reply-To: <1283974231.16.0.73129931792.issue9802@psf.upfronthosting.co.za>
Message-ID: <1283974231.16.0.73129931792.issue9802@psf.upfronthosting.co.za>


New submission from Matthew Woodcraft <matthew at woodcraft.me.uk>:

In CPython, the builtin max() and min() have the property that if there are items with equal keys, the first item is returned. From a quick look at their source, I think this is true for Jython and IronPython too.

I propose making this a documented guarantee.

On Python-dev, Raymond Hettinger said:
<<
That seems like a reasonable request. This behavior has been around for a very long time is unlikely to change. Elsewhere, we've made efforts to document sort stability (i.e. sorted(), heapq.nlargest(), heapq.nsmallest, merge(), etc).
>>
(<http://mail.python.org/pipermail/python-dev/2010-September/103543.html>)

I'm attaching a patch with a concrete suggestion for a change to
functions.rst, modelled on the documentation of heapq.nlargest().

----------
assignee: docs at python
components: Documentation
files: maxmin.patch
keywords: patch
messages: 115892
nosy: docs at python, mattheww
priority: normal
severity: normal
status: open
title: Document 'stability' of builtin min() and max()
type: feature request
Added file: http://bugs.python.org/file18802/maxmin.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9802>
_______________________________________

From report at bugs.python.org  Wed Sep  8 21:42:29 2010
From: report at bugs.python.org (James Hutchison)
Date: Wed, 08 Sep 2010 19:42:29 +0000
Subject: [New-bugs-announce] [issue9803] IDLE closes with save while
	breakpoint open
In-Reply-To: <1283974949.4.0.785258120567.issue9803@psf.upfronthosting.co.za>
Message-ID: <1283974949.4.0.785258120567.issue9803@psf.upfronthosting.co.za>


New submission from James Hutchison <jamesghutchison at gmail.com>:

I have multiple versions of python - 2.6.1 and 3.1.2. 2.6.1 is the primary install (i.e., right click on a file and "edit with IDLE" brings up 2.6), and was installed first. This issue occurs on 3.1.2, Windows XP 32-bit

If I highlight a breakpoint, run with the debugger, make a change, then save, IDLE will close all windows after saving without an error message. If I clear the breakpoint and then save, IDLE will not close. Reopening the file reveals that the save was successful. I do not need to actually be stopped at a highlighted breakpoint for this to occur (i.e. this will occur if I save at the beginning before the script has ran). If I run with 2.6.1 I do not see this issue. The save difference could be something simple, such as adding a space somewhere random.

----------
components: IDLE
messages: 115894
nosy: Jimbofbx
priority: normal
severity: normal
status: open
title: IDLE closes with save while breakpoint open
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9803>
_______________________________________

From report at bugs.python.org  Wed Sep  8 23:47:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 Sep 2010 21:47:49 +0000
Subject: [New-bugs-announce] [issue9804] ascii() does not always join
	surrogate pairs
In-Reply-To: <1283982469.78.0.773368120322.issue9804@psf.upfronthosting.co.za>
Message-ID: <1283982469.78.0.773368120322.issue9804@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is on an UCS-2 py3k build:

>>> ascii('\U00012FFF')
"'\\U00012fff'"
>>> ascii('\U0001D121')
"'\\ud834\\udd21'"

----------
components: Interpreter Core, Unicode
messages: 115905
nosy: haypo, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: ascii() does not always join surrogate pairs
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9804>
_______________________________________

From report at bugs.python.org  Thu Sep  9 00:08:38 2010
From: report at bugs.python.org (Ken Basye)
Date: Wed, 08 Sep 2010 22:08:38 +0000
Subject: [New-bugs-announce] [issue9805] Documentation on old-style
	formatting of dicts is overly	restrictive
In-Reply-To: <1283983718.4.0.736400654813.issue9805@psf.upfronthosting.co.za>
Message-ID: <1283983718.4.0.736400654813.issue9805@psf.upfronthosting.co.za>


New submission from Ken Basye <ken.basye at gmail.com>:

>From http://docs.python.org/library/stdtypes.html#string-formatting-operations :

"When the right argument is a dictionary (or other mapping type), then the formats in the string must include a parenthesised mapping key into that dictionary inserted immediately after the '%' character."  
(with emphasis on 'must' in the HTML, BTW).  

This isn't correct:  "%s" % dict() is a perfectly legal expression with a dictionary as the right argument and no mapping key in the formats.  Indeed, if the current doc were correct, there would apparently be no way to format an empty dictionary.

How about this one-word fix:

"When the right argument is a dictionary (or other mapping type), then the formats in the string may include ..." and so on into the next sentence, and no emphasis on 'may'.






P.S. Not sure about the Type of this issue, and it's present in both 2.7 and current 3.X doc.

----------
assignee: docs at python
components: Documentation
messages: 115907
nosy: Ken.Basye, docs at python
priority: normal
severity: normal
status: open
title: Documentation on old-style formatting of dicts is overly restrictive
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9805>
_______________________________________

From report at bugs.python.org  Thu Sep  9 03:05:42 2010
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 09 Sep 2010 01:05:42 +0000
Subject: [New-bugs-announce] [issue9806] no need to try loading posix
	extensions without SOABI
In-Reply-To: <1283994342.76.0.291160023697.issue9806@psf.upfronthosting.co.za>
Message-ID: <1283994342.76.0.291160023697.issue9806@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

the SOABI is always defined, no need to try loading an extension without the SOABI in its name.

ok to commit?

----------
components: Interpreter Core
files: dynload.diff
keywords: patch
messages: 115922
nosy: barry, doko
priority: normal
severity: normal
status: open
title: no need to try loading posix extensions without SOABI
versions: Python 3.2
Added file: http://bugs.python.org/file18806/dynload.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9806>
_______________________________________

From report at bugs.python.org  Thu Sep  9 03:24:25 2010
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 09 Sep 2010 01:24:25 +0000
Subject: [New-bugs-announce] [issue9807] deriving configuration information
	for different builds	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

currently, much of the configuration information is fetched by opening the config.h and the Makefile for the build. The locations of these files are derived from the prefix given at configure time.

If you want to have two distinct builds with the same prefix, but with different configuration options, this kind of configuration information is unsufficient.  The current use case is a normal build and a debug build, as used for the Fedora and Debian/Ubuntu python packages.

Fedora and Debian/Ubuntu carry a patch, adding a sys.pydebug attribute and patching "some" things to get the correct information for these builds using the same prefix.

This kind of information should not be derived by following some paths names, but be contained in the python binary itself, without needing to read the Makefile and the config.h files.

Attached is a patch currently applied in Debian/Ubuntu (and some variant for Fedora) which introduces a sys.pydebug attribute and derives the correct locations for the config.h and Makefile files. It's not meant as a patch ready to apply, but to get an idea what is needed to have two different python installations with the same prefix.

----------
components: Build
files: debug-build.diff
keywords: patch
messages: 115923
nosy: barry, doko
priority: normal
severity: normal
stage: needs patch
status: open
title: deriving configuration information for different builds with the same prefix
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file18807/debug-build.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Thu Sep  9 05:20:25 2010
From: report at bugs.python.org (Jon Anglin)
Date: Thu, 09 Sep 2010 03:20:25 +0000
Subject: [New-bugs-announce] [issue9808] Implement os.getlogin on Windows
In-Reply-To: <1284002425.19.0.311634262224.issue9808@psf.upfronthosting.co.za>
Message-ID: <1284002425.19.0.311634262224.issue9808@psf.upfronthosting.co.za>


New submission from Jon Anglin <janglin at fortresgrand.com>:

This is a feature request to implement the os.getlogin function on Windows systems.  This may not be a widely used function, but implementing on Windows will bring Python on Windows one step closer to Python on Unix (like) systems.  The os_getlogin.diff file contains my proposed patch to add this functionality for Windows.

----------
components: Library (Lib), Windows
files: os_getlogin.diff
keywords: patch
messages: 115927
nosy: janglin
priority: normal
severity: normal
status: open
title: Implement os.getlogin on Windows
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file18808/os_getlogin.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9808>
_______________________________________

From report at bugs.python.org  Thu Sep  9 07:19:53 2010
From: report at bugs.python.org (GreY FoX)
Date: Thu, 09 Sep 2010 05:19:53 +0000
Subject: [New-bugs-announce] [issue9809] Wrong Registery Entries on win64
In-Reply-To: <1284009593.81.0.159283716249.issue9809@psf.upfronthosting.co.za>
Message-ID: <1284009593.81.0.159283716249.issue9809@psf.upfronthosting.co.za>


New submission from GreY FoX <greyfoxgti at gmail.com>:

Priority:  3 Keywords:      6

well python on installation on win64 adds the following registry keys:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Python]

[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore]

[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7]

[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\Help]

[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\Help\Main Python Documentation]
@="C:\\Python27\\Doc\\python27.chm"

[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\InstallPath]
@="C:\\Python27\\"

[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\InstallPath\InstallGroup]
@="Python 2.7"

[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\Modules]

[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\PythonPath]
@="C:\\Python27\\Lib;C:\\Python27\\DLLs;C:\\Python27\\Lib\\lib-tk"



but to be found by the programs searching for it it should be:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\Help]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\Help\Main Python Documentation]
@="C:\\Python27\\Doc\\python27.chm"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\InstallPath]
@="C:\\Python27\\"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\InstallPath\InstallGroup]
@="Python 2.7"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\Modules]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\PythonPath]
@="C:\\Python27\\Lib;C:\\Python27\\DLLs;C:\\Python27\\Lib\\lib-tk"



this would fix the installer of the setuptools
thanks

----------
components: Installation
messages: 115929
nosy: GreYFoX
priority: normal
severity: normal
status: open
title: Wrong Registery Entries on win64
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9809>
_______________________________________

From report at bugs.python.org  Thu Sep  9 09:38:11 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 09 Sep 2010 07:38:11 +0000
Subject: [New-bugs-announce] [issue9810] bzip2 build sometimes fails (VS8.0)
In-Reply-To: <1284017891.77.0.101169021323.issue9810@psf.upfronthosting.co.za>
Message-ID: <1284017891.77.0.101169021323.issue9810@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

bzip2 project sometimes fails to build pyd file. This is because

(snip)
nmake /nologo /f makefile.msc lib
(snip)
nmake /nologo /f makefile.msc clean

is run by bzip2.vcproj, but "lib" command won't create
bzip2.exe nor bzip2recover.exe, wheres "clean" will try
to delete these files without checking their existence.

Technically it is easy to fix this. (Replace "del ..." with
if exists ... del .....    in bzip2-1.0.5/makefile.msc)
But is it allowed to modify external project files? Thank you.

----------
components: Build
messages: 115930
nosy: ocean-city
priority: normal
severity: normal
status: open
title: bzip2 build sometimes fails (VS8.0)
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9810>
_______________________________________

From report at bugs.python.org  Thu Sep  9 11:59:05 2010
From: report at bugs.python.org (Sverre Johansen)
Date: Thu, 09 Sep 2010 09:59:05 +0000
Subject: [New-bugs-announce] [issue9811] strftime strips '%' from unknown
	format codes on OS X
In-Reply-To: <1284026345.38.0.190320909092.issue9811@psf.upfronthosting.co.za>
Message-ID: <1284026345.38.0.190320909092.issue9811@psf.upfronthosting.co.za>


New submission from Sverre Johansen <sverre.johansen at gmail.com>:

There seems to be a platform difference in the way stftime handles 
unknown format codes.

In OSX Python removes the percentage sign from the returned string when the format code is unknown. In Linux it leaves it.

Look at the following example:

This is Python 3.1.2 in Ubuntu:

    Python 3.1.2 (r312:79147, Apr 15 2010, 15:35:48) 
    [GCC 4.4.3] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import datetime
    >>> datetime.datetime.now().strftime("%q")
    '%q'

And this is Python 3.1.2 on Max OSX:

    Python 3.1.2 (r312:79147, Sep  9 2010, 11:11:24) 
    [GCC 4.2.1 (Apple Inc. build 5664)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import datetime
    >>> datetime.datetime.now().strftime("%q")
    'q'

I've gotten the same result in 2.5, 2.6 and 3.1.

FYI, this broke some code that parsed the same string first with strftime, and then used string interpolation (The mac version
deleted all percentage signs before '('):

    >>> datetime.datetime.now().strftime("%Y - %(foobar)s") % {"foobar": "egg"}

This does not work in OSX.

----------
components: Library (Lib)
messages: 115933
nosy: sverrejoh
priority: normal
severity: normal
status: open
title: strftime strips '%' from unknown format codes on OS X
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9811>
_______________________________________

From report at bugs.python.org  Thu Sep  9 17:03:21 2010
From: report at bugs.python.org (Kenneth Dombrowski)
Date: Thu, 09 Sep 2010 15:03:21 +0000
Subject: [New-bugs-announce] [issue9812] cPickle segfault with nested dicts
	in threaded env
In-Reply-To: <1284044601.98.0.223579173983.issue9812@psf.upfronthosting.co.za>
Message-ID: <1284044601.98.0.223579173983.issue9812@psf.upfronthosting.co.za>


New submission from Kenneth Dombrowski <kdombrowski at gmail.com>:

FreeBSD 8.0-RELEASE-p2
Python 2.5.5
amd64

attached diff provides a test for cpickle which reproduces a segfault when pickling >15 nested dicts in a threaded environment 

cpickle.patch attached to http://bugs.python.org/issue3640 applys cleanly to the 2.5 source and fixes this issue

i understand 2.5 is no longer maintained except for security fixes, i leave it up to the maintainers to decide if this segfault warrants a security patch 

thank you

----------
components: Extension Modules
files: test_cpickle.nested_dicts_in_threaded_env.diff
keywords: patch
messages: 115950
nosy: kdombrowski
priority: normal
severity: normal
status: open
title: cPickle segfault with nested dicts in threaded env
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file18812/test_cpickle.nested_dicts_in_threaded_env.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9812>
_______________________________________

From report at bugs.python.org  Thu Sep  9 23:25:44 2010
From: report at bugs.python.org (Charles M Norton)
Date: Thu, 09 Sep 2010 21:25:44 +0000
Subject: [New-bugs-announce] [issue9813] Module Name Changed
In-Reply-To: <1284067544.87.0.0157628070586.issue9813@psf.upfronthosting.co.za>
Message-ID: <1284067544.87.0.0157628070586.issue9813@psf.upfronthosting.co.za>


New submission from Charles M Norton <old_road_farm at verizon.net>:

In Python 2.6, I could import 
from mx.DateTime.ISO import ParseDateTimeUTC
With 2.7 I cannot.

Here is the error:

  File "util_lib.py", line 46, in <module>
    from mx.DateTime.ISO import ParseDateTimeUTC
ImportError: No module named mx.DateTime.ISO


What changes do I need to make, to import on pre-2.7 and 2.7?

----------
components: Library (Lib)
messages: 115976
nosy: octopusgrabbus
priority: normal
severity: normal
status: open
title: Module Name Changed
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9813>
_______________________________________

From report at bugs.python.org  Fri Sep 10 00:58:34 2010
From: report at bugs.python.org (Dino Viehland)
Date: Thu, 09 Sep 2010 22:58:34 +0000
Subject: [New-bugs-announce] [issue9814] subprocess isn't friendly to other
	Python implementations	with different GCs
In-Reply-To: <1284073114.59.0.931577015567.issue9814@psf.upfronthosting.co.za>
Message-ID: <1284073114.59.0.931577015567.issue9814@psf.upfronthosting.co.za>


New submission from Dino Viehland <dinov at microsoft.com>:

subprocess isn't very friendly to implementations with different GCs then CPython and in general relies on behavior that's not going to be very stable.  I noticed the following issues but was able to work around all of them.

First Popen is a finalizable object which holds onto another finalizable object (the process handle).  In __del__ Popen calls internal poll which attempts to wait on the handle.  But because both the handle and the POpen object can go out of scope at the same time the handle can be finalized first.  The end result is that you cannot get the return code and therefore the Popen class will resurrect it's self.  That will at the very least leak the Popen object and when running the subprocess tests will eventually start failing all of the tests.  For me this was happening because test_cwd doesn't call wait and therefore never explicitly gets the exit code.

Resurrecting finalizable objects seems like a pretty bad idea and seems to be there only for test purposes - after all who cares if you collect the exit code after no one refers to the object.  Unless _active is supposed to be publicly exposed?  

Another issue is relying on CPython's reference counting garbage collcetion.  In particular _get_handles on Windows does "p2cread = self._make_inheritable(p2cread)" where stdin == PIPE.  On CPython this is going to remove the 1 reference to the previous p2cread and close it immediately.  With other GCs this reference will linger around only to be closed at some point.  Usually that's not a problem but because this handle remains in the parent process the pipe does not get closed when it should resulting in hangs.  This is effectively a duplicated handle of the handle _execute_child closes after the child is launched.

----------
components: Library (Lib)
messages: 115979
nosy: dino.viehland
priority: low
severity: normal
status: open
title: subprocess isn't friendly to other Python implementations with different GCs
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9814>
_______________________________________

From report at bugs.python.org  Fri Sep 10 09:18:20 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 10 Sep 2010 07:18:20 +0000
Subject: [New-bugs-announce] [issue9815] test_tarfile sometimes ends with
	error "Cannot remoe dir"
In-Reply-To: <1284103100.0.0.404704166803.issue9815@psf.upfronthosting.co.za>
Message-ID: <1284103100.0.0.404704166803.issue9815@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

I noticed regrtest claimed it cannot delete folder after test_tarfile
ran. It was like this.

Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "e:\python-dev\py3k\lib\runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "e:\python-dev\py3k\lib\test\test_tarfile.py", line 1566, in <module>
    test_main()
  File "e:\python-dev\py3k\lib\test\test_tarfile.py", line 1563, in test_main
    shutil.rmtree(TEMPDIR)
  File "e:\python-dev\py3k\lib\shutil.py", line 283, in rmtree
    onerror(os.remove, fullname, sys.exc_info())
  File "e:\python-dev\py3k\lib\shutil.py", line 281, in rmtree
    os.remove(fullname)
WindowsError: [Error 32] ???????????????????????????
??????: 'E:\\PYTHON~1\\py3k\\@test_5276_tmp\\tmp.tar'

# It says "Process cannot access the file. Another process is using it."

I tried to reproduce this by running test_tarfile alone, but failed.
But I succeeded to do it with following command.
  py3k -m test.regrtest test_capi test_tarfile

(Probably there is timing problem like GC... The reason why I think
so is below)

I think _Stream object left opened after exception occured in (even
after returned from function Tarfile#open) because it lives in stack
frame. Because t._extfileobj is True by default, TarFile object won't close it explicitly.

----------
components: Extension Modules
files: py3k_fix_tarfile.patch
keywords: patch
messages: 115984
nosy: ocean-city
priority: normal
severity: normal
status: open
title: test_tarfile sometimes ends with error "Cannot remoe dir"
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file18815/py3k_fix_tarfile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9815>
_______________________________________

From report at bugs.python.org  Fri Sep 10 09:29:31 2010
From: report at bugs.python.org (Joseph Schaeffer)
Date: Fri, 10 Sep 2010 07:29:31 +0000
Subject: [New-bugs-announce] [issue9816] random.jumpahead and PRNG sequence
	independence
In-Reply-To: <1284103771.84.0.522023819888.issue9816@psf.upfronthosting.co.za>
Message-ID: <1284103771.84.0.522023819888.issue9816@psf.upfronthosting.co.za>


New submission from Joseph Schaeffer <thiryal at gmail.com>:

Reading the Python 2.6 docs, it appeared that using random.jumpahead would allow the initialization of several generators with the same seed but having much different internal states. While the resulting PRNG appear to have different internal states, the produced random numbers [via .random()] are exactly the same after a small initial segment.

Attached is some example code which shows the first point at which they all agree - in my testing (Mac OS X, Python versions 2.5, 2.6, 2.7) the generated numbers all agreed on the 12th number generated. For smaller differences in jumpahead it was noticeable a lot earlier - n=1,2 differ only in the first sample from each.

The internal state of the PRNGs is indeed different even after the successive sampling, so it may be that this is intended - however if so the docs may cause confusion: my particular case was where I need random numbers for a stochastic markov process and in addition needed many such generators [one for each trajectory] and was hoping to use random.jumpahead to have indepedent PRNG's without having to generate [and prove] my own independent set of seeds. Thus having a long sequence of non-independent random numbers near the initial start condition causes random.jumpahead to be unusable for my situation.

It appears that Python 3.1 removed random.jumpahead - if so, it may be useful to note in the 2.6 docs why this was / the issues with random.jumpahead: reading how it changed after 2.3 made it sound like it was exactly what I wanted. 

Possible cause: I suspect the issue may be related to how a Mersenne Twister algorithm can take a while to recover from poor seeding (excessive 0's), but do not know enough to explore that idea.

----------
components: Library (Lib)
files: random_test.py
messages: 115985
nosy: Joseph.Schaeffer
priority: normal
severity: normal
status: open
title: random.jumpahead and PRNG sequence independence
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file18816/random_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9816>
_______________________________________

From report at bugs.python.org  Fri Sep 10 11:15:11 2010
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 10 Sep 2010 09:15:11 +0000
Subject: [New-bugs-announce] [issue9817] expat copyright/license file is
	missing
In-Reply-To: <1284110111.54.0.68745930028.issue9817@psf.upfronthosting.co.za>
Message-ID: <1284110111.54.0.68745930028.issue9817@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

files in Modules/expat reference a file COPYING for the copyright/license, but this is file is not included in the Python sources.

Proposing to add the attached file, taken from the expat sources.

----------
assignee: doko
components: None
files: COPYING
messages: 115986
nosy: doko
priority: normal
severity: normal
status: open
title: expat copyright/license file is missing
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file18817/COPYING

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9817>
_______________________________________

From report at bugs.python.org  Fri Sep 10 11:31:05 2010
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 10 Sep 2010 09:31:05 +0000
Subject: [New-bugs-announce] [issue9818] build files to build
	Lib/distutils/command/wininst-9.0*	are missing
In-Reply-To: <1284111065.95.0.0437799903447.issue9818@psf.upfronthosting.co.za>
Message-ID: <1284111065.95.0.0437799903447.issue9818@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

PC/V[CS]* contain the information to build the wininst-[678]* files, but I don't see any information how to build wininst-9.0*.

----------
components: Build
messages: 115988
nosy: doko
priority: normal
severity: normal
status: open
title: build files to build Lib/distutils/command/wininst-9.0* are missing
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9818>
_______________________________________

From report at bugs.python.org  Fri Sep 10 11:39:53 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 10 Sep 2010 09:39:53 +0000
Subject: [New-bugs-announce] [issue9819] TESTFN_UNICODE and
	TESTFN_UNDECODABLE
In-Reply-To: <1284111593.27.0.664276526228.issue9819@psf.upfronthosting.co.za>
Message-ID: <1284111593.27.0.664276526228.issue9819@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Hello. I noticed test suite reports WARNING every time.

///////////////////////////////////////////////////

E:\python-dev>py3k -m test.regrtest test_os
WARNING: The filename '@test_464_tmp-?????' CAN be encoded by the filesyste
m encoding (mbcs). Unicode filename tests may not be effective
(snip)

///////////////////////////////////////////////////

This happens because TESTFN_UNICODE_UNDECODABLE in Lib/test/support.py
*is* decodable on Japanese environment (cp932).

It is easy to make this really undecodable in Japanese.
Using the characters like "\u2661" or "\u2668" (Former is heart mark,
latter is "Onsen" - Hot spring mark) I could remove the warning by this.
    TESTFN_UNENCODABLE = TESTFN + "-\u5171\u6709\u3055\u308c\u308b\u2661\u2668"

///////////////////////////////////////////////////

And another issue. This happens only on test_unicode_file,

///////////////////////////////////////////////////

E:\python-dev>py3k -m test.test_unicode_file
Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\test\test_unicode_file.py", line 12, in <module>
    TESTFN_UNICODE.encode(TESTFN_ENCODING)
UnicodeEncodeError: 'mbcs' codec can't encode characters in position 0--1: inval
id character

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "e:\python-dev\py3k\lib\runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "e:\python-dev\py3k\lib\test\test_unicode_file.py", line 16, in <module>
    raise unittest.SkipTest("No Unicode filesystem semantics on this platform.")

unittest.case.SkipTest: No Unicode filesystem semantics on this platform.

///////////////////////////////////////////////////

This happens because TESTFN_UNICODE cannot be encoded in Japanese.

E:\python-dev>py3k
Python 3.2a2+ (py3k:84663M, Sep 10 2010, 13:24:41) [MSC v.1400 32 bit (Intel)] o
n win32
Type "help", "copyright", "credits" or "license" for more information.
>>> print("-\xe0\xf2")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'cp932' codec can't encode character '\xe0' in position 1: i
llegal multibyte sequence

But interesting, this bytes sequence "\xe0\xf2" can be read as
cp932 multibyte characters.

E:\python-dev>python
Python 2.6.6 (r266:84297, Aug 24 2010, 18:46:32) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> print "\xe0\xf2"
?
>>> "\xe0\xf2".decode("cp932")
u'\u7463'

E:\python-dev>py3k
Python 3.2a2+ (py3k:84663M, Sep 10 2010, 13:24:41) [MSC v.1400 32 bit (Intel)] o
n win32
Type "help", "copyright", "credits" or "license" for more information.
>>> print('\u7463')
?

I believe this value "\xe0\xf2" came from python2.x, maybe "\u7463"
should be used here? I'm not sure it can be decoded everywhere using
other encodings, though.

----------
components: Tests, Unicode
messages: 115989
nosy: ocean-city
priority: normal
severity: normal
status: open
title: TESTFN_UNICODE and TESTFN_UNDECODABLE
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9819>
_______________________________________

From report at bugs.python.org  Fri Sep 10 12:42:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 10:42:59 +0000
Subject: [New-bugs-announce] [issue9820] Windows : os.listdir(b'.') doesn't
	raise an error for	unencodable filenames
In-Reply-To: <1284115379.54.0.982688803617.issue9820@psf.upfronthosting.co.za>
Message-ID: <1284115379.54.0.982688803617.issue9820@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

In Python 3.2, mbcs encoding (default filesystem encoding on Windows) is now strict: raise an error on unencodable/undecodable characters/bytes. But os.listdir(b'.') encodes unencodable bytes as b'?'.

Example:

>>> os.mkdir('listdir')
>>> open('listdir\\xxx-\u0363', 'w').close()
>>> filename = os.listdir(b'listdir')[0]
>>> filename
b'xxx-?'
>>> open(filename, 'r').close()
IOError: [Errno 22] Invalid argument: 'xxx-?'

os.listdir(b'listdir') should raise an error (and not ignore the filename or replaces unencodable characters by b'?').

I think that we should list the directory using the wide character API (FindFirstFileW) but encode the filename using PyUnicode_EncodeFSDefault() if the directory name type is bytes, instead of using the ANSI API (FindFirstFileA).

----------
components: Library (Lib), Unicode, Windows
messages: 115995
nosy: haypo, loewis
priority: normal
severity: normal
status: open
title: Windows : os.listdir(b'.') doesn't raise an error for unencodable filenames
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9820>
_______________________________________

From report at bugs.python.org  Fri Sep 10 13:04:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Sep 2010 11:04:41 +0000
Subject: [New-bugs-announce] [issue9821] Support PEP 383 on Windows: mbcs
	support of	surrogateescape error handler
In-Reply-To: <1284116681.52.0.20336510367.issue9821@psf.upfronthosting.co.za>
Message-ID: <1284116681.52.0.20336510367.issue9821@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

It would be nice to support PEP 383 (surrogateescape) on Windows, but the mbcs codec doesn't support it for performance reason. The Windows functions to encode/decode MBCS don't give the index of the unencodable/undecodable character/byte. For encoding, we can try to encode character by character (but be careful of surrogate pairs) and check that the character is a Python lone surrogate character or not (character in range U+DC80..U+DCFF). For decoding, it is more complex because MBCS can be a multibyte encoding, eg. cp65001 (Microsoft variant of utf-8, see #6058). So it's not possible to encode byte per byte and we should write an heuristic to guess the right number of bytes for each call to the decode function.

--

A completly different solution is to get the MBCS code page and use the Python code page codec (eg. "cp1252") instead of "mbcs" encoding, because Python cpXXXX codecs support all Python error handlers. Example (with Python 2.6):

>>> print(u"abc?def".encode("cp1252", "replace"))
abc?def
>>> print(u"abc?def".encode("cp1252", "ignore"))
abcdef
>>> print(u"abc?def".encode("cp1252", "backslashreplace"))
abc\u0141def

See also #8611 for the problem if the Python path cannot be encoded to mbcs (work in progress, see #9425).

----------
components: Interpreter Core, Library (Lib), Unicode, Windows
messages: 116001
nosy: haypo, loewis
priority: normal
severity: normal
status: open
title: Support PEP 383 on Windows: mbcs support of surrogateescape error handler
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9821>
_______________________________________

From report at bugs.python.org  Fri Sep 10 13:37:00 2010
From: report at bugs.python.org (sorin)
Date: Fri, 10 Sep 2010 11:37:00 +0000
Subject: [New-bugs-announce] [issue9822] windows batch files are dependent
	on cmd current directory
In-Reply-To: <1284118620.1.0.910652087288.issue9822@psf.upfronthosting.co.za>
Message-ID: <1284118620.1.0.910652087288.issue9822@psf.upfronthosting.co.za>


New submission from sorin <sorin.sbarnea at gmail.com>:

Currently most batch files from Tools\buildbot do fail to run if you do not call them from the python source root directory.


I already have patched files, but the question is against which branch should I make them, considering that this bug is valid for all versions?

Do you prefer patch or just the entire files?

----------
components: Build
messages: 116009
nosy: sorin
priority: normal
severity: normal
status: open
title: windows batch files are dependent on cmd current directory
type: compile error
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9822>
_______________________________________

From report at bugs.python.org  Fri Sep 10 18:15:23 2010
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 10 Sep 2010 16:15:23 +0000
Subject: [New-bugs-announce] [issue9823] OrderedDict is comparable to dict
In-Reply-To: <1284135323.35.0.651506099343.issue9823@psf.upfronthosting.co.za>
Message-ID: <1284135323.35.0.651506099343.issue9823@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

OrderedDict is currently comparable to dict.

I think this is not logical, because a dict doesn't have order, and having an identical order is a necessary condition for a match.

I think that comparing an OrderedDict with a dict makes as much sense as comparing a tuple with a set, and that's currently not allowed. (Always returns False)

Here's a disturbing code snippet executed in Python 3.2a1:

>>> from collections import OrderedDict
>>> d1 = OrderedDict(((1, 2), (3, 4)))
>>> d2 = OrderedDict(((3, 4), (1, 2)))
>>> d1 == d2
False
>>> d1 == {1: 2, 3: 4} == d2
True

----------
components: Library (Lib)
messages: 116027
nosy: cool-RR
priority: normal
severity: normal
status: open
title: OrderedDict is comparable to dict
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9823>
_______________________________________

From report at bugs.python.org  Fri Sep 10 18:50:10 2010
From: report at bugs.python.org (Luke Plant)
Date: Fri, 10 Sep 2010 16:50:10 +0000
Subject: [New-bugs-announce] [issue9824] SimpleCookie should escape commas
	and semi-colons
In-Reply-To: <1284137410.37.0.376622837409.issue9824@psf.upfronthosting.co.za>
Message-ID: <1284137410.37.0.376622837409.issue9824@psf.upfronthosting.co.za>


New submission from Luke Plant <L.Plant.98 at cantab.net>:

In developing Django, we found that some browsers don't treat commas and semi-colons in cookie values (i.e. the Set-Cookie header) the way that RFC 2109 says they should. (Safari splits the header on a comma followed by space, Internet Explorer splits on semi-colons - both irrespective of any 'quoting').

The result is that if you use SimpleCookie to create Set-Cookie headers, where the cookie value contains a comma or semi-colon, you can get all kinds of breakage. 

In the end, we realised that the RFCs are kind of irrelevant, and we have to look at what browsers actually do.  So, it would be much more useful if semi-colons and commas were escaped the way that other characters are by SimpleCookie.

Our discussion/findings are here:
http://code.djangoproject.com/ticket/12470#comment:4
http://groups.google.com/group/django-developers/msg/2cb729938e8e67ca

The patch to Cookie.py (Python 2.X) or http/cookies.py (Python 3.X) is simple and follows. I'm assuming that this applies to Python 3.2 and 3.3, but I haven't checked.

----------
components: Library (Lib)
files: simplecookie_fix.diff
keywords: patch
messages: 116030
nosy: spookylukey
priority: normal
severity: normal
status: open
title: SimpleCookie should escape commas and semi-colons
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file18833/simplecookie_fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9824>
_______________________________________

From report at bugs.python.org  Fri Sep 10 21:04:04 2010
From: report at bugs.python.org (jason kirtland)
Date: Fri, 10 Sep 2010 19:04:04 +0000
Subject: [New-bugs-announce] [issue9825] OrderedDict ref cycles cause memory
	leak
In-Reply-To: <1284145444.07.0.163314050875.issue9825@psf.upfronthosting.co.za>
Message-ID: <1284145444.07.0.163314050875.issue9825@psf.upfronthosting.co.za>


New submission from jason kirtland <jek at discorporate.us>:

Circular graphs of collections.OrderedDict are uncollectable due to the presence of OrderedDict.__del__.

>>> from collections import OrderedDict
>>> import gc
>>> left, right = OrderedDict(), OrderedDict()
>>> left['other'] = right
>>> right['other'] = left
>>> assert not gc.garbage
>>> del left, right
>>> gc.collect()
10
>>> assert not gc.garbage
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AssertionError

Not an issue in 3.1.1, have not verified with 3.1.2.

----------
components: Library (Lib)
files: odicttest.py
messages: 116036
nosy: jek
priority: normal
severity: normal
status: open
title: OrderedDict ref cycles cause memory leak
type: resource usage
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file18834/odicttest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9825>
_______________________________________

From report at bugs.python.org  Fri Sep 10 21:10:02 2010
From: report at bugs.python.org (jason kirtland)
Date: Fri, 10 Sep 2010 19:10:02 +0000
Subject: [New-bugs-announce] [issue9826] OrderedDict ref cycles break repr()
In-Reply-To: <1284145802.06.0.781537031861.issue9826@psf.upfronthosting.co.za>
Message-ID: <1284145802.06.0.781537031861.issue9826@psf.upfronthosting.co.za>


New submission from jason kirtland <jek at discorporate.us>:

repr of circular graphs of collections.OrderedDicts fails with 'RuntimeError: maximum recursion depth exceeded while calling a Python object'.

>>> from collections import OrderedDict
>>> left, right = OrderedDict(), OrderedDict()
>>> left['other'] = right
>>> right['other'] = left
>>> left
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  ...
  File "lib/python2.7/collections.py", line 137, in __repr__
    return '%s(%r)' % (self.__class__.__name__, self.items())
RuntimeError: maximum recursion depth exceeded in __subclasscheck__

----------
components: Library (Lib)
files: odictcyclerepr.py
messages: 116037
nosy: jek
priority: normal
severity: normal
status: open
title: OrderedDict ref cycles break repr()
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file18835/odictcyclerepr.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9826>
_______________________________________

From report at bugs.python.org  Sat Sep 11 02:20:12 2010
From: report at bugs.python.org (Chris Leary)
Date: Sat, 11 Sep 2010 00:20:12 +0000
Subject: [New-bugs-announce] [issue9827] Clarify LogRecord documentation
In-Reply-To: <1284164412.99.0.558219134609.issue9827@psf.upfronthosting.co.za>
Message-ID: <1284164412.99.0.558219134609.issue9827@psf.upfronthosting.co.za>


New submission from Chris Leary <christopher.leary at cornell.edu>:

I tried to clear this section up a bit in light of the confusion here: http://stackoverflow.com/q/3687864/3594

Not sure if it applies to 3k trunk.

First documentation patch, be sure to lmk what I'm doing wrong! :-)

----------
assignee: docs at python
components: Documentation
files: pyloggingdoc.diff
keywords: patch
messages: 116067
nosy: cdleary, docs at python
priority: normal
severity: normal
status: open
title: Clarify LogRecord documentation
versions: Python 2.7
Added file: http://bugs.python.org/file18842/pyloggingdoc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9827>
_______________________________________

From report at bugs.python.org  Sat Sep 11 06:37:46 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 11 Sep 2010 04:37:46 +0000
Subject: [New-bugs-announce] [issue9828] Repeated Py_Initialize and
	Py_Finalize usage brings fatal	error?
In-Reply-To: <1284179866.79.0.151055672964.issue9828@psf.upfronthosting.co.za>
Message-ID: <1284179866.79.0.151055672964.issue9828@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

When I ran the code in #6869 (msg95444) on py3k, I noticed
Fatal Python error occurs.

# Actually, I need to copy created executable file into
# PC/VC6 directoly where python32_d.dll exists. Otherwise,
# the error "encoding.utf-8 was not found" occured even if
# PC/VC6 was added to environment variable PATH. But probably
# it is another issue.

E:\python-dev\py3k\PC\VC6>foo
--- 0 ---
[34859 refs]
--- 1 ---
Fatal Python error: drop_gil: wrong thread state

... And here is stacktrace.

_NMSG_WRITE(int 10) line 221
abort() line 44 + 7 bytes
Py_FatalError(const char * 0x1e371878) line 2109
drop_gil(_ts * 0x00920d90) line 321 + 10 bytes
PyEval_SaveThread() line 424 + 6 bytes
0012ff30()
PyCFunction_Call(_object * 0x00b99378, _object * 0x00afcc40, _object * 0x00000000) line 89 + 9 bytes
PyObject_Call(_object * 0x00b99378, _object * 0x00afcc40, _object * 0x00000000) line 2149 + 15 bytes
call_function_tail(_object * 0x00b99378, _object * 0x00afcc40) line 2181 + 15 bytes
_PyObject_CallMethod_SizeT(_object * 0x00bf6838, char * 0x1e332898, char * 0x00000000) line 2297 + 13 bytes
io_open(_object * 0x00c17f78, _object * 0x00ae0f88, _object * 0x00000000) line 423 + 16 bytes
PyCFunction_Call(_object * 0x00b0cab8, _object * 0x00ae0f88, _object * 0x00000000) line 84 + 15 bytes
PyObject_Call(_object * 0x00b0cab8, _object * 0x00ae0f88, _object * 0x00000000) line 2149 + 15 bytes
call_function_tail(_object * 0x00b0cab8, _object * 0x00ae0f88) line 2181 + 15 bytes
PyObject_CallMethod(_object * 0x00bf6138, char * 0x1e3d6abc, char * 0x1e3d6ab4) line 2258 + 13 bytes
create_stdio(_object * 0x00bf6138, int 0, int 0, char * 0x1e3d6968, char * 0x00000000, char * 0x00000000) line 808 + 48 bytes
initstdio() line 931 + 28 bytes
Py_InitializeEx(int 1) line 303 + 5 bytes
Py_Initialize() line 314 + 7 bytes
main() line 10 + 8 bytes
mainCRTStartup() line 206 + 25 bytes
KERNEL32! 77e789d5()

Because first run succeeded, Py_Finalize might not do enough
work to reset thread state, I guess.

I didn't try this on other platforms. (thread_nt.h was used here)

----------
components: Interpreter Core
messages: 116075
nosy: ocean-city
priority: normal
severity: normal
status: open
title: Repeated Py_Initialize and Py_Finalize usage brings fatal error?
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9828>
_______________________________________

From report at bugs.python.org  Sat Sep 11 07:06:26 2010
From: report at bugs.python.org (bsidhom)
Date: Sat, 11 Sep 2010 05:06:26 +0000
Subject: [New-bugs-announce] [issue9829] Unexpected Fraction.from_float()
	Behavior
In-Reply-To: <1284181586.06.0.381689525187.issue9829@psf.upfronthosting.co.za>
Message-ID: <1284181586.06.0.381689525187.issue9829@psf.upfronthosting.co.za>


New submission from bsidhom <bsidhom at gmail.com>:

The Fractions.from_float() call returns an incorrect value when run on certain numbers. Some test runs have been listed below. Note that this problem does not exist when the same float is converted to a string and then passed to the standard Fraction() constructor; I do not know if this is an inherent problem due to the structure of the float itself or an implementation issue.

>>> for x in [1.23, 1.24, 1.25, 1.26, 1.27]:
	print(Fraction.from_float(x))
	print(Fraction(str(x)))

	
2769713770832855/2251799813685248
123/100
5584463537939415/4503599627370496
31/25
5/4
5/4
5674535530486825/4503599627370496
63/50
2859785763380265/2251799813685248
127/100

The problem does not exist if a string literal is passed either:

>>> print(Fraction('1.23'))
123/100

----------
components: Library (Lib)
messages: 116076
nosy: bsidhom
priority: normal
severity: normal
status: open
title: Unexpected Fraction.from_float() Behavior
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9829>
_______________________________________

From report at bugs.python.org  Sat Sep 11 11:13:40 2010
From: report at bugs.python.org (Marco Buccini)
Date: Sat, 11 Sep 2010 09:13:40 +0000
Subject: [New-bugs-announce] [issue9830] Python 2.7 x64 not properly
	installed on Windows 7	(registry)
In-Reply-To: <1284196420.02.0.512208117975.issue9830@psf.upfronthosting.co.za>
Message-ID: <1284196420.02.0.512208117975.issue9830@psf.upfronthosting.co.za>


New submission from Marco Buccini <marcusbu at gmail.com>:

I've just installed Python 2.7 x86-64, on my 64-bit Windows 7, then I've tried to install some packages - such as setuptools and pyside - but a message during the installation said something like "Cannot find Python2.7 in the windows registry".

So I've removed the 64-bit version of Python, then I've installed that one of 32-bit and, as expected, it works fine.

I've also tried to search on google to see if it's a Python bug or not, but I've found only this unreachable link: http://bugs.python.org/setuptools/issue2

Do you confirm this bug?

----------
components: Installation
messages: 116083
nosy: markon
priority: normal
severity: normal
status: open
title: Python 2.7 x64 not properly installed on Windows 7 (registry)
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9830>
_______________________________________

From report at bugs.python.org  Sat Sep 11 11:46:20 2010
From: report at bugs.python.org (Ismail Donmez)
Date: Sat, 11 Sep 2010 09:46:20 +0000
Subject: [New-bugs-announce] [issue9831] test_distutils fails on MacOSX 10.6
In-Reply-To: <1284198380.71.0.192975016699.issue9831@psf.upfronthosting.co.za>
Message-ID: <1284198380.71.0.192975016699.issue9831@psf.upfronthosting.co.za>


New submission from Ismail Donmez <ismail at namtrac.org>:

Using py3k branch revision 84707, on Mac OSX 10.6, case-sensitive HFS+ filesystem.


======================================================================
FAIL: test_package_data (distutils.tests.test_build_py.BuildPyTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/distutils/tests/test_build_py.py", line 56, in test_package_data
    self.assertTrue("__init__.pyc" in files)
AssertionError: False is not True

----------
components: Tests
messages: 116084
nosy: cartman
priority: normal
severity: normal
status: open
title: test_distutils fails on MacOSX 10.6
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9831>
_______________________________________

From report at bugs.python.org  Sat Sep 11 11:47:18 2010
From: report at bugs.python.org (Ismail Donmez)
Date: Sat, 11 Sep 2010 09:47:18 +0000
Subject: [New-bugs-announce] [issue9832] test_unicodedata fails on MacOSX
	10.6
In-Reply-To: <1284198438.38.0.986581404777.issue9832@psf.upfronthosting.co.za>
Message-ID: <1284198438.38.0.986581404777.issue9832@psf.upfronthosting.co.za>


New submission from Ismail Donmez <ismail at namtrac.org>:

Using py3k branch revision 84707, on Mac OSX 10.6, case-sensitive HFS+ filesystem.


======================================================================
FAIL: test_ucd_510 (test.test_unicodedata.UnicodeMiscTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/test/test_unicodedata.py", line 266, in test_ucd_510
    self.assertTrue("\u1d79".upper()=='\ua77d')
AssertionError: False is not True

======================================================================
FAIL: test_method_checksum (test.test_unicodedata.UnicodeMethodsTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/test/test_unicodedata.py", line 67, in test_method_checksum
    self.assertEqual(result, self.expectedchecksum)
AssertionError: '72252619bcc5d47da59734c1a2bc8f8dd34e14f8' != '4504dffd035baea02c5b9de82bebc3d65e0e0baf'
- 72252619bcc5d47da59734c1a2bc8f8dd34e14f8
+ 4504dffd035baea02c5b9de82bebc3d65e0e0baf

----------
components: Tests
messages: 116085
nosy: cartman
priority: normal
severity: normal
status: open
title: test_unicodedata fails on MacOSX 10.6
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9832>
_______________________________________

From report at bugs.python.org  Sat Sep 11 11:48:13 2010
From: report at bugs.python.org (Ismail Donmez)
Date: Sat, 11 Sep 2010 09:48:13 +0000
Subject: [New-bugs-announce] [issue9833] test_ttk_guionly fails on MacOSX
	10.6
In-Reply-To: <1284198493.67.0.22042162237.issue9833@psf.upfronthosting.co.za>
Message-ID: <1284198493.67.0.22042162237.issue9833@psf.upfronthosting.co.za>


New submission from Ismail Donmez <ismail at namtrac.org>:

Using py3k branch revision 84707, on Mac OSX 10.6, case-sensitive HFS+ filesystem.


======================================================================
ERROR: test_tab_identifiers (tkinter.test.test_ttk.test_widgets.NotebookTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/tkinter/test/test_ttk/test_widgets.py", line 560, in test_tab_identifiers
    self.assertEqual(self.nb.tab('@5,5'), self.nb.tab('current'))
  File "/Users/cartman/Sources/py3k/Lib/tkinter/ttk.py", line 922, in tab
    return _val_or_dict(kw, self.tk.call, self._w, "tab", tab_id)
  File "/Users/cartman/Sources/py3k/Lib/tkinter/ttk.py", line 318, in _val_or_dict
    res = func(*(args + options))
_tkinter.TclError: tab '@5,5' not found

======================================================================
FAIL: test_identify (tkinter.test.test_ttk.test_widgets.WidgetTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/tkinter/test/test_ttk/test_widgets.py", line 27, in test_identify
    self.assertEqual(self.widget.identify(5, 5), "label")
AssertionError: 'Button.button' != 'label'
- Button.button
+ label


======================================================================
FAIL: test_traversal (tkinter.test.test_ttk.test_widgets.NotebookTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/tkinter/test/test_ttk/test_widgets.py", line 721, in test_traversal
    self.assertEqual(self.nb.select(), str(self.child1))
AssertionError: '.4320099472' != '.4320099600'
- .4320099472
?         ^^^
+ .4320099600
?         ^^^

----------
components: Tests
messages: 116086
nosy: cartman
priority: normal
severity: normal
status: open
title: test_ttk_guionly fails on MacOSX 10.6
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9833>
_______________________________________

From report at bugs.python.org  Sat Sep 11 13:24:46 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 11 Sep 2010 11:24:46 +0000
Subject: [New-bugs-announce] [issue9834] PySequence_GetSlice() lacks a NULL
	check
In-Reply-To: <1284204286.26.0.294776311301.issue9834@psf.upfronthosting.co.za>
Message-ID: <1284204286.26.0.294776311301.issue9834@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

PySequence_GetSlice() in Objects/abstract.c contains the following code:

    mp = s->ob_type->tp_as_mapping;
    if (mp->mp_subscript) {

This crashes when the type's "tp_as_mapping" is NULL. The obvious fix is to simply write

    if (mp && mp->mp_subscript)

as basically everywhere else around that function. The problem seems to have occurred during a rewrite for Python 3, it's ok in the 2.x series.

----------
components: Interpreter Core
messages: 116092
nosy: scoder
priority: normal
severity: normal
status: open
title: PySequence_GetSlice() lacks a NULL check
type: crash
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9834>
_______________________________________

From report at bugs.python.org  Sat Sep 11 14:12:00 2010
From: report at bugs.python.org (Thomas Sondergaard)
Date: Sat, 11 Sep 2010 12:12:00 +0000
Subject: [New-bugs-announce] [issue9835] ZipFile unix external attributes
	incorrect for entry	written with writestr
In-Reply-To: <1284207120.65.0.876260441068.issue9835@psf.upfronthosting.co.za>
Message-ID: <1284207120.65.0.876260441068.issue9835@psf.upfronthosting.co.za>


New submission from Thomas Sondergaard <thomas at sondergaard.cc>:

For entries written with writestr ZipFile doesn't record the file type in the unix external attributes block. It should set it to "regular file" (S_IFREG).

The attached sample creates a zip file. If you inspect it with zipinfo -v, you will see that the unix file type is not correct for the entry stored with writestr.

[ts at roadrunner ~]$ zipinfo -v test.zip |grep "Unix file attributes"
  Unix file attributes (000600 octal):              ?rw-------
  Unix file attributes (100664 octal):              -rw-rw-r--

----------
components: Library (Lib)
files: test.py
messages: 116093
nosy: Thomas.Sondergaard
priority: normal
severity: normal
status: open
title: ZipFile unix external attributes incorrect for entry written with writestr
type: behavior
Added file: http://bugs.python.org/file18846/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9835>
_______________________________________

From report at bugs.python.org  Sat Sep 11 15:54:45 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 11 Sep 2010 13:54:45 +0000
Subject: [New-bugs-announce] [issue9836] Refleak in PyUnicode_FormatV
In-Reply-To: <1284213285.44.0.689496664907.issue9836@psf.upfronthosting.co.za>
Message-ID: <1284213285.44.0.689496664907.issue9836@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

I noticed following refleak.

http://mail.python.org/pipermail/python-checkins/2010-September/097438.html

py3k results for svn r84704 (hg cset 4ffcca0d1896)
--------------------------------------------------

test_unicode leaked [2, 2, 2] references, sum=6

This refleak seems to be introduced in r84704.
I hope attached patch will fix this.

----------
components: Unicode
messages: 116095
nosy: ocean-city
priority: normal
severity: normal
status: open
title: Refleak in PyUnicode_FormatV
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9836>
_______________________________________

From report at bugs.python.org  Sun Sep 12 11:28:15 2010
From: report at bugs.python.org (Black Dew)
Date: Sun, 12 Sep 2010 09:28:15 +0000
Subject: [New-bugs-announce] [issue9837] ZipFileExt.read() reads more data
	than requested
In-Reply-To: <1284283695.55.0.592905912112.issue9837@psf.upfronthosting.co.za>
Message-ID: <1284283695.55.0.592905912112.issue9837@psf.upfronthosting.co.za>


New submission from Black Dew <blackdew at gmail.com>:

ZipFileExt.read() can return more data than requested, unlike file and other file-like objects.

This function calls read1() in a loop, passing the original requested size even if part of the data was already read thus reading and returning more than the caller requested.

This should be fixed by requesting n-len(buf) or something similar, or at least properly documented.

----------
components: Library (Lib)
messages: 116158
nosy: Black.Dew
priority: normal
severity: normal
status: open
title: ZipFileExt.read() reads more data than requested
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9837>
_______________________________________

From report at bugs.python.org  Sun Sep 12 15:23:47 2010
From: report at bugs.python.org (Pauli Virtanen)
Date: Sun, 12 Sep 2010 13:23:47 +0000
Subject: [New-bugs-announce] [issue9838] Inadequate C-API to Python 3 I/O
	objects
In-Reply-To: <1284297827.04.0.573858766917.issue9838@psf.upfronthosting.co.za>
Message-ID: <1284297827.04.0.573858766917.issue9838@psf.upfronthosting.co.za>


New submission from Pauli Virtanen <pav at iki.fi>:

The C-API exposed by the `io` module on Python 3.1/3.2 is very limited, and makes interfacing with Python file objects in extension modules difficult.

In more detail:

1) Because the Python layer has buffering etc., the file handle returned by `PyObject_AsFileDescriptor` is not usable as-is. It requires flush and seek before use, every time there is a chance that the file object has been accessed on the Python side. 

2) There are no C-API functions such as the minimal set of `PyFile_Write(buf, length)`, `PyFile_Read(buf, length)`, `PyFile_Seek(pos, whence)`, `PyFile_Tell()`.

Instead, every call must go through PyObject_CallMethod, and the file objects only handle `PyBytes` and `PyByteArray` which are cumbersome and inefficient to use in extension modules.

----------
components: Extension Modules
messages: 116188
nosy: pv
priority: normal
severity: normal
status: open
title: Inadequate C-API to Python 3 I/O objects
type: feature request
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9838>
_______________________________________

From report at bugs.python.org  Sun Sep 12 15:23:50 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 13:23:50 +0000
Subject: [New-bugs-announce] [issue9839] Test issue
In-Reply-To: <1284297830.23.0.244332630291.issue9839@psf.upfronthosting.co.za>
Message-ID: <1284297830.23.0.244332630291.issue9839@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

Will this have two patch keywords?

----------
files: rss.xml.diff
keywords: patch
messages: 116189
nosy: loewis
priority: normal
severity: normal
status: open
title: Test issue
Added file: http://bugs.python.org/file18859/rss.xml.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9839>
_______________________________________

From report at bugs.python.org  Mon Sep 13 00:13:20 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 12 Sep 2010 22:13:20 +0000
Subject: [New-bugs-announce] [issue9840] Recursive Repr
In-Reply-To: <1284329600.42.0.558454209322.issue9840@psf.upfronthosting.co.za>
Message-ID: <1284329600.42.0.558454209322.issue9840@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

Add a recursive_repr() decorator to provide a solution to the problem of creating a container __repr__ method that doesn't fail for recursive calls.

----------
files: recursive_repr.patch
keywords: patch
messages: 116239
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Recursive Repr
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file18862/recursive_repr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9840>
_______________________________________

From report at bugs.python.org  Mon Sep 13 01:26:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 23:26:28 +0000
Subject: [New-bugs-announce] [issue9841] sysconfig and distutils.sysconfig
	differ in subtle ways
In-Reply-To: <1284333988.17.0.109581594915.issue9841@psf.upfronthosting.co.za>
Message-ID: <1284333988.17.0.109581594915.issue9841@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

With the recent distutils revert, code that was removed from distutils.sysconfig is now back.  This causes an unfortunate code duplication that raises maintenance cost (see msg116087 for an example).

Even if distutils is feature-frozen, I think that it should be changed to use the sysconfig module again.  Think about it that way: The new feature is sysconfig itself, this does not break the distutils freeze since compatibility would be retained.

----------
assignee: tarek
components: Distutils, Library (Lib)
messages: 116251
nosy: eric.araujo, tarek
priority: normal
severity: normal
status: open
title: sysconfig and distutils.sysconfig differ in subtle ways
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9841>
_______________________________________

From report at bugs.python.org  Mon Sep 13 02:05:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 13 Sep 2010 00:05:24 +0000
Subject: [New-bugs-announce] [issue9842] Document ... used in recursive repr
	of containers
In-Reply-To: <1284336324.93.0.400210409006.issue9842@psf.upfronthosting.co.za>
Message-ID: <1284336324.93.0.400210409006.issue9842@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Built-in containers like dict use an ellipsis to represent a recursive item.  In the symbols index, ?...? only links to the secondary prompt; I think it should also link to a paragraph explaining the display of recursive containers.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 116256
nosy: docs at python, eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Document ... used in recursive repr of containers
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9842>
_______________________________________

From report at bugs.python.org  Mon Sep 13 03:22:05 2010
From: report at bugs.python.org (Demur Rumed)
Date: Mon, 13 Sep 2010 01:22:05 +0000
Subject: [New-bugs-announce] [issue9843] imp documentation redundancy with
	acquire_lock and	release_lock
In-Reply-To: <1284340925.23.0.318731794312.issue9843@psf.upfronthosting.co.za>
Message-ID: <1284340925.23.0.318731794312.issue9843@psf.upfronthosting.co.za>


New submission from Demur Rumed <junkmute at hotmail.com>:

http://docs.python.org/dev/library/imp.html

acquire_lock and release_lock are listed twice. The first iteration of acquire_lock repeats "On platforms without threads, this function does nothing." twice and advises release, while the latter does not

----------
assignee: docs at python
components: Documentation
messages: 116267
nosy: docs at python, serprex
priority: normal
severity: normal
status: open
title: imp documentation redundancy with acquire_lock and release_lock

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9843>
_______________________________________

From report at bugs.python.org  Mon Sep 13 08:19:28 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 13 Sep 2010 06:19:28 +0000
Subject: [New-bugs-announce] [issue9844] calling nonexisting function under
	__INSURE__
In-Reply-To: <1284358768.31.0.932745075936.issue9844@psf.upfronthosting.co.za>
Message-ID: <1284358768.31.0.932745075936.issue9844@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

The Py_Main function has a section under #ifdef __INSURE__ at the end, where it does:

    _Py_ReleaseInternedStrings();
    _Py_ReleaseInternedUnicodeStrings();

The first function doesn't exist in Python 3K, so there will be a compile error with __INSURE__ defined.

----------
components: Interpreter Core
messages: 116281
nosy: eli.bendersky
priority: normal
severity: normal
status: open
title: calling nonexisting function under __INSURE__
type: compile error
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9844>
_______________________________________

From report at bugs.python.org  Mon Sep 13 15:07:15 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 13 Sep 2010 13:07:15 +0000
Subject: [New-bugs-announce] [issue9845] Allow changing the method in
	urllib.request.Request
In-Reply-To: <1284383235.98.0.831352562835.issue9845@psf.upfronthosting.co.za>
Message-ID: <1284383235.98.0.831352562835.issue9845@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

Right now you have to override Request or patch its get_method() method to be able to send HTTP requests where the method is not GET or POST.

This is making some assumptions on what the users wants to do with the request. The way get_method guesses the method is good enough in most cases, but I think it would be good to let advanced developers provide their own method when they build a request.  This would avoid unnecessary boiler-plate code to be able to customize the method.

----------
assignee: orsenthil
components: Library (Lib)
files: request_custom_method.patch
keywords: patch
messages: 116301
nosy: orsenthil, tarek
priority: normal
severity: normal
status: open
title: Allow changing the method in urllib.request.Request
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file18869/request_custom_method.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9845>
_______________________________________

From report at bugs.python.org  Mon Sep 13 18:17:20 2010
From: report at bugs.python.org (John Admanski)
Date: Mon, 13 Sep 2010 16:17:20 +0000
Subject: [New-bugs-announce] [issue9846] ZipExtFile provides no mechanism
	for closing the	underlying file object
In-Reply-To: <1284394640.99.0.715812735205.issue9846@psf.upfronthosting.co.za>
Message-ID: <1284394640.99.0.715812735205.issue9846@psf.upfronthosting.co.za>


New submission from John Admanski <jadmanski at gmail.com>:

When creating a ZipExtFile through ZipFile.open, the if the original ZipFile object was created with a filename then a new file object will be opened and given to the ZipExtFile to use for its file operations. There is no explicit mechanism that will allow you to release this file.

ZipExtFile does have an (undocumented?) close method, but this won't actually close the file object that underlies it; probably because it has no way of knowing if it actually owns the file object or if it just has a reference to a file object that belongs to the ZipFile.

You can work around this by destroying references to the ZipExtFile and letting the file's __del__ handle the close for you but this relies on implementation details of ZipExtFile.

Found in Python 3.1 but a look at svn.python.org suggests that this problem is still there in 2.7 and 3.2; however, I haven't actually tried it with them.

----------
components: Library (Lib)
messages: 116322
nosy: john.admanski
priority: normal
severity: normal
status: open
title: ZipExtFile provides no mechanism for closing the underlying file object
type: feature request
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9846>
_______________________________________

From report at bugs.python.org  Mon Sep 13 19:31:15 2010
From: report at bugs.python.org (James Hutchison)
Date: Mon, 13 Sep 2010 17:31:15 +0000
Subject: [New-bugs-announce] [issue9847] Binary strings never compare equal
	to raw/normal strings
In-Reply-To: <1284399075.73.0.514162795967.issue9847@psf.upfronthosting.co.za>
Message-ID: <1284399075.73.0.514162795967.issue9847@psf.upfronthosting.co.za>


New submission from James Hutchison <jamesghutchison at gmail.com>:

Tested on Python 3.1.2 Windows XP 32-bit

Binary strings (such as what is returned by filereader.readline()) are never equal to raw or normal strings, even when both strings are empty

if(b"" == ""):
    print("Strings are equal");
    else:
        if(b"" == r""):
            print("raw and binary equal, normal isn't");
        else:
            print("they aren't equal");

output: they aren't equal

----------
components: Interpreter Core
messages: 116331
nosy: Jimbofbx
priority: normal
severity: normal
status: open
title: Binary strings never compare equal to raw/normal strings
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9847>
_______________________________________

From report at bugs.python.org  Mon Sep 13 21:31:47 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 13 Sep 2010 19:31:47 +0000
Subject: [New-bugs-announce] [issue9848] setup.py contains needless
	references to built-in	_weakref module
In-Reply-To: <1284406307.9.0.78586268452.issue9848@psf.upfronthosting.co.za>
Message-ID: <1284406307.9.0.78586268452.issue9848@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

_weakref module is a built-in module in Python 3 since r58602, but references to _weakref module in setup.py haven't been removed. They can be removed in py3k and 3.1 branches.

setup.py in 2.7 branch (since r84233) contains unused, commented out reference to _weakref module, which also can be removed.

----------
components: Build
messages: 116343
nosy: Arfrever, georg.brandl
priority: normal
severity: normal
status: open
title: setup.py contains needless references to built-in _weakref module
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9848>
_______________________________________

From report at bugs.python.org  Tue Sep 14 01:25:12 2010
From: report at bugs.python.org (Jason Baker)
Date: Mon, 13 Sep 2010 23:25:12 +0000
Subject: [New-bugs-announce] [issue9849] Argparse needs better error
	handling for nargs
In-Reply-To: <1284420312.86.0.187137843637.issue9849@psf.upfronthosting.co.za>
Message-ID: <1284420312.86.0.187137843637.issue9849@psf.upfronthosting.co.za>


New submission from Jason Baker <amnorvend at gmail.com>:

This is referring to argparse 1.1 installed under Python 2.6.  When I was passing in an nargs flag, I figured that since '+' and '*' are valid options, I should pass in strings.  So when I tried passing in the string '1' instead of the integer 1, I got the following error:


>>> import argparse

>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('foo', nargs='1')
_StoreAction(option_strings=[], dest='foo', nargs='1', const=None, default=None, type=None, choices=None, help=None, metavar=None)

>>> parser.parse_args()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "build/bdist.macosx-10.6-universal/egg/argparse.py", line 1698, in parse_args
  File "build/bdist.macosx-10.6-universal/egg/argparse.py", line 1730, in parse_known_args
  File "build/bdist.macosx-10.6-universal/egg/argparse.py", line 1935, in _parse_known_args
  File "build/bdist.macosx-10.6-universal/egg/argparse.py", line 1884, in consume_positionals
  File "build/bdist.macosx-10.6-universal/egg/argparse.py", line 2028, in _match_arguments_partial
  File "build/bdist.macosx-10.6-universal/egg/argparse.py", line 2169, in _get_nargs_pattern
TypeError: can't multiply sequence by non-int of type 'str'

Fortunately, I had just added the nargs and knew to correct that.  However, if I were to do something like read that value in from a config file and forget to coerce the value from a string to an int, I could see how this could be a giant pain to track down.

----------
components: Library (Lib)
messages: 116355
nosy: Jason.Baker
priority: normal
severity: normal
status: open
title: Argparse needs better error handling for nargs
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9849>
_______________________________________

From report at bugs.python.org  Tue Sep 14 07:14:13 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 14 Sep 2010 05:14:13 +0000
Subject: [New-bugs-announce] [issue9850] obsolete macpath module dangerously
	broken and should be	removed
In-Reply-To: <1284441253.52.0.765024184015.issue9850@psf.upfronthosting.co.za>
Message-ID: <1284441253.52.0.765024184015.issue9850@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

The macpath module in the standard library purports to supply "the Mac OS 9 (and earlier) implementation of the os.path module.  It can be used to manipulate old-style Macintosh pathnames on Mac OS X (or any other platform).  The following functions are available in this module: normcase(), normpath(), isabs(), join(), split(), isdir(), isfile(), walk(), exists(). For other functions available in os.path dummy counterparts are available."

Old-style Mac pathnames are not further documented - in fact, the above quote is the entire external documentation for the module - but they are ones using colon separators, like ("MacHD:Users:nad:macpath_test:file"). These style path names were initially supported on Mac OS X by compatibility APIs for programs ported from classic Mac OS but those interfaces have long been deprecated in OS X and in most cases are not available in 64-bit execution mode.

Even if one did have a need to use the obsolete old-style paths, the macpath module is currently practically unusable for anything other than simple character manipulations of the path.  Nearly all of the functions that actually call OS routines are broken in one or more ways.

Those that do make file system calls are calling APIs that are expecting normal posix-style ('/' separated paths) incorrectly with old-style (":) paths (ispath, isdir, lexists, etc) which means they only give correct results in the trivial case of unqualified file or directory names, i.e. those in the working directory.

The islink() function confusingly is testing whether a path points to a Finder Alias file (not a symlink).  Unfortunately, the Carbon API used for that test does not exist in a 64-bit version and all of the Python Carbon modules were removed in Python 3.

$ arch -i386 python2.7 -c 'import macpath; print(macpath.islink("alias_to_file"))'
1
$ arch -x86_64 python2.7 -c 'import macpath; print(macpath.islink("alias_to_file"))'
False
$ python3.2 -c 'import macpath; print(macpath.islink("alias_to_file"))'
False

The underlying import errors are being masked by "try"'s:

$ arch -i386 python2.7 -c 'import Carbon.File; Carbon.File.ResolveAliasFile'
$ arch -x86_64 python2.7 -c 'import Carbon.File; Carbon.File.ResolveAliasFile'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
AttributeError: 'module' object has no attribute 'ResolveAliasFile'
$ python3.1 -c 'import Carbon.File; Carbon.File.ResolveAliasFile'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named Carbon.File

The realpath function is also broken in 2.7, calling Carbon.File.FSResolveAliasFile with a ":" separated path when it expects a "/" path, and is totally broken in 3.x (no Carbon modules).


While ospath *could* be repaired by proper documentation, fixing the mishmash of path types internally, and supplying C wrappers and/or alternative 64-bit APIs, it does not seem worth the effort as these style paths are seldom encountered in modern code.  Considering how broken the module currently is and given that it probably was simply overlooked in the Python 2 to 3 transition, I think a case could be made for immediate removal prior to Python 3.2 release and even for a 3.1.x maintenance release.  Short of that, it should be cleared documented as deprecated in 3.2, 3.1, and 2.7 along with warnings about broken functionality along with added DeprecationWarnings to the module.

I can write up patches to do that depending on what the consensus is.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 116365
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: obsolete macpath module dangerously broken and should be removed
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9850>
_______________________________________

From report at bugs.python.org  Tue Sep 14 10:28:42 2010
From: report at bugs.python.org (hume)
Date: Tue, 14 Sep 2010 08:28:42 +0000
Subject: [New-bugs-announce] [issue9851] multiprocessing socket timeout will
	break client
In-Reply-To: <1284452922.14.0.631964759206.issue9851@psf.upfronthosting.co.za>
Message-ID: <1284452922.14.0.631964759206.issue9851@psf.upfronthosting.co.za>


New submission from hume <humeafo at gmail.com>:

when use multiprocessing managers, while use socket to communicate between server process and client process, if I used the global socket timeout feature(no matter how large the value is) the client will always say

  File "c:\python27\lib\multiprocessing\connection.py", line 149, in Client
    answer_challenge(c, authkey)
  File "c:\python27\lib\multiprocessing\connection.py", line 383, in answer_challenge
    message = connection.recv_bytes(256)         # reject large message
IOError: [Errno 10035] 

this is not reasonable, because this behaviour will make subprocess unable to use socket's timeout features globally.

Another question is line 138 in managers.py:
        # do authentication later
        self.listener = Listener(address=address, backlog=5)
        self.address = self.listener.address

backlog=5 will accept only 5 cocurrent connections, this is stupid, you'd better make this a argument that can be specified by user

----------
components: Library (Lib)
messages: 116375
nosy: hume
priority: normal
severity: normal
status: open
title: multiprocessing socket timeout will break client
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9851>
_______________________________________

From report at bugs.python.org  Tue Sep 14 14:05:48 2010
From: report at bugs.python.org (Ismail Donmez)
Date: Tue, 14 Sep 2010 12:05:48 +0000
Subject: [New-bugs-announce] [issue9852] test_ctypes fail with clang
In-Reply-To: <1284465948.07.0.835658917717.issue9852@psf.upfronthosting.co.za>
Message-ID: <1284465948.07.0.835658917717.issue9852@psf.upfronthosting.co.za>


New submission from Ismail Donmez <ismail at namtrac.org>:

This is probably a clang bug but this is the only test failing with clang:


======================================================================
FAIL: test_byte (ctypes.test.test_cfuncs.CFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/ctypes/test/test_cfuncs.py", line 20, in test_byte
    self.assertEqual(self._dll.tf_b(-126), -42)
AssertionError: 43 != -42

======================================================================
FAIL: test_byte_plus (ctypes.test.test_cfuncs.CFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/ctypes/test/test_cfuncs.py", line 26, in test_byte_plus
    self.assertEqual(self._dll.tf_bb(0, -126), -42)
AssertionError: 43 != -42

======================================================================
FAIL: test_short (ctypes.test.test_cfuncs.CFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/ctypes/test/test_cfuncs.py", line 44, in test_short
    self.assertEqual(self._dll.tf_h(-32766), -10922)
AssertionError: 10923 != -10922

======================================================================
FAIL: test_short_plus (ctypes.test.test_cfuncs.CFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/ctypes/test/test_cfuncs.py", line 50, in test_short_plus
    self.assertEqual(self._dll.tf_bh(0, -32766), -10922)
AssertionError: 10923 != -10922

======================================================================
FAIL: test_doubleresult (ctypes.test.test_functions.FunctionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/ctypes/test/test_functions.py", line 143, in test_doubleresult
    self.assertEqual(result, -21)
AssertionError: 65771.0 != -21

======================================================================
FAIL: test_floatresult (ctypes.test.test_functions.FunctionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/ctypes/test/test_functions.py", line 131, in test_floatresult
    self.assertEqual(result, -21)
AssertionError: 65771.0 != -21

======================================================================
FAIL: test_intresult (ctypes.test.test_functions.FunctionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/ctypes/test/test_functions.py", line 105, in test_intresult
    self.assertEqual(result, -21)
AssertionError: 65771 != -21

======================================================================
FAIL: test_longdoubleresult (ctypes.test.test_functions.FunctionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/ctypes/test/test_functions.py", line 155, in test_longdoubleresult
    self.assertEqual(result, -21)
AssertionError: 65771.0 != -21

----------
assignee: theller
components: ctypes
messages: 116392
nosy: cartman, theller
priority: normal
severity: normal
status: open
title: test_ctypes fail with clang
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9852>
_______________________________________

From report at bugs.python.org  Tue Sep 14 15:09:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 13:09:43 +0000
Subject: [New-bugs-announce] [issue9853] Wrong signature for
	SSLSocket.recvfrom
In-Reply-To: <1284469783.13.0.12192351164.issue9853@psf.upfronthosting.co.za>
Message-ID: <1284469783.13.0.12192351164.issue9853@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

SSLSocket.recvfrom includes an `addr` argument in its signature, but socket.recvfrom doesn't take such an argument. It should be removed.
(obviously, this method is neither tested nor used in the real-world...)

In 2.7, this is taken care of by the patch in issue9729.

----------
messages: 116397
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Wrong signature for SSLSocket.recvfrom
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9853>
_______________________________________

From report at bugs.python.org  Tue Sep 14 18:20:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 16:20:11 +0000
Subject: [New-bugs-announce] [issue9854] SocketIO should return None on
	EWOULDBLOCK
In-Reply-To: <1284481211.95.0.424459514211.issue9854@psf.upfronthosting.co.za>
Message-ID: <1284481211.95.0.424459514211.issue9854@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

SocketIO claims to implement RawIOBase, but it lets blocking IO errors pass through on non-blocking sockets:

>>> s = socket.create_connection(("python.org", 80)); s.settimeout(0.0)
>>> f = s.makefile("rb", buffering=0)
>>> f.readinto(bytearray(10))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/py3k/nntp-9360/Lib/socket.py", line 228, in readinto
    return self._sock.recv_into(b)
socket.error: [Errno 11] Resource temporarily unavailable

Instead, readinto() should detect the blocking condition (EAGAIN / EWOULDBLOCK) and return None (same for write(), I imagine).

There also seems to be a problem in the default read() implementation in RawIOBase, which doesn't accept a possible None result from readinto():

>>> f.readinto = lambda x: None
>>> f.read(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'NoneType' object cannot be interpreted as an integer

(the RawIOBase docs themselves don't mention that readinto() can return None, but it's the only logical possibility: catching EWOULDBLOCK in read() but not in readinto() wouldn't make sense)

----------
components: IO, Library (Lib)
messages: 116408
nosy: amaury.forgeotdarc, benjamin.peterson, pitrou, stutzbach
priority: normal
severity: normal
status: open
title: SocketIO should return None on EWOULDBLOCK
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9854>
_______________________________________

From report at bugs.python.org  Tue Sep 14 18:50:23 2010
From: report at bugs.python.org (Tom)
Date: Tue, 14 Sep 2010 16:50:23 +0000
Subject: [New-bugs-announce] [issue9855] Complex number slicing neither
	works nor causes an error	on immediate use
In-Reply-To: <1284483023.7.0.0398180886345.issue9855@psf.upfronthosting.co.za>
Message-ID: <1284483023.7.0.0398180886345.issue9855@psf.upfronthosting.co.za>


New submission from Tom <tom at littlemonster.co.uk>:

I hope the title of this makes sense. I've been out of things for a long time.

Going through the Python tutorial (http://docs.python.org/tutorial/introduction.html) I departed from the script to try something. It gave neither of the results I had thought it might.

    >>> (0+1j)*(0+1j).imag
    1j
    >>> (0+1j)*(0+1j).real
    0j
    >>> a=(0+1j)*(0+1j)
    >>> a.imag
    0.0
    >>> a.real
    -1.0
    >>> 

This being my first crack at this language, I may have missed something that is obvious to the more experienced.

In my naivety, I thought that slicing the result of a calculation should work - why not? It should have the same structure as that pointed to by a variable.

So I'll leave this for either somebody with the patience to put me straight or somebody to fix.

Cheers!

----------
messages: 116409
nosy: LittleMonster
priority: normal
severity: normal
status: open
title: Complex number slicing neither works nor causes an error on immediate use
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9855>
_______________________________________

From report at bugs.python.org  Tue Sep 14 19:26:58 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 14 Sep 2010 17:26:58 +0000
Subject: [New-bugs-announce] [issue9856] Change object.__format__(s) where s
	is non-empty to a	DeprecationWarning
In-Reply-To: <1284485218.75.0.159147258754.issue9856@psf.upfronthosting.co.za>
Message-ID: <1284485218.75.0.159147258754.issue9856@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

In 3.3 the existing PendingDeprecationWarning needs to become a DeprecationWarning. In 3.4 it will become an error.

I'll change 3.3 after 3.2 is released.

See issue 7994 for the original PendingDeprecationWarning discussion.

----------
assignee: eric.smith
components: Interpreter Core
keywords: easy
messages: 116413
nosy: eric.smith
priority: normal
severity: normal
status: open
title: Change object.__format__(s) where s is non-empty to a DeprecationWarning
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9856>
_______________________________________

From report at bugs.python.org  Tue Sep 14 23:45:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Sep 2010 21:45:19 +0000
Subject: [New-bugs-announce] [issue9857] SkipTest in tearDown is reported an
	as an error
In-Reply-To: <1284500719.22.0.435536478708.issue9857@psf.upfronthosting.co.za>
Message-ID: <1284500719.22.0.435536478708.issue9857@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Raising SkipTest when in a tearDown method is reported as an error, rather than a skipped test.
Now doing this sounds like a weird use case, but it would be actually useful when you have a worker thread, and the tearDown method collects the exception raised in that thread and raises it again. For the worker thread to be able to use skipTest(), a SkipTest exception raised in tearDown should be properly reported as a skip.

----------
assignee: michael.foord
components: Library (Lib)
messages: 116422
nosy: michael.foord, pitrou
priority: normal
severity: normal
status: open
title: SkipTest in tearDown is reported an as an error
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9857>
_______________________________________

From report at bugs.python.org  Wed Sep 15 10:53:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Sep 2010 08:53:13 +0000
Subject: [New-bugs-announce] [issue9858] RawIOBase doesn't define readinto
In-Reply-To: <1284540793.42.0.0185593652898.issue9858@psf.upfronthosting.co.za>
Message-ID: <1284540793.42.0.0185593652898.issue9858@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

RawIOBase is defined as having the readinto() method but it doesn't. It should at least have a failing one (raising io.UnsupportedOperation like the BufferedIOBase.{read,readinto} methods do).

This is, of course, mainly for auto-documenting purposes (with help() and friends).

----------
components: IO
keywords: easy
messages: 116440
nosy: pitrou
priority: low
severity: normal
stage: needs patch
status: open
title: RawIOBase doesn't define readinto
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9858>
_______________________________________

From report at bugs.python.org  Wed Sep 15 15:46:37 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 15 Sep 2010 13:46:37 +0000
Subject: [New-bugs-announce] [issue9859] Add tests to verify API match of
	modules with 2	implementations
In-Reply-To: <1284558397.04.0.990092096712.issue9859@psf.upfronthosting.co.za>
Message-ID: <1284558397.04.0.990092096712.issue9859@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

Recently it came to light that the classes in C and Python implementations of the io module have slightly different attributes (issue9858).  I propose the addition of a helper function in Lib/test/support.py to verify that the classes in two different implementations define the same attributes.  Then, we can add tests to use that function to verify that C and Python implementations define the same API (for the io module, but also for other modules where we have two implementations).  The script I added to issue9858 could serve as a starting point for such a function.

Since CPython's standard library is the de facto reference implementation, it's important that it define one API and not two slightly different ones. :-)

----------
components: Tests
messages: 116445
nosy: stutzbach
priority: low
severity: normal
stage: needs patch
status: open
title: Add tests to verify API match of modules with 2 implementations
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9859>
_______________________________________

From report at bugs.python.org  Wed Sep 15 16:08:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 15 Sep 2010 14:08:15 +0000
Subject: [New-bugs-announce] [issue9860] Building python outside of source
	directory fails
In-Reply-To: <1284559695.71.0.359508650396.issue9860@psf.upfronthosting.co.za>
Message-ID: <1284559695.71.0.359508650396.issue9860@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

When testing config options, it is often useful to build python in a directory different from the root of the source tree.  This is supported by autoconf based builds as follows: you cd to the desired directory run configure with an explicit path. For example:

$ cd ../altdir
$ ../python-source/configure
$ make

However, this fails for python 3.1 and 3.2 with the following error:


i686-apple-darwin10-gcc-4.2.1: Parser/tokenizer_pgen.o: No such file or directory
i686-apple-darwin10-gcc-4.2.1: Parser/printgrammar.o: No such file or directory
i686-apple-darwin10-gcc-4.2.1: Parser/pgenmain.o: No such file or directory
make: *** [Parser/pgen] Error 1

----------
assignee: belopolsky
components: Interpreter Core
messages: 116448
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: Building python outside of source directory fails
type: compile error
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9860>
_______________________________________

From report at bugs.python.org  Wed Sep 15 16:19:52 2010
From: report at bugs.python.org (paul clinch)
Date: Wed, 15 Sep 2010 14:19:52 +0000
Subject: [New-bugs-announce] [issue9861] subprocess module changed exposed
	attributes
In-Reply-To: <1284560392.0.0.232628441453.issue9861@psf.upfronthosting.co.za>
Message-ID: <1284560392.0.0.232628441453.issue9861@psf.upfronthosting.co.za>


New submission from paul clinch <pclinch at internet-glue.co.uk>:

Some attributes, e.g. STARTF_USESHOWWINDOW have moved to _subrocess.STARTF_USESHOWWINDOW. This breaks old code.

----------
components: Library (Lib)
messages: 116450
nosy: pclinch
priority: normal
severity: normal
status: open
title: subprocess module changed exposed attributes
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9861>
_______________________________________

From report at bugs.python.org  Wed Sep 15 18:30:34 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 15 Sep 2010 16:30:34 +0000
Subject: [New-bugs-announce] [issue9862] test_subprocess hangs on AIX
In-Reply-To: <1284568234.82.0.42184878799.issue9862@psf.upfronthosting.co.za>
Message-ID: <1284568234.82.0.42184878799.issue9862@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

On AIX, the test test_communicate_pipe_buf in test_subprocess will hang forever (in py3k and py27):

test_communicate_pipe_buf (__main__.ProcessTestCase) ... 


  File "Lib/test/test_subprocess.py", line 386, in test_communicate_pipe_buf
    (stdout, stderr) = p.communicate(string_to_write)
  File "/san_cis/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/Python-2.7-svn/Lib/subprocess.py", line 740, in communicate
    return self._communicate(input)
  File "/san_cis/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/Python-2.7-svn/Lib/subprocess.py", line 1257, in _communicate
    stdout, stderr = self._communicate_with_poll(input)
  File "/san_cis/home/cis/data/bamboo-home-agent-runtime/xml-data/build-dir/RTAIX30-SUP/Python-2.7-svn/Lib/subprocess.py", line 1320, in _communicate_with_poll
    input_offset += os.write(fd, chunk)
KeyboardInterrupt

The comment in this test indicates:
  # communicate() with writes larger than pipe_buf
  # This test will probably deadlock rather than fail, if
  # communicate() does not work properly.

So I guess it means communicate() does not work properly on AIX.

----------
components: Library (Lib)
messages: 116467
nosy: sable
priority: normal
severity: normal
status: open
title: test_subprocess hangs on AIX
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9862>
_______________________________________

From report at bugs.python.org  Wed Sep 15 21:00:15 2010
From: report at bugs.python.org (Corey Bertram)
Date: Wed, 15 Sep 2010 19:00:15 +0000
Subject: [New-bugs-announce] [issue9863] threading, signals,
	atexit: different execution with different versions
Message-ID: <1284577215.42.0.967366454397.issue9863@psf.upfronthosting.co.za>


Changes by Corey Bertram <corey at qr7.com>:


----------
nosy: cbertram
priority: normal
severity: normal
status: open
title: threading, signals, atexit: different execution with different versions
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9863>
_______________________________________

From report at bugs.python.org  Wed Sep 15 21:05:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Sep 2010 19:05:24 +0000
Subject: [New-bugs-announce] [issue9864] email.utils.{parsedate,
	parsedate_tz} should have better return types
In-Reply-To: <1284577524.51.0.954157890746.issue9864@psf.upfronthosting.co.za>
Message-ID: <1284577524.51.0.954157890746.issue9864@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

They both return raw tuples, which are not very intuitive to interpret:

>>> email.utils.parsedate_tz("Wed, 15 Sep 2010 09:53:50 -0700 (PDT)")
(2010, 9, 15, 9, 53, 50, 0, 1, -1, -25200)

It would be much better if they returned some kind of namedtuple, which would preserve backwards compatibility but with much better readability and usability.

Note that parsedate() could also return the existing time.struct_time type (which is compatible with a 9-tuple):
http://docs.python.org/library/time.html#time.struct_time

----------
components: Library (Lib)
messages: 116473
nosy: barry, pitrou, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: email.utils.{parsedate,parsedate_tz} should have better return types
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9864>
_______________________________________

From report at bugs.python.org  Wed Sep 15 23:12:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Sep 2010 21:12:39 +0000
Subject: [New-bugs-announce] [issue9865] OrderedDict doesn't implement
	__sizeof__
In-Reply-To: <1284585159.01.0.70557172329.issue9865@psf.upfronthosting.co.za>
Message-ID: <1284585159.01.0.70557172329.issue9865@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Ordered dicts pretend to have the memory consumption as dicts:

>>> import sys, collections
>>> sys.getsizeof({})
280
>>> sys.getsizeof(collections.OrderedDict())
280

----------
components: Library (Lib)
messages: 116481
nosy: pitrou, rhettinger
priority: low
severity: normal
status: open
title: OrderedDict doesn't implement __sizeof__
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9865>
_______________________________________

From report at bugs.python.org  Wed Sep 15 23:23:01 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 15 Sep 2010 21:23:01 +0000
Subject: [New-bugs-announce] [issue9866] Inconsistencies in tracing list
	comprehensions
In-Reply-To: <1284585781.8.0.0490639400631.issue9866@psf.upfronthosting.co.za>
Message-ID: <1284585781.8.0.0490639400631.issue9866@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Attached test script, tracetest.py, prints disassembly followed by a trace of the following function:


1  def f():
2      return [i
3              for i
4              in range(2)]


With default configuration, the output is


  2           0 LOAD_CONST               1 (<code object <listcomp> at 0x100484e00, file "tracetest.py", line 2>) 
              3 MAKE_FUNCTION            0 

  4           6 LOAD_GLOBAL              0 (range) 
              9 LOAD_CONST               2 (2) 
             12 CALL_FUNCTION            1 
             15 GET_ITER             
             16 CALL_FUNCTION            1 
             19 RETURN_VALUE         
listcomp:
  2           0 BUILD_LIST               0 
              3 LOAD_FAST                0 (.0) 
        >>    6 FOR_ITER                12 (to 21) 

  3           9 STORE_FAST               1 (i) 
             12 LOAD_FAST                1 (i) 
             15 LIST_APPEND              2 
             18 JUMP_ABSOLUTE            6 
        >>   21 RETURN_VALUE         
['2 0 LOAD_CONST', '4 6 LOAD_GLOBAL', '2 0 BUILD_LIST', '3 9 STORE_FAST', '2 6 FOR_ITER', '3 9 STORE_FAST', '2 6 FOR_ITER']

but with configuration using --without-computed-gotos option, the disassembly is the same, but the trace is different:


['2 0 LOAD_CONST', '4 6 LOAD_GLOBAL', '2 0 BUILD_LIST', '2 6 FOR_ITER', '2 6 FOR_ITER']

This behavior changed between 3.1 and 3.2 (likely in r74132), but it is inconsistent in both versions.  Since r74132 changes were not backported to 3.1, I am classifying this as 3.2 only even though the problem is present in 3.1 as well.

See also issues #6042 and #9315.

----------
components: Interpreter Core
files: tracetest.py
messages: 116482
nosy: alexandre.vassalotti, amaury.forgeotdarc, belopolsky, collinwinter, eli.bendersky, ezio.melotti, flox, georg.brandl, jyasskin, pitrou, rhettinger, teresap989, terry.reedy
priority: normal
severity: normal
status: open
title: Inconsistencies in tracing list comprehensions
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file18895/tracetest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9866>
_______________________________________

From report at bugs.python.org  Thu Sep 16 04:02:58 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Thu, 16 Sep 2010 02:02:58 +0000
Subject: [New-bugs-announce] [issue9867] Interrupted system calls are not
	retried on OS X
In-Reply-To: <1284602578.74.0.189576970404.issue9867@psf.upfronthosting.co.za>
Message-ID: <1284602578.74.0.189576970404.issue9867@psf.upfronthosting.co.za>


New submission from Armin Ronacher <armin.ronacher at active-4.com>:

Currently Python does not check fread and other IO calls for EINTR.  This usually is not an issue, but on OS X a continued program will be sent an SIGCONT signal which causes fread to be interrupted.

Testcase:

mitsuhiko at nausicaa:~$ python2.7
Python 2.7 (r27:82508, Jul  3 2010, 21:12:11) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from signal import SIGCONT, signal
>>> def show_signal(*args):
...  print 'Got SIGCONT'
...  
>>> signal(SIGCONT, show_signal)
0
>>> import sys
>>> sys.stdin.read()
^Z
[1]+  Stopped                 python2.7
mitsuhiko at nausicaa:~$ fg
python2.7
Got SIGCONT
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 4] Interrupted system call
>>> 

Expected behavior: on fg it should continue to read.  The solution would be to loop all calls to fread and friends until errno is no longer EINTR.  Now the question is how to best do that.  I can't think of a portable way to define a macro that continues to run an expression until errno is EINTR, maybe someone else has an idea.

Otherwise it would be possible to just put the loops by hand around each fread/fgetc etc. call, but that would make the code quite a bit more ugly.

Technically I suppose the problem applies to all platforms, on OS X it's just easier to trigger.

----------
messages: 116504
nosy: aronacher
priority: normal
severity: normal
status: open
title: Interrupted system calls are not retried on OS X
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9867>
_______________________________________

From report at bugs.python.org  Thu Sep 16 05:21:09 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 16 Sep 2010 03:21:09 +0000
Subject: [New-bugs-announce] [issue9868] test_locale leaves locale changed
In-Reply-To: <1284607269.81.0.729168421081.issue9868@psf.upfronthosting.co.za>
Message-ID: <1284607269.81.0.729168421081.issue9868@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

I noticed test_locale leaves locale changed.

# test_boo is simple test just to print windows error.

E:\python-dev\py3k\Lib\test>py3k -m test.regrtest test_locale test_boo
[1/2] test_locale
[2/2] test_boo
test test_boo failed -- Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\test\test_boo.py", line 11, in test
    os.rmdir(TMPDIR)
WindowsError: [Error 2] ?w?e?3?e???t?@?C???a?c?A?c?e?U?1?n?B: 'e:\\python-dev\\
py3k\\lib\\test\\__boo__'
Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\test\regrtest.py", line 941, in runtest_inner
    indirect_test()
  File "e:\python-dev\py3k\lib\test\test_boo.py", line 14, in test_main
    support.run_unittest(TestCase)
  File "e:\python-dev\py3k\lib\test\support.py", line 1128, in run_unittest
    _run_suite(suite)
  File "e:\python-dev\py3k\lib\test\support.py", line 1111, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\test\test_boo.py", line 11, in test
    os.rmdir(TMPDIR)
WindowsError: [Error 2] ?w?e?3?e???t?@?C???a?c?A?c?e?U?1?n?B: 'e:\\python-dev\\
py3k\\lib\\test\\__boo__'
test.support.TestFailed: Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\test\test_boo.py", line 11, in test
    os.rmdir(TMPDIR)
WindowsError: [Error 2] ?w?e?3?e???t?@?C???a?c?A?c?e?U?1?n?B: 'e:\\python-dev\\
py3k\\lib\\test\\__boo__'

During handling of the above exception, another exception occurred:

test test_boo failed -- Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\test\test_boo.py", line 11, in test
    os.rmdir(TMPDIR)
WindowsError: [Error 2] ?w?e?3?e???t?@?C???a?c?A?c?e?U?1?n?B: 'e:\\python-dev\\
py3k\\lib\\test\\__boo__'
test.support.TestFailed: Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\test\test_boo.py", line 11, in test
    os.rmdir(TMPDIR)
WindowsError: [Error 2] ?w?e?3?e???t?@?C???a?c?A?c?e?U?1?n?B: 'e:\\python-dev\\
py3k\\lib\\test\\__boo__'

During handling of the above exception, another exception occurred:

Exception IOError: 'raw write() returned invalid length 253 (should have been be
tween 0 and 252)' in <_io.TextIOWrapper name='<stdout>' encoding='cp932'> ignore
d
test.support.TestFailed: Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\test\test_boo.py", line 11, in test
    os.rmdir(TMPDIR)
WindowsError: [Error 2] ?w?e?3?e???t?@?C???a?c?A?c?e?U?1?n?B: 'e:\\python-dev\\
py3k\\lib\\test\\__boo__'

During handling of the above exception, another exception occurred:

Exception IOError: 'raw write() returned invalid length 253 (should have been be
tween 0 and 252)' in <_io.TextIOWrapper name='<stdout>' encoding='cp932'> ignore
d
[79459 refs]

/////////////////////////////////////////////////
// test_boo.py

from test import support
import unittest
import os

TMPDIR = os.path.join(os.path.dirname(os.path.abspath(__file__)), "__notexist__")

class TestCase(unittest.TestCase):
    def test(self):
        os.rmdir(TMPDIR)

def test_main():
    support.run_unittest(TestCase)

if __name__ == '__main__':
    test_main()

----------
components: Tests
messages: 116506
nosy: ocean-city
priority: normal
severity: normal
status: open
title: test_locale leaves locale changed
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9868>
_______________________________________

From report at bugs.python.org  Thu Sep 16 09:51:51 2010
From: report at bugs.python.org (Carl Witty)
Date: Thu, 16 Sep 2010 07:51:51 +0000
Subject: [New-bugs-announce] [issue9869] long_subtype_new segfault in
	pure-Python code
In-Reply-To: <1284623511.61.0.459492940306.issue9869@psf.upfronthosting.co.za>
Message-ID: <1284623511.61.0.459492940306.issue9869@psf.upfronthosting.co.za>


New submission from Carl Witty <Carl.Witty at gmail.com>:

PyNumber_Long() (and hence long_new()) are willing to return ints, rather than longs.  However, when long_subtype_new() calls long_new(), it casts the result to PyLongObject* without a check.  (Well, there is an assertion, so if assertions are enabled you'd get an assertion failure instead of a potential segmentation fault.)

The attached program segfaults for me; returning smaller numbers than 1000000 sometimes gives bad answers instead of crashing.

----------
components: Interpreter Core
files: python_long_bug.py
messages: 116514
nosy: cwitty
priority: normal
severity: normal
status: open
title: long_subtype_new segfault in pure-Python code
type: crash
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file18899/python_long_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9869>
_______________________________________

From report at bugs.python.org  Thu Sep 16 10:11:26 2010
From: report at bugs.python.org (Sergey)
Date: Thu, 16 Sep 2010 08:11:26 +0000
Subject: [New-bugs-announce] [issue9870] compile and nested scopes
In-Reply-To: <1284624686.57.0.761868003126.issue9870@psf.upfronthosting.co.za>
Message-ID: <1284624686.57.0.761868003126.issue9870@psf.upfronthosting.co.za>


New submission from Sergey <sergey_magaf at mail.ru>:

See attached tmp1.py
It is very simple but it doesn't work
It raises NameError
NameError: global name 'arg' is not defined

----------
components: None
files: tmp1.py
messages: 116515
nosy: webcubator
priority: normal
severity: normal
status: open
title: compile and nested scopes
type: behavior
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file18900/tmp1.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9870>
_______________________________________

From report at bugs.python.org  Thu Sep 16 10:55:25 2010
From: report at bugs.python.org (Popa Claudiu)
Date: Thu, 16 Sep 2010 08:55:25 +0000
Subject: [New-bugs-announce] [issue9871] IDLE dies when using some regex
In-Reply-To: <1284627325.17.0.642526416241.issue9871@psf.upfronthosting.co.za>
Message-ID: <1284627325.17.0.642526416241.issue9871@psf.upfronthosting.co.za>


New submission from Popa Claudiu <pcmanticore at gmail.com>:

Hello.

While trying to find a way for extracting strange characters in an ascii file, I stumbled upon some strange behaviour of IDLE, which exits without warning after running the following regex:

re.findall(b"\x.{2}", b"sdds\xd8")

In Python 2.6, this won't happen. This is my version of Python 3.1:
Python 3.1 (r31:73574, Jun 26 2009, 20:21:35).

----------
components: IDLE
messages: 116516
nosy: Popa.Claudiu
priority: normal
severity: normal
status: open
title: IDLE dies when using some regex
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9871>
_______________________________________

From report at bugs.python.org  Thu Sep 16 14:28:13 2010
From: report at bugs.python.org (Ram Rachum)
Date: Thu, 16 Sep 2010 12:28:13 +0000
Subject: [New-bugs-announce] [issue9872] `a.b.my_function is not
	b.my_function` when `a` and `b`	are both on `sys.path`
In-Reply-To: <1284640093.44.0.797706221833.issue9872@psf.upfronthosting.co.za>
Message-ID: <1284640093.44.0.797706221833.issue9872@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

Let's say you have this structure:

a\
  __init__.py
  b\
    __init__.py

In `b.__init__` a function called `my_function` is defined.

And assume that `a` and `b` are both on `sys.path`. Then this situation happens:

    >>> import a.b
    >>> import b
    >>> a.b.my_function is b.my_function
    False
    >>> a.b.my_function
    <function my_function at 0x00BC70C0>
    >>> b.my_function
    <function my_function at 0x00BC7108>
    >>> a.b.my_function.__module__
    'a.b'
    >>> b.my_function.__module__
    'b'

It seems that `a.b.my_function` and `b.my_function` are different objects.

----------
messages: 116536
nosy: cool-RR
priority: normal
severity: normal
status: open
title: `a.b.my_function is not b.my_function` when `a` and `b` are both on `sys.path`
type: behavior
versions: Python 2.6, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9872>
_______________________________________

From report at bugs.python.org  Thu Sep 16 15:25:12 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 16 Sep 2010 13:25:12 +0000
Subject: [New-bugs-announce] [issue9873] Allow bytes in some APIs that use
	string literals	internally
In-Reply-To: <1284643512.64.0.708677047597.issue9873@psf.upfronthosting.co.za>
Message-ID: <1284643512.64.0.708677047597.issue9873@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

As per python-dev discussion in June, many Py3k APIs currently gratuitously prevent the use of bytes and bytearray objects as arguments due to their use of string literals internally.

Examples:
urllib.parse.urlparse
urllib.parse.urlunparse
urllib.parse.urljoin
urllib.parse.urlsplit
(and plenty of other examples in urllib.parse)

While a strict reading of the relevant RFCs suggests that strings are the more appropriate type for these APIs, as a practical matter, protocol developers want to be able to operate on ASCII supersets as raw bytes.

The proposal is to modify the implementation of these functions such that string literals are used only with string arguments, and bytes literals otherwise. If a function accepts multiple values and a mixture of strings and bytes is passed in then the operation will still fail (as it should).

----------
assignee: ncoghlan
components: Library (Lib)
messages: 116543
nosy: ncoghlan
priority: high
severity: normal
stage: needs patch
status: open
title: Allow bytes in some APIs that use string literals internally
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Thu Sep 16 15:53:18 2010
From: report at bugs.python.org (Raphael Mankin)
Date: Thu, 16 Sep 2010 13:53:18 +0000
Subject: [New-bugs-announce] [issue9874] Message.attach() loses empty
	attachments
In-Reply-To: <1284645198.43.0.725761534678.issue9874@psf.upfronthosting.co.za>
Message-ID: <1284645198.43.0.725761534678.issue9874@psf.upfronthosting.co.za>


New submission from Raphael Mankin <raph at mankin.org.uk>:

When attaching a sequence of parts to a MIMEMultipart message, empty attachments are silently discarded.

----------
components: Library (Lib)
messages: 116550
nosy: raph at mankin.org.uk
priority: normal
severity: normal
status: open
title: Message.attach() loses empty attachments
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9874>
_______________________________________

From report at bugs.python.org  Thu Sep 16 16:19:51 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 16 Sep 2010 14:19:51 +0000
Subject: [New-bugs-announce] [issue9875] Garbage output when running
	setup.py on Windows
In-Reply-To: <1284646791.69.0.38074502633.issue9875@psf.upfronthosting.co.za>
Message-ID: <1284646791.69.0.38074502633.issue9875@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <invalid at example.invalid>:

The output of setup.py is polluted with this log message:

  Importing new compiler from distutils.msvc9compiler

on Windows.  For example, using pyOpenSSL's setup.py, running "setup.py --version" produces this output:

  Importing new compiler from distutils.msvc9compiler
  0.10

But the version number of pyOpenSSL is "0.10", not "Importing new compiler from distutils.msvc9compiler\n0.10".

The --quiet flag does not solve this problem, apparently because this log message is done at the top-level of msvccompiler.py, perhaps before --quiet is interpreted.

This interferes with my build automation which depends on "setup.py --version" producing the version number of the project in order to properly compute certain filenames.

----------
assignee: tarek
components: Distutils
messages: 116552
nosy: eric.araujo, exarkun, tarek
priority: normal
severity: normal
status: open
title: Garbage output when running setup.py on Windows
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9875>
_______________________________________

From report at bugs.python.org  Thu Sep 16 18:38:05 2010
From: report at bugs.python.org (Alexander Solovyov)
Date: Thu, 16 Sep 2010 16:38:05 +0000
Subject: [New-bugs-announce] [issue9876] ConfigParser can't interpolate
	values from other sections
In-Reply-To: <1284655085.98.0.131711113127.issue9876@psf.upfronthosting.co.za>
Message-ID: <1284655085.98.0.131711113127.issue9876@psf.upfronthosting.co.za>


New submission from Alexander Solovyov <piranha at piranha.org.ua>:

Often it is useful to access some variable in other section for interpolation needs: for example, parent directory declared in common section could be used in configuration of certain components. Included patch can fix that (using syntax 'section.variable'), is there any chances that it could be applied? :)


--- ConfigParser.old.py	2010-09-16 19:20:27.000000000 +0300
+++ ConfigParser.py	2010-09-16 19:22:33.000000000 +0300
@@ -585,7 +585,7 @@
             if "%(" in value:
                 value = self._KEYCRE.sub(self._interpolation_replace, value)
                 try:
-                    value = value % vars
+                    value = value % _Context(self, section)
                 except KeyError, e:
                     raise InterpolationMissingOptionError(
                         option, section, rawval, e.args[0])
@@ -667,3 +667,15 @@
             raise ValueError("invalid interpolation syntax in %r at "
                              "position %d" % (value, m.start()))
         ConfigParser.set(self, section, option, value)
+
+
+class _Context(object):
+    def __init__(self, config, section):
+        self.config = config
+        self.section = section
+
+    def __getitem__(self, key):
+        if '.' in key:
+            return self.config.get(*key.split('.'))
+        else:
+            return self.config.get(self.section, key)

----------
components: Library (Lib)
messages: 116573
nosy: asolovyov
priority: normal
severity: normal
status: open
title: ConfigParser can't interpolate values from other sections
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9876>
_______________________________________

From report at bugs.python.org  Thu Sep 16 19:51:05 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 16 Sep 2010 17:51:05 +0000
Subject: [New-bugs-announce] [issue9877] Expose
	sysconfig._get_makefile_filename() in public API
In-Reply-To: <1284659465.24.0.827166007618.issue9877@psf.upfronthosting.co.za>
Message-ID: <1284659465.24.0.827166007618.issue9877@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

sysconfig.get_config_h_filename() returns the path of pyconfig.h.  The Makefile is also used to return values from sysconfig but it's path is hidden in a non-public method, for no good reason that I can think of.  Therefore, sysconfig._get_makefile_filename() should be renamed to sysconfig.get_makefile_filename().

----------
assignee: barry
components: Library (Lib)
keywords: easy
messages: 116583
nosy: barry
priority: normal
severity: normal
status: open
title: Expose sysconfig._get_makefile_filename() in public API
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9877>
_______________________________________

From report at bugs.python.org  Thu Sep 16 20:08:46 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 16 Sep 2010 18:08:46 +0000
Subject: [New-bugs-announce] [issue9878] Avoid parsing pyconfig.h and
	Makefile by autogenerating	extension module
In-Reply-To: <1284660526.13.0.672517649262.issue9878@psf.upfronthosting.co.za>
Message-ID: <1284660526.13.0.672517649262.issue9878@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

This is splitting one concern from bug 9807 - specifically to avoid parsing pyconfig.h and Makefile in the sysconfig module by autogenerating an extension module (e.g. _sysconfig.c) at build time and using that to get the variables from those two files.

----------
assignee: barry
components: Library (Lib)
messages: 116588
nosy: barry
priority: normal
severity: normal
status: open
title: Avoid parsing pyconfig.h and Makefile by autogenerating extension module
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9878>
_______________________________________

From report at bugs.python.org  Thu Sep 16 23:56:11 2010
From: report at bugs.python.org (Tom Browder)
Date: Thu, 16 Sep 2010 21:56:11 +0000
Subject: [New-bugs-announce] [issue9879] Tracker Won't Accept New Bugs
In-Reply-To: <1284674171.88.0.225242150175.issue9879@psf.upfronthosting.co.za>
Message-ID: <1284674171.88.0.225242150175.issue9879@psf.upfronthosting.co.za>


New submission from Tom Browder <tom.browder at gmail.com>:

When I attempt to enter a new bug I get:

An error has occurred

A problem was encountered processing your request. The tracker
maintainers have been notified of the problem.

----------
components: Demos and Tools
messages: 116620
nosy: Tom.Browder
priority: normal
severity: normal
status: open
title: Tracker Won't Accept New Bugs
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9879>
_______________________________________

From report at bugs.python.org  Fri Sep 17 00:02:12 2010
From: report at bugs.python.org (Tom Browder)
Date: Thu, 16 Sep 2010 22:02:12 +0000
Subject: [New-bugs-announce] [issue9880] Python 2.7 Won't Build:
	SystemError: unknown opcode
In-Reply-To: <1284674532.4.0.904279806396.issue9880@psf.upfronthosting.co.za>
Message-ID: <1284674532.4.0.904279806396.issue9880@psf.upfronthosting.co.za>


New submission from Tom Browder <tom.browder at gmail.com>:

I am trying to rebuild the 2.7 maintenance branch and get this error
on Ubuntu 10.04.1 LTS:

XXX lineno: 743, opcode: 0
Traceback (most recent call last):
 File "/usr/local/src/python-2.7-maint-svn/Lib/site.py", line 62, in <module>
  import os
 File "/usr/local/src/python-2.7-maint-svn/Lib/os.py", line 743, in <module>
  def urandom(n):
SystemError: unknown opcode

I installed it successfully once so I may be getting conflicts, but I can't figure out why.  There were some similar bugs reported in previous versions but I didn't see a clear solution.

I have done "make distclean" and "./configure".  I have unset my
PYTHONPATH and LD_LIBRARY_PATH, but python2.7 is my default python from a previous good build and installation.

----------
components: Build
messages: 116623
nosy: Tom.Browder
priority: normal
severity: normal
status: open
title: Python 2.7 Won't Build: SystemError: unknown opcode
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9880>
_______________________________________

From report at bugs.python.org  Fri Sep 17 00:22:59 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 16 Sep 2010 22:22:59 +0000
Subject: [New-bugs-announce] [issue9881] PySSL_SSLRead loops until data is
	available, even in non-blocking mode
In-Reply-To: <1284675779.48.0.545213768425.issue9881@psf.upfronthosting.co.za>
Message-ID: <1284675779.48.0.545213768425.issue9881@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <invalid at example.invalid>:

Here's a transcript which demonstrates the blocking behavior:

>>> import socket
>>> import time
>>> import ssl
>>> s = ssl.wrap_socket(socket.socket())
>>> s.connect(('localhost', 8443))
>>> s.send('GET /async.rpy HTTP/1.1\r\n\r\n')
27
>>> s.setblocking(False)
>>> a = time.time(); s.recv(1024); b = time.time()
'HTTP/1.1 200 OK\r\nTransfer-Encoding: chunked\r\nDate: Thu, 02 Sep 2010 11:51:03 GMT\r\nContent-Type: text/html\r\nServer: TwistedWeb/10.1.0+r29954\r\n\r\n4c\r\n<html><body>Sorry to keep you waiting.</body></html>\r\n0\r\n\r\n'
>>> print b - a
4.13403391838
>>>

(This can be reproduced using any web server which is a bit slow in responding; it's very obvious here because I used a server that intentionally waits several seconds before generating a response).

----------
components: Library (Lib)
messages: 116629
nosy: exarkun
priority: normal
severity: normal
status: open
title: PySSL_SSLRead loops until data is available, even in non-blocking mode
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9881>
_______________________________________

From report at bugs.python.org  Fri Sep 17 02:21:57 2010
From: report at bugs.python.org (ipatrol)
Date: Fri, 17 Sep 2010 00:21:57 +0000
Subject: [New-bugs-announce] [issue9882] abspath from directory
In-Reply-To: <1284682917.39.0.650396347526.issue9882@psf.upfronthosting.co.za>
Message-ID: <1284682917.39.0.650396347526.issue9882@psf.upfronthosting.co.za>


New submission from ipatrol <ipatrol6010 at yahoo.com>:

Just an easy patch.

os.path.abspath is defined as os.path.normpath(os.path.join(os.getcwd(),path), but os.path.relpath also adds a start option. This creates an asymmetry where getting the absolute path from a relative path and a directory has no single operation whereas the inverse does. So finding the absolute path of 'foo' in the directory '/bar/buzz/bang/quok' requires several nested functions or else a quick dash in with os.chdir. Hence redefining os.path.abspath as os.path.normpath(os.path.join(start or os.getcwd(),path).

----------
components: Library (Lib)
messages: 116643
nosy: ipatrol
priority: normal
severity: normal
status: open
title: abspath from directory
type: feature request
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9882>
_______________________________________

From report at bugs.python.org  Fri Sep 17 05:30:45 2010
From: report at bugs.python.org (Aubrey Barnard)
Date: Fri, 17 Sep 2010 03:30:45 +0000
Subject: [New-bugs-announce] [issue9883] minidom: AttributeError:
	DocumentFragment instance has no	attribute 'writexml'
In-Reply-To: <1284694245.92.0.410723728376.issue9883@psf.upfronthosting.co.za>
Message-ID: <1284694245.92.0.410723728376.issue9883@psf.upfronthosting.co.za>


New submission from Aubrey Barnard <aubrey.f.barnard at gmail.com>:

Summary:
Writing a document fragment doesn't work because the 'writexml' method is not implemented.

Problem:
I would like to be able to write out document fragments as XML text, but this functionality is not implemented. Here are the reasons why I think this functionality should be implemented.

1. DOM Level 1 describes a document fragment as a lightweight document. I can write a document as XML text so why not a document fragment?

2. This would be very easy to implement, basically just the child processing loop from Element.writexml:
for node in self.childNodes:
    node.writexml(writer,indent+addindent,addindent,newl)

3. Document fragments are often returned as intermediate results in XML building. The best way I can think of to unit test these results is by writing the document fragment as XML text and comparing to an existing string. (Comparing two document fragments is not guaranteed to work.)

4. Implementing an XML editor on top of minidom would require this functionality, e.g. display a piece of cut XML.

I realize that writing document fragments as XML text is not a common or "core" operation, but it makes sense in the above four cases and perhaps other cases as well. Therefore, to me, implementing this functionality is less a question of "Why?" and more a question of "Why not?"

I will be glad to add any other information as requested.

----------
components: XML
messages: 116644
nosy: Aubrey.Barnard
priority: normal
severity: normal
status: open
title: minidom: AttributeError: DocumentFragment instance has no attribute 'writexml'
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9883>
_______________________________________

From report at bugs.python.org  Fri Sep 17 11:12:22 2010
From: report at bugs.python.org (Owen)
Date: Fri, 17 Sep 2010 09:12:22 +0000
Subject: [New-bugs-announce] [issue9884] The 4th parameter of method always
	None or 0 on x64	Windows.
In-Reply-To: <1284714742.48.0.856656538994.issue9884@psf.upfronthosting.co.za>
Message-ID: <1284714742.48.0.856656538994.issue9884@psf.upfronthosting.co.za>


New submission from Owen <j2.nete at gmail.com>:

OS: Windows 2003STD x64 en

I have try to call python method from c++ dll by "WINFUNCTYPE".
But the 4th parameter is always None or 0 if the type is int or void* (float is works fine).

Following is the part of source code:
==code==========================================
import sys
from ctypes import *

windll.LoadLibrary("testPy2.dll")
#########################################

def test3(param1,param2,param3,param4,param5,param6,param7,param8,param9,param10):
  print("================")
  print(param1)
  print(param2)
  print(param3)
  # the 4th param4 is always 0.
  print(param4)
  print(param5)
  print(param6)
  print(param7)
  print(param8)
  print(param9)
  print(param10)
  print("================")
  return 20
  
C_METHOD_TYPE4 = WINFUNCTYPE(c_int32, c_int32, c_int32, c_int32, c_int32, c_int32, c_int32, c_int32, c_int32, c_int32, c_int32)

windll.testPy2.fntestPy7(9,C_METHOD_TYPE4(test3))
==code==========================================

To my knowledge, both visual c++ and gcc use registers for the first few parameters, and then after that use the stack.  Maybe this is the reason.

I have attached some simple codes for reproduce this issue.
issues
  - testPy2      <- source code of the dll
  - test.py      <- python file to reproduce the issue
  - testPy2.dll  <- the dll to reproduce the issue

----------
components: Windows
files: issues.zip
messages: 116649
nosy: J2.NETe
priority: normal
severity: normal
status: open
title: The 4th parameter of method always None or 0 on x64 Windows.
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file18907/issues.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9884>
_______________________________________

From report at bugs.python.org  Fri Sep 17 13:36:19 2010
From: report at bugs.python.org (paontis)
Date: Fri, 17 Sep 2010 11:36:19 +0000
Subject: [New-bugs-announce] [issue9885] Function Round does not work
	properly in some conditions
In-Reply-To: <1284723379.23.0.462202029266.issue9885@psf.upfronthosting.co.za>
Message-ID: <1284723379.23.0.462202029266.issue9885@psf.upfronthosting.co.za>


New submission from paontis <paoregs at gmail.com>:

For example round(10.3333, 1) returns 10.300000000000001 and round(1.3333, 2)returns 1.3300000000000001

I exect they return 10.3 and 1.33 rispectively

NOTE: other combinations work fine eg. round(10.3333, 2) or round(1.3333, 3)

See IDLE commands in the attached file round.txt

Used Python 2.6.6 for Windows

----------
files: round.txt
messages: 116656
nosy: paontis
priority: normal
severity: normal
status: open
title: Function Round does not work properly in some conditions
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file18908/round.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9885>
_______________________________________

From report at bugs.python.org  Fri Sep 17 14:13:26 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 17 Sep 2010 12:13:26 +0000
Subject: [New-bugs-announce] [issue9886] Make
	operator.itemgetter/attrgetter/methodcaller easier	to discover
In-Reply-To: <1284725606.32.0.188356028787.issue9886@psf.upfronthosting.co.za>
Message-ID: <1284725606.32.0.188356028787.issue9886@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The observation has been made that there are some idioms related to key functions passed to various methods and functions that aren't particularly easy to discover.

One suggestion is to create a "key function" glossary entry that provides examples of standard library operations that exist primarily for use as key functions (i.e. the three functions mentioned in the issue title), as well as mentioning some of the APIs that accept key functions (e.g. sorted, list.sort, min, max). The documentation of these various could then cross link to the "key function" glossary entry to make this idioms more discoverable without needing to repeat ourselves in the documentation of every method that accepts a key function.

As per discussion on python-ideas, including the glossary entry suggestion from Terry Reedy:
http://mail.python.org/pipermail/python-ideas/2010-September/008093.html

----------
assignee: docs at python
components: Documentation
messages: 116658
nosy: docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: Make operator.itemgetter/attrgetter/methodcaller easier to discover
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9886>
_______________________________________

From report at bugs.python.org  Fri Sep 17 15:19:53 2010
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Fri, 17 Sep 2010 13:19:53 +0000
Subject: [New-bugs-announce] [issue9887] distutil's build_scripts doesn't
	read utf-8 in all locales
In-Reply-To: <1284729593.16.0.252664137674.issue9887@psf.upfronthosting.co.za>
Message-ID: <1284729593.16.0.252664137674.issue9887@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

"LANG=C python3 setup.py build_scripts" chokes on UTF-8 encoded scripts. The problem is that "copy_scripts" uses "open" without specifying an encoding. This issue may be related to #9561.

----------
assignee: tarek
components: Distutils
messages: 116660
nosy: eric.araujo, hagen, tarek
priority: normal
severity: normal
status: open
title: distutil's build_scripts doesn't read utf-8 in all locales
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9887>
_______________________________________

From report at bugs.python.org  Fri Sep 17 20:18:02 2010
From: report at bugs.python.org (Brian Bernstein)
Date: Fri, 17 Sep 2010 18:18:02 +0000
Subject: [New-bugs-announce] [issue9888] int overflow in datetime causes seg
	fault from	datetime.ctime()
In-Reply-To: <1284747482.26.0.727712350645.issue9888@psf.upfronthosting.co.za>
Message-ID: <1284747482.26.0.727712350645.issue9888@psf.upfronthosting.co.za>


New submission from Brian Bernstein <bernie9998 at gmail.com>:

When creating an int overflow via a subtraction operation with a datetime object and a timedelta object, the resulting datetime object can cause a segmentation fault when the ctime method is called.

Segmentation Fault occurred on python 2.6.5 on 64 bit ubuntu lucid.

Code as follows:

from datetime import datetime, timedelta
(datetime.now() - timedelta(734395)).ctime()

----------
components: None
files: segfault.py
messages: 116700
nosy: bernie9998
priority: normal
severity: normal
status: open
title: int overflow in datetime causes seg fault from datetime.ctime()
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file18909/segfault.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9888>
_______________________________________

From report at bugs.python.org  Fri Sep 17 21:32:11 2010
From: report at bugs.python.org (Michael Kleehammer)
Date: Fri, 17 Sep 2010 19:32:11 +0000
Subject: [New-bugs-announce] [issue9889] PyUnicode_FormatV and Py_UNICODE*?
In-Reply-To: <1284751931.03.0.894481141092.issue9889@psf.upfronthosting.co.za>
Message-ID: <1284751931.03.0.894481141092.issue9889@psf.upfronthosting.co.za>


New submission from Michael Kleehammer <michael at kleehammer.com>:

Using Py_UNICODE* in Python 3 C extensions is significantly more cumbersome than using char* was in Python 2.x.  One addition that could help would be a Py_UNICODE* format type for PyUnicode_FormatV.

Many printf libraries us %S for wchar_t which would have been nicely analogous, but that is already taken for str(obj).

----------
components: Extension Modules, Interpreter Core
messages: 116714
nosy: mkleehammer
priority: normal
severity: normal
status: open
title: PyUnicode_FormatV and Py_UNICODE*?
type: feature request
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9889>
_______________________________________

From report at bugs.python.org  Sat Sep 18 03:54:37 2010
From: report at bugs.python.org (Dylon)
Date: Sat, 18 Sep 2010 01:54:37 +0000
Subject: [New-bugs-announce] [issue9890] Visual C++ Runtime Library Error is
	there a fix?
In-Reply-To: <1284774877.07.0.1280459876.issue9890@psf.upfronthosting.co.za>
Message-ID: <1284774877.07.0.1280459876.issue9890@psf.upfronthosting.co.za>


New submission from Dylon <hydro56 at gmail.com>:

I attempt to run the program (IDLE) after a fresh install of Python x86 on windows 7 32-bit and it gives me this error:
"Runtime Error!

Program: C:\Program Files\Python\pythonw.exe


This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information."

----------
components: IDLE, Windows
messages: 116746
nosy: Hydro56
priority: normal
severity: normal
status: open
title: Visual C++ Runtime Library Error is there a fix?
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9890>
_______________________________________

From report at bugs.python.org  Sat Sep 18 11:11:21 2010
From: report at bugs.python.org (Rodrigo Bernardo Pimentel)
Date: Sat, 18 Sep 2010 09:11:21 +0000
Subject: [New-bugs-announce] [issue9891] Minor doc typo at datamodel.rst:
	"list" -> "alist"
In-Reply-To: <1284801081.96.0.0540649030597.issue9891@psf.upfronthosting.co.za>
Message-ID: <1284801081.96.0.0540649030597.issue9891@psf.upfronthosting.co.za>


New submission from Rodrigo Bernardo Pimentel <rbp at isnomore.net>:

The "Built-in methods" item of the "The standard type hierarchy" section of Doc/reference/datamodels.rst uses a list instance called "alist" as an example, and it says "__self__ is set to the object denoted by *list*." It should read "the object denoted by *alist*"

This affects all releases, so I've marked them all. But I suppose we don't care about 2.5 anymore. All the others are listed on docs.python.org (or are "trunk"), and I think should be fixed.

It's a trivial fix, and a single patch works 2.x and another for 3.x.

----------
assignee: docs at python
components: Documentation
files: alist_doc-2.x.patch
keywords: patch
messages: 116757
nosy: docs at python, rbp
priority: normal
severity: normal
status: open
title: Minor doc typo at datamodel.rst: "list" -> "alist"
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file18914/alist_doc-2.x.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9891>
_______________________________________

From report at bugs.python.org  Sat Sep 18 14:58:11 2010
From: report at bugs.python.org (Dmitry Dvoinikov)
Date: Sat, 18 Sep 2010 12:58:11 +0000
Subject: [New-bugs-announce] [issue9892] Event spends less time in wait()
	than requested
In-Reply-To: <1284814691.18.0.9754077779.issue9892@psf.upfronthosting.co.za>
Message-ID: <1284814691.18.0.9754077779.issue9892@psf.upfronthosting.co.za>


New submission from Dmitry Dvoinikov <dmitry at targeted.org>:

If you request Event.wait(x), the call consistently returns in less than x seconds.

Sample:
---------------------------------------------------------
from threading import Event
from time import time

e = Event()

before = time()
e.wait(0.1)
after = time()

print(after - before)

# under Python 3.1 prints 0.109999...
# under Python 3.2 prints 0.092999...
---------------------------------------------------------

----------
components: Library (Lib)
messages: 116772
nosy: ddvoinikov
priority: normal
severity: normal
status: open
title: Event spends less time in wait() than requested
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9892>
_______________________________________

From report at bugs.python.org  Sat Sep 18 18:34:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Sep 2010 16:34:46 +0000
Subject: [New-bugs-announce] [issue9893] Usefulness of the Misc/Vim/ files?
In-Reply-To: <1284827686.39.0.471855984875.issue9893@psf.upfronthosting.co.za>
Message-ID: <1284827686.39.0.471855984875.issue9893@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

While trying out vim, I noticed that the files in Misc/Vim are very poor compared to what is otherwise provided by the vim community:
- highlighting including 3.x syntax: http://www.vim.org/scripts/script.php?script_id=974
- PEP 8 indentation: http://www.vim.org/scripts/script.php?script_id=974

Also, the vimrc uses "au BufRead,BufNewFile *.py" style selection, while the recommended modern style seems to use a ".vim/ftplugin" filetype-specific file instead.

Does it still make sense to maintain these files separately?

----------
components: Demos and Tools
messages: 116812
nosy: brett.cannon, pitrou
priority: low
severity: normal
status: open
title: Usefulness of the Misc/Vim/ files?
type: resource usage
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9893>
_______________________________________

From report at bugs.python.org  Sat Sep 18 18:44:32 2010
From: report at bugs.python.org (Pino Toscano)
Date: Sat, 18 Sep 2010 16:44:32 +0000
Subject: [New-bugs-announce] [issue9894] wrong errno check
In-Reply-To: <1284828272.46.0.993131390334.issue9894@psf.upfronthosting.co.za>
Message-ID: <1284828272.46.0.993131390334.issue9894@psf.upfronthosting.co.za>


New submission from Pino Toscano <toscano.pino at tiscali.it>:

In Lib/test/test_subprocess.py there's a check of an errno value done against a number, instead of using the proper E* constants, which is not portable (POSIX does not specify any actual value of the E* constants).
This makes the test test_leaking_fds_on_error fail on OSes where the errno ENOENT has a value different than two (like on GNU/Hurd, for example).

The attached patch was done in the py3k branch, but the issue appears in any other branch (including trunk). Could you please fix the issue also in the active Python branches?

----------
components: Tests
files: errno_py3k.diff
keywords: patch
messages: 116813
nosy: pino
priority: normal
severity: normal
status: open
title: wrong errno check
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file18920/errno_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9894>
_______________________________________

From report at bugs.python.org  Sat Sep 18 20:24:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 Sep 2010 18:24:56 +0000
Subject: [New-bugs-announce] [issue9895] Speed up test_subprocess
In-Reply-To: <1284834296.27.0.356977051477.issue9895@psf.upfronthosting.co.za>
Message-ID: <1284834296.27.0.356977051477.issue9895@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

test_subprocess is currently very slow and the main culprit is test_no_leaking (here, it takes 80s out of the 100s needed for the whole run). This tests spawns as many subprocesses as would be needed to reach the max file descriptor limit. Spawning a subprocess is a heavy operation and consequently the test is very long.

This patch adopts another approach: it opens many file descriptors (using os.open()) until the max fd limit is reached, closes some of them (10 is enough) and then launches a bunch of subprocesses in a loop to check that they succeed. Consequently, the test is very fast (even on a Windows VM in debug mode).

----------
components: Tests
files: noleaking.patch
keywords: patch
messages: 116821
nosy: brian.curtin, gregory.p.smith, pitrou, tim.golden
priority: normal
severity: normal
stage: patch review
status: open
title: Speed up test_subprocess
type: performance
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file18921/noleaking.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9895>
_______________________________________

From report at bugs.python.org  Sat Sep 18 20:39:27 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 18 Sep 2010 18:39:27 +0000
Subject: [New-bugs-announce] [issue9896] Introspectable range objects
In-Reply-To: <1284835167.56.0.979385376089.issue9896@psf.upfronthosting.co.za>
Message-ID: <1284835167.56.0.979385376089.issue9896@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

The attached patch adds the start, stop and step members to range objects, corresponding the contructor arguments. The patch also include tests and documentation changes.

----------
components: Interpreter Core
files: range_attrs.diff
keywords: patch
messages: 116824
nosy: durban
priority: normal
severity: normal
status: open
title: Introspectable range objects
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file18922/range_attrs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9896>
_______________________________________

From report at bugs.python.org  Sun Sep 19 12:06:31 2010
From: report at bugs.python.org (hume)
Date: Sun, 19 Sep 2010 10:06:31 +0000
Subject: [New-bugs-announce] [issue9897] multiprocessing problems
In-Reply-To: <1284890791.64.0.603170640253.issue9897@psf.upfronthosting.co.za>
Message-ID: <1284890791.64.0.603170640253.issue9897@psf.upfronthosting.co.za>


New submission from hume <humeafo at gmail.com>:

when use multiprocessing managers, while use socket to communicate between server process and client process, if I used the global socket timeout feature(no matter how large the value is) the client will always say

  File "c:\python27\lib\multiprocessing\connection.py", line 149, in Client
    answer_challenge(c, authkey)
  File "c:\python27\lib\multiprocessing\connection.py", line 383, in answer_challenge
    message = connection.recv_bytes(256)         # reject large message
IOError: [Errno 10035] 

this is not reasonable, because this behaviour will make subprocess unable to use socket's timeout features globally.

Another question is line 138 in managers.py:
        # do authentication later
        self.listener = Listener(address=address, backlog=5)
        self.address = self.listener.address

backlog=5 will accept only 5 cocurrent connections, this is not so user friendly, you'd better make this a argument that can be specified by user

----------
components: Library (Lib)
messages: 116854
nosy: hume
priority: normal
severity: normal
status: open
title: multiprocessing problems
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9897>
_______________________________________

From report at bugs.python.org  Sun Sep 19 20:55:41 2010
From: report at bugs.python.org (Ram Rachum)
Date: Sun, 19 Sep 2010 18:55:41 +0000
Subject: [New-bugs-announce] [issue9898] cProfile.runctx doesn't allow sort
	argument
In-Reply-To: <1284922541.3.0.303854957861.issue9898@psf.upfronthosting.co.za>
Message-ID: <1284922541.3.0.303854957861.issue9898@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

The `cProfile.runctx` function currently doesn't allow using the `sort` argument. For some reason the `sort` argument is allowed in `run` but not in `runctx`. Attached is a patch that allows using `sort` in `runctx`.

----------
components: Library (Lib)
files: cProfile.patch
keywords: patch
messages: 116880
nosy: cool-RR
priority: normal
severity: normal
status: open
title: cProfile.runctx doesn't allow sort argument
type: feature request
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file18932/cProfile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9898>
_______________________________________

From report at bugs.python.org  Sun Sep 19 22:42:59 2010
From: report at bugs.python.org (Ismail Donmez)
Date: Sun, 19 Sep 2010 20:42:59 +0000
Subject: [New-bugs-announce] [issue9899] [REGRESSION] test_tk broken on
	MacOSX 10.6
In-Reply-To: <1284928979.9.0.717353739827.issue9899@psf.upfronthosting.co.za>
Message-ID: <1284928979.9.0.717353739827.issue9899@psf.upfronthosting.co.za>


New submission from Ismail Donmez <ismail at namtrac.org>:

py3k branch, revision 84907

======================================================================
ERROR: test_font_eq (tkinter.test.test_tkinter.test_font.FontTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/cartman/Sources/py3k/Lib/tkinter/test/test_tkinter/test_font.py", line 10, in test_font_eq
    font1 = font.nametofont("system")
  File "/Users/cartman/Sources/py3k/Lib/tkinter/font.py", line 22, in nametofont
    return Font(name=name, exists=True)
  File "/Users/cartman/Sources/py3k/Lib/tkinter/font.py", line 83, in __init__
    "named font %s does not already exist" % (self.name,))
_tkinter.TclError: named font system does not already exist

----------
components: Tests
messages: 116883
nosy: cartman
priority: normal
severity: normal
status: open
title: [REGRESSION] test_tk broken on MacOSX 10.6
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9899>
_______________________________________

From report at bugs.python.org  Mon Sep 20 01:04:15 2010
From: report at bugs.python.org (Rob Watson)
Date: Sun, 19 Sep 2010 23:04:15 +0000
Subject: [New-bugs-announce] [issue9900] Threading Bug or misuse of the api ?
In-Reply-To: <1284937455.45.0.396725320878.issue9900@psf.upfronthosting.co.za>
Message-ID: <1284937455.45.0.396725320878.issue9900@psf.upfronthosting.co.za>


New submission from Rob Watson <rmawatson at gmail.com>:

Is the below a bug or a misuse of the api ? This was compiled with visual studio 2008 and python26 64bit

void testfunction()
{
	for (int x = 1;x <= 100000;x++)
	{
		
		PyGILState_STATE gstate = PyGILState_Ensure();
		PyRun_SimpleString("2 + 1");
		PyGILState_Release(gstate);
	}	
}


int main()
{
	
	Py_Initialize();
	PyEval_InitThreads();
	PyEval_ReleaseLock();	
	
	boost::thread(boost::bind(testfunction));
	
        // if this Sleep(100) is commented out, I will get "Python Fatal Error : This thread state must be current when releasing"
	Sleep(100);
	testfunction();
	Sleep(1000000);
}

----------
components: None
messages: 116891
nosy: Rob.Watson
priority: normal
severity: normal
status: open
title: Threading Bug or misuse of the api ?
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9900>
_______________________________________

From report at bugs.python.org  Mon Sep 20 01:57:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Sep 2010 23:57:42 +0000
Subject: [New-bugs-announce] [issue9901] GIL destruction can fail
In-Reply-To: <1284940662.22.0.656569610088.issue9901@psf.upfronthosting.co.za>
Message-ID: <1284940662.22.0.656569610088.issue9901@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

test_finalize_with_trace (in test_threading) sometimes fails because of failing to destroy the GIL (in _PyEval_FiniThreads()). This can be reproduced quite reliably by launching several copies in parallel:

$ ./python -m test.regrtest -j10 -F test_threading
[...]
test test_threading failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_threading.py", line 334, in test_finalize_with_trace
    "Unexpected error: " + ascii(stderr))
AssertionError: Unexpected error: b'Fatal Python error: pthread_mutex_destroy(gil_mutex) failed\n'


What happens is that pthread_mutex_destroy() fails with EBUSY. According to the POSIX man page:

?[EBUSY]
    The implementation has detected an attempt to destroy the object referenced by mutex while it is locked or referenced (for example, while being used in a pthread_cond_timedwait() or pthread_cond_wait()) by another thread.?


After a bit of tracing, it becomes clear that Py_Finalize() calls _PyEval_FiniThreads() while another thread is taking the GIL (take_gil()). Unfortunately, this is not a situation we can avoid, since we rely on process exit to kill lingering threads: arbitrary CPython code may still be running in parallel while we are finalizing interpreter structures.

Therefore, it is likely that _PyEval_FiniThreads() should avoid destroying the mutex at all. Indeed, if we destroy the mutex, it is possible that a lingering thread tries to retake the GIL after waking up from a system call (Py_END_ALLOW_THREADS), and fails because of another fatal error ("Fatal Python error: pthread_mutex_lock(gil_mutex) failed").

----------
components: Interpreter Core
messages: 116893
nosy: amaury.forgeotdarc, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: GIL destruction can fail
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9901>
_______________________________________

From report at bugs.python.org  Mon Sep 20 02:02:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Sep 2010 00:02:18 +0000
Subject: [New-bugs-announce] [issue9902] test_undecodable_env failure
In-Reply-To: <1284940938.56.0.417110685036.issue9902@psf.upfronthosting.co.za>
Message-ID: <1284940938.56.0.417110685036.issue9902@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Under the "x86 debian parallel 3.x" buildbot, there's the following failure:

======================================================================
FAIL: test_undecodable_env (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/test/test_subprocess.py", line 898, in test_undecodable_env
    self.assertEquals(stdout.decode('ascii'), ascii(value))
AssertionError: "'abc\\xff'" != "'abc\\udcff'"
- 'abc\xff'
?      ^
+ 'abc\udcff'
?      ^^^


======================================================================
FAIL: test_undecodable_env (test.test_subprocess.ProcessTestCasePOSIXPurePython)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/test/test_subprocess.py", line 898, in test_undecodable_env
    self.assertEquals(stdout.decode('ascii'), ascii(value))
AssertionError: "'abc\\xff'" != "'abc\\udcff'"
- 'abc\xff'
?      ^
+ 'abc\udcff'
?      ^^^

----------
assignee: haypo
components: Tests
messages: 116895
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: test_undecodable_env failure
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9902>
_______________________________________

From report at bugs.python.org  Mon Sep 20 02:48:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Sep 2010 00:48:43 +0000
Subject: [New-bugs-announce] [issue9903] test_concurrent_futures writes on
	stderr
In-Reply-To: <1284943723.6.0.157191690698.issue9903@psf.upfronthosting.co.za>
Message-ID: <1284943723.6.0.157191690698.issue9903@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

test_concurrent_futures writes the following on stderr:

exception calling callback for <Future at 0x6a72508 state=finished returned int>
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/concurrent/futures/_base.py", line 267, in _invoke_callbacks
    callback(self)
  File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/test/test_concurrent_futures.py", line 626, in raising_fn
    raise Exception('doh!')
Exception: doh!


test_concurrent_futures should capture stderr instead, and also probably check its value (to be sure that the exception does get logged out properly).

----------
assignee: bquinlan
components: Tests
messages: 116902
nosy: bquinlan, pitrou
priority: normal
severity: normal
status: open
title: test_concurrent_futures writes on stderr
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9903>
_______________________________________

From report at bugs.python.org  Mon Sep 20 08:29:06 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 20 Sep 2010 06:29:06 +0000
Subject: [New-bugs-announce] [issue9904] Cosmetic issues that might be
	worthy a fix in symtable.h/c
In-Reply-To: <1284964146.62.0.95975690396.issue9904@psf.upfronthosting.co.za>
Message-ID: <1284964146.62.0.95975690396.issue9904@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

The following minor issues may affect the readability of the code implementing symbol tables in Include/symtable.h and Python/symtable.c

    * The comment for st_global in symtable.h says: "borrowed ref to st_top->st_symbols. typo? (st_top->ste_symbols)
    * ste_varnames: the name and the comment after it are misleading, since it actually collects only the function's parameters and not all variables.
    * the st_nblocks and st_future fields of symtable aren't used anywhere - py3k compiles fine when they're removed.
    * in analyze_block a comment says "Recursively call analyze_block()" - untrue, probably meant analyze_child_block. While technically analyze_child_block calls analyze_block, the comment as-is appears misleading.
    * symtable_add_def is also called with the USE flag, not only definitions, hence its name doesn't reflect its purpose accurately
    * There are some indentation artifacts that obscure readability. For example the case Raise_kind of symtable_visit_stmt, where two nested blocks start and end in the same column obscuring the fact they're nested. This could be a result of an automatic tab to space conversion in the past.

----------
components: Interpreter Core
messages: 116911
nosy: eli.bendersky, ncoghlan
priority: normal
severity: normal
status: open
title: Cosmetic issues  that might be worthy a fix in symtable.h/c
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9904>
_______________________________________

From report at bugs.python.org  Mon Sep 20 19:59:36 2010
From: report at bugs.python.org (Thomas Claveirole)
Date: Mon, 20 Sep 2010 17:59:36 +0000
Subject: [New-bugs-announce] [issue9905] subprocess.Popen fails with
	stdout=PIPE, stderr=PIPE if standard descriptors (0, 1,
	2) are closed.
In-Reply-To: <1285005576.46.0.387895977213.issue9905@psf.upfronthosting.co.za>
Message-ID: <1285005576.46.0.387895977213.issue9905@psf.upfronthosting.co.za>


New submission from Thomas Claveirole <thomas.claveirole at gmail.com>:

Hello,

Here is a code that exhibits an invalid behavior (Python 2.6.6):
---8<---
import subprocess, os

os.close(0) # Works correctly if any of these two are commented out.
os.close(2)

print subprocess.Popen('echo foo>&2', shell=True,
                       stdout=subprocess.PIPE,
                       stderr=subprocess.PIPE).communicate()
--->8---

When run, the output is:
('', '')

While it should be:
('', 'foo\n')

When analyzing the code with strace the problem gets clearer:
$ strace -f -e pipe,fork,dup2,close ./Popen-bug.py
[...]
5085  pipe([0, 2])                      = 0  # Creates the pipes.
5085  pipe([3, 4])                      = 0
5085  pipe([5, 6])                      = 0
[...] # In this skipped part Popen() closes useless pipe endpoints.
5086  dup2(2, 1)                        = 1 # stdout setup.
5086  dup2(4, 2)                        = 2 # stderr setup.
5086  close(2)                          = 0
[...]

The last "close(2)" is the error: apparently Popen() tries to close the remaining pipe endpoints (as should theoretically be done) but fails to see that the endpoint created by pipe([0, 2]) has already been closed during the previous dup2(4, 2) and that the file descriptor 2 is now the standard error.  Therefore, Popen incorrectly closes the standard error.

To fix that, Popen should check, before closing the remaining pipe endpoints, that these endpoints are not the one that just get closed by the two previous dup2s.

Best regards,

----------
components: Library (Lib)
messages: 116957
nosy: Thomas.Claveirole
priority: normal
severity: normal
status: open
title: subprocess.Popen fails with stdout=PIPE, stderr=PIPE if standard descriptors (0, 1, 2) are closed.
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9905>
_______________________________________

From report at bugs.python.org  Mon Sep 20 22:05:01 2010
From: report at bugs.python.org (Michael Gilbert)
Date: Mon, 20 Sep 2010 20:05:01 +0000
Subject: [New-bugs-announce] [issue9906] including elementary mathematical
	functions in default	types
In-Reply-To: <1285013101.44.0.231152316832.issue9906@psf.upfronthosting.co.za>
Message-ID: <1285013101.44.0.231152316832.issue9906@psf.upfronthosting.co.za>


New submission from Michael Gilbert <michael.s.gilbert at gmail.com>:

hi,

it would be really nice if elementary mathematical operations such as sin/cosine (via __sin__ and __cos__) were available as base parts of the python data model [0].  this would make it easier to write new math classes, and it would eliminate the ugliness of things like self.exp().

this would also eliminate the need for separate math and cmath libraries since those could be builtin to the default float and complex types.  of course if those libs were removed, that would cause a lot of backward compatibility breakage.

it would also help new users who just want to do math and don't know that they need to import separate classes just for elementary math functionality.

anyway, just a thought.

[0] http://docs.python.org/reference/datamodel.html

----------
components: Interpreter Core
messages: 116966
nosy: Michael.Gilbert
priority: normal
severity: normal
status: open
title: including elementary mathematical functions in default types
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9906>
_______________________________________

From report at bugs.python.org  Mon Sep 20 23:36:47 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Sep 2010 21:36:47 +0000
Subject: [New-bugs-announce] [issue9907] interactive mode TAB does not
	insert on OS X built with	editline instead of GNU readline
In-Reply-To: <1285018607.7.0.0427821796342.issue9907@psf.upfronthosting.co.za>
Message-ID: <1285018607.7.0.0427821796342.issue9907@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

When building Python on OS X, there is now support for linking Python with the readline compatibility interface of the OS X supplied BSD editline library rather than using the GNU readline library.  Because of deficiencies in the version in earlier OS X releases, this support is only enabled for builds with a deployment target of 10.5 or higher.  With the python 2.7 release, for the first time a python.org installer for OS X is available that uses this capability: the 10.5 and higher 32-bit/64-bit version. The 10.3 and higher 32-bit-only installer uses GNU readline as do previous installers.  There is a behavior regression in the editline-linked versions: when started in interactive mode, the TAB key does not insert, rather it inserts a "./" file spec in the command buffer and a second TAB causes a completion search of files in the current directory.

With readline and typing <TAB> <CR>:

  $ unset PYTHONSTARTUP 
  $ python2.7
  Python 2.7 (r27:82508, Jul  3 2010, 20:17:05) 
  [GCC 4.0.1 (Apple Inc. build 5493)] on darwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>>     
  ... 
  $ 

With editline and <TAB> <CR>:

  $ unset PYTHONSTARTUP 
  $ python2.7
  Python 2.7 (r27:82508, Jul  3 2010, 21:12:11) 
  [GCC 4.0.1 (Apple Inc. build 5493)] on darwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>> ./
    File "<stdin>", line 1
      ./
      ^
  SyntaxError: invalid syntax
  >>> ^D

Two workarounds for python2.7 until the problem is addressed in a future installer:

   (1) either install the 10.3 and up python 2.7

or (2) add or edit a python startup file for python2.7:

       $ cat > $HOME/.pystartup
       import readline
       if 'libedit' in readline.__doc__:
           readline.parse_and_bind("bind ^I ed-insert")
       ^D
       $ export PYTHONSTARTUP=$HOME/.pystartup


Since whitespace is significant in Python, Modules/readline.c initialization attempts to override TAB behavior by forcing TAB to "insert" by default (unless overridden by later readline module calls).  Somehow that is failing when going through editline's readline compatibility layer.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 116981
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: interactive mode TAB does not insert on OS X built with editline instead of GNU readline
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9907>
_______________________________________

From report at bugs.python.org  Tue Sep 21 02:04:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Sep 2010 00:04:16 +0000
Subject: [New-bugs-announce] [issue9908] os.stat() fails on bytes paths
	under Windows 7
In-Reply-To: <1285027456.78.0.828515138477.issue9908@psf.upfronthosting.co.za>
Message-ID: <1285027456.78.0.828515138477.issue9908@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Under Windows 7, there is another path in posixmodule.c for stat() (because of the link dereferencing feature, it seems). This path fails for the bytes version. It turns out that GetFinalPathNameByHandleA returns a value which is one byte too small (while GetFinalPathNameByHandleW returns the expected value). The MSDN doc (*) seems to mention it although with a strange wording:

    ?Windows Server 2008 and Windows Vista:  For the ANSI version of this function, GetFinalPathNameByHandleA, the return value includes the size of the terminating null character.?

(*) http://msdn.microsoft.com/en-us/library/aa364962%28VS.85%29.aspx

The net result is that, when we give 'buf_size+1' to the second GetFinalPathNameByHandleA() call after 'buf_size' was returned by the first call, the buffer is still not big enough and it doesn't get filled. The subsequent call to win32_lstat() is done with a bogus path and fails with "[Error 2]: the system cannot find the file specified".

Here is a patch fixing this and also harmonizing win32_stat() and win32_stat_w(). I've added a test, although additional tests for bytes symlinks would probably be deserved. Please review.

PS: the context is:
http://mail.python.org/pipermail/python-dev/2010-September/103860.html

----------
components: Library (Lib), Windows
files: win7statbytes.patch
keywords: patch
messages: 117009
nosy: brian.curtin, db3l, pitrou, tim.golden
priority: high
severity: normal
status: open
title: os.stat() fails on bytes paths under Windows 7
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file18940/win7statbytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9908>
_______________________________________

From report at bugs.python.org  Tue Sep 21 05:27:43 2010
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Tue, 21 Sep 2010 03:27:43 +0000
Subject: [New-bugs-announce] [issue9909] request for calendar.dayofyear()
	function
In-Reply-To: <1285039663.27.0.59327234025.issue9909@psf.upfronthosting.co.za>
Message-ID: <1285039663.27.0.59327234025.issue9909@psf.upfronthosting.co.za>


New submission from Jeffrey Finkelstein <jeffrey.finkelstein at gmail.com>:

This is a function which computes the integer between 1 and 366 representing the day of the year, given a year, month, and day.

The implementation I have provided computes the difference between the ordinal numbers of the given day and January first of that month.

This will be useful in resolving issue9864, in which parsing of date strings has an unimplemented "day of year" feature.

----------
components: Library (Lib)
files: dayofyear.patch
keywords: patch
messages: 117024
nosy: jfinkels
priority: normal
severity: normal
status: open
title: request for calendar.dayofyear() function
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file18941/dayofyear.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9909>
_______________________________________

From report at bugs.python.org  Tue Sep 21 08:32:34 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 21 Sep 2010 06:32:34 +0000
Subject: [New-bugs-announce] [issue9910] Add Py_SetPath API for embeddint
	python
In-Reply-To: <1285050754.57.0.81319423251.issue9910@psf.upfronthosting.co.za>
Message-ID: <1285050754.57.0.81319423251.issue9910@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

When calling Py_Initialize() from an embedding application, there is currently no way for the application to override Python's initial settin g of sys.path.  An elaborate mechanism in getpathp.c kicks in, guessing the path based on several criteria.

Ideally, this mechanism, which is valid only for python.exe and its semantics, should be opt in.  It forces embedders that have their own libraries to go through complicated hoops (with environment variables and what not) to direct their embedded interpreter at the right place for modules, and to make sure that it is not confused by any other python distribution present on the system.

This submission adds a Py_SetPath() function to the API.  This has been successfully used by CCP in EVE Online and other products to completely override python's path guessing mechanics.  If called with a semicolon separated path prior to Py_Initialize, it will be used as the fodder for the initial sys.path.

----------
components: Interpreter Core
files: py_setpath.patch
keywords: easy, needs review, patch
messages: 117030
nosy: krisvale
priority: normal
severity: normal
status: open
title: Add Py_SetPath API for embeddint python
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file18943/py_setpath.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9910>
_______________________________________

From report at bugs.python.org  Tue Sep 21 16:43:01 2010
From: report at bugs.python.org (DSM)
Date: Tue, 21 Sep 2010 14:43:01 +0000
Subject: [New-bugs-announce] [issue9911] doc copyedits
In-Reply-To: <1285080181.79.0.899000794299.issue9911@psf.upfronthosting.co.za>
Message-ID: <1285080181.79.0.899000794299.issue9911@psf.upfronthosting.co.za>


New submission from DSM <dsm001 at users.sourceforge.net>:

Various typo fixes for the docs.  As usual, I left historical documents alone (except for 3.1 whatsnew: fixed the spelling of Jack Diederich's name).  Fixing ~30 means I probably introduced ~3 problems of my own, but that should still be a net win..

Patch against py3k r84944.

----------
assignee: docs at python
components: Documentation
files: typos.patch
keywords: patch
messages: 117052
nosy: docs at python, dsm001
priority: normal
severity: normal
status: open
title: doc copyedits
versions: Python 3.3
Added file: http://bugs.python.org/file18947/typos.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9911>
_______________________________________

From report at bugs.python.org  Tue Sep 21 17:24:36 2010
From: report at bugs.python.org (Floris Bruynooghe)
Date: Tue, 21 Sep 2010 15:24:36 +0000
Subject: [New-bugs-announce] [issue9912] Fail when vsvarsall.bat produces
	stderr
In-Reply-To: <1285082676.18.0.058541871992.issue9912@psf.upfronthosting.co.za>
Message-ID: <1285082676.18.0.058541871992.issue9912@psf.upfronthosting.co.za>


New submission from Floris Bruynooghe <floris.bruynooghe at gmail.com>:

It would have saved me a lot of time if msvc9compiler would fail if executing the vsvarsall.bat file produced any output.  The attached patch does this and fails when I try to compile from within a cygwin environment.  I've also tested this from the normal windows command prompt and there buiding does succeed with this patch applied.

----------
assignee: tarek
components: Distutils
files: msvc9.diff
keywords: patch
messages: 117067
nosy: eric.araujo, flub, tarek
priority: normal
severity: normal
status: open
title: Fail when vsvarsall.bat produces stderr
type: feature request
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file18950/msvc9.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9912>
_______________________________________

From report at bugs.python.org  Tue Sep 21 17:57:48 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 21 Sep 2010 15:57:48 +0000
Subject: [New-bugs-announce] [issue9913] Misc/SpecialBuilds.txt is out of
	date
In-Reply-To: <1285084668.56.0.665403194927.issue9913@psf.upfronthosting.co.za>
Message-ID: <1285084668.56.0.665403194927.issue9913@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

It looks like Misc/SpecialBuilds.txt has not been updated since 2.4.

This file is referenced from C-API documentation [1], but is not accessible as a hyperlink.

Some of the recommendations in this file are out of date, in particular those that recommend setting make variables where a configure switch is available.

I believe it would be best to retire Misc/SpecialBuilds.txt and move still relevant sections to proper .rst files.


[1] http://docs.python.org/dev/py3k/c-api/intro.html#debugging-builds

----------
assignee: docs at python
components: Documentation
messages: 117076
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: Misc/SpecialBuilds.txt  is out of date
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9913>
_______________________________________

From report at bugs.python.org  Tue Sep 21 20:17:45 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 21 Sep 2010 18:17:45 +0000
Subject: [New-bugs-announce] [issue9914] trace/profile conflict with the use
	of	sys.modules[__name__]
In-Reply-To: <1285093065.41.0.819526070425.issue9914@psf.upfronthosting.co.za>
Message-ID: <1285093065.41.0.819526070425.issue9914@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

The main() method of trace and profile modules attempt to emulate the environment in which traced code runs when invoked directly, but it fails in several respects.   The specific problem which is the subject of this issue is that while __name__ is set to '__main__' in code globals, sys.modules['__main__'] still point to the trace/profile module.

Among other problems, this conflicts, with a popular idiom used in regression test scripts:

   support.run_unittest(__name__)

For example,

$ python -m trace -c -C trace.d Lib/test/test_optparse.py 

----------------------------------------------------------------------
Ran 0 tests in 0.001s

OK

No tests are ran because run_unittests() looks for test case classes in the trace module and finds none.


This is related to #9323, so I am merging in the nosy list.  See also r83393.

----------
assignee: belopolsky
components: Library (Lib)
messages: 117090
nosy: belopolsky, eli.bendersky, ezio.melotti, flox, georg.brandl
priority: normal
severity: normal
status: open
title: trace/profile conflict with the use of sys.modules[__name__]
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9914>
_______________________________________

From report at bugs.python.org  Tue Sep 21 22:03:32 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 21 Sep 2010 20:03:32 +0000
Subject: [New-bugs-announce] [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

(I've made an educated guess about who to add to the Nosy list)

The attached patch substantially speeds up sorting using the "key" parameter.  It is purely a performance patch; the language and libraries are not changed in any other way from the users point of view.  I measured a reduction in execution time of at least 15% in many cases and more than 40% for large n.

I performed measurements on an Intel 64-bit Linux system using gcc 4.3.2 and on an Intel 32-bit Windows XP system using Visual C Express Edition 2009.

Previously, "key" was implemented by a creating a sortwrapperobject, which is a PyObject storing a key and a value and using only the key for comparison.  

With the patch, sortwrapperobject is removed entirely.  Instead, the sort uses two arrays: one for keys and one for values.  Comparisons use the keys array.  Whenever a swap is performed, the swap is performed on both arrays.  If the "keys" parameter is not provided to the sort, the second swap is skipped (since the keys are also the values).

Compared to the sortwrapperobject approach, speed is improved by:
- Requiring only 1 memory allocation for an array of PyObject *'s, instead of n memory allocations for n sortwrapperobjects
- Removes the need to dereference through sortwrapperobjects, which were scattered about in memory (i.e., had poor cache locality)
- Substantially smaller memory overhead, further improving cache performance
 
When the "key" parameter is not used, the code still needs to check to see if it should be performing a second swap.  However, the additional instructions are cache and branch-prediction friendly and do not have a noticeable impact on performance.  I conducted enough experiments to establish a 95% confidence interval that excluded a slowdown of more than 1% (but did not exclude a slowdown of 0% - which is good).

A handful of results:

# No key, same speed
otto:~$ py3k-git-base/python -m timeit -s 'x = list(range(5))' -s 'f = x.sort' 'f()'
1000000 loops, best of 3: 0.276 usec per loop
otto:~$ py3k-git/python -m timeit -s 'x = list(range(5))' -s 'f = x.sort' 'f()' 
1000000 loops, best of 3: 0.276 usec per loop

# With a key, patched version is faster
otto:~$ py3k-git-base/python -m timeit -s 'x = list(range(5))' -s 'f = x.sort' 'f(key=int)'
1000000 loops, best of 3: 1.76 usec per loop
otto:~$ py3k-git/python -m timeit -s 'x = list(range(5))' -s 'f = x.sort' 'f(key=int)'
1000000 loops, best of 3: 1.5 usec per loop

# Results are more dramatic with large n
otto:~$ py3k-git-base/python -m timeit -s 'x = list(range(100000))' -s 'f = x.sort' 'f(key=int)'
10 loops, best of 3: 35.2 msec per loop
otto:~$ py3k-git/python -m timeit -s 'x = list(range(100000))' -s 'f = x.sort' 'f(key=int)'
10 loops, best of 3: 22.4 msec per loop

I have been using a script for running a large battery of experiments with different values of n and different conditions (random data, sorted data, reverse-sorted data, key, no key, etc.).  The script works, but it's clunky to use.  I'm working on cleaning that up and hope to attach it to this issue within the next few days.

----------
assignee: stutzbach
components: Library (Lib)
files: sort-key-locality.diff
keywords: patch
messages: 117097
nosy: collinwinter, rhettinger, stutzbach, tim_one
priority: normal
severity: normal
stage: patch review
status: open
title: speeding up sorting with a key
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file18952/sort-key-locality.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Tue Sep 21 23:44:12 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 21 Sep 2010 21:44:12 +0000
Subject: [New-bugs-announce] [issue9916] errno module is missing some symbols
In-Reply-To: <1285105452.83.0.807715545592.issue9916@psf.upfronthosting.co.za>
Message-ID: <1285105452.83.0.807715545592.issue9916@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

According to this message, Python's errno module is missing some symbols:

https://lists.ubuntu.com/archives/ubuntu-devel/2010-August/031341.html

ENOMEDIUM       123     /* No medium found */
EMEDIUMTYPE     124     /* Wrong medium type */
ECANCELED       125     /* Operation Canceled */
ENOKEY          126     /* Required key not available */
EKEYEXPIRED     127     /* Key has expired */
EKEYREVOKED     128     /* Key has been revoked */
EKEYREJECTED    129     /* Key was rejected by service */
EOWNERDEAD      130     /* Owner died */
ENOTRECOVERABLE 131     /* State not recoverable */
ERFKILL         132     /* Operation not possible due to RF-kill */

While we're at it, it might be nice to add -m functionality to print out the errno, though I'm not even sure this is possible with an extension module.

----------
assignee: barry
components: Extension Modules
messages: 117105
nosy: barry
priority: normal
severity: normal
status: open
title: errno module is missing some symbols
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9916>
_______________________________________

From report at bugs.python.org  Wed Sep 22 03:42:57 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Sep 2010 01:42:57 +0000
Subject: [New-bugs-announce] [issue9917] resource max value represented as
	signed when should be	unsigned
In-Reply-To: <1285119777.0.0.437398080007.issue9917@psf.upfronthosting.co.za>
Message-ID: <1285119777.0.0.437398080007.issue9917@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Breaking out the library bug discussed in issue 678264 from the test bug the issue is about.

See msg14344 and msg116479.

----------
components: Library (Lib)
messages: 117123
nosy: ajaksu2, loewis, mdr0, nnorwitz, r.david.murray, sable
priority: normal
severity: normal
stage: needs patch
status: open
title: resource max value represented as signed when should be unsigned
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9917>
_______________________________________

From report at bugs.python.org  Wed Sep 22 10:20:05 2010
From: report at bugs.python.org (ingemar)
Date: Wed, 22 Sep 2010 08:20:05 +0000
Subject: [New-bugs-announce] [issue9918] Installation "make test",
	two fails if non-ascii path
In-Reply-To: <1285143605.22.0.680406805216.issue9918@psf.upfronthosting.co.za>
Message-ID: <1285143605.22.0.680406805216.issue9918@psf.upfronthosting.co.za>


New submission from ingemar <ingemar at sijohansson.com>:

I am using Kubuntu 10.4 on a no-brand box with a 64-bit CPU.
I use my own download and install of Python 3.1, SIP and PyQt.

The default download directory as set up by the Kubuntu install is /home/ingemar/H?mtningar,
where "H?mtningar" is Swedish and corresponds to "Download". 
This is where the download of Python-3.1.2.tar.bz2 gets stored by default.
And this is where I let Krusader store the Python-3.1.2 folder that it pulls out of the bz2.
So I step into that folder and run ./configure,  make,  make test,  -- whoops, two tests fail:
-----------------------------------------------------------------------------------------------------
....
test_cmd
test_cmd_line
Warning: os.environ was modified by test_cmd_line
test test_cmd_line failed -- Traceback (most recent call last):
  File "/home/ingemar/H?mtningar/Python-3.1.2/Lib/test/test_cmd_line.py", line 181, in test_large_PYTHONPATH
    self.assertTrue(path1.encode('ascii') in stdout)
AssertionError: False is not True

test_cmd_line_script
test_code
....


....
test_xdrlib
test_xml_etree
test_xml_etree_c
test_xmlrpc
Traceback (most recent call last):
  File "/home/ingemar/H?mtningar/Python-3.1.2/Lib/xmlrpc/server.py", line 448, in do_POST
    size_remaining = int(self.headers["content-length"])
ValueError: invalid literal for int() with base 10: 'I am broken'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/ingemar/H?mtningar/Python-3.1.2/Lib/socketserver.py", line 281, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/home/ingemar/H?mtningar/Python-3.1.2/Lib/socketserver.py", line 307, in process_request
    self.finish_request(request, client_address)
  File "/home/ingemar/H?mtningar/Python-3.1.2/Lib/socketserver.py", line 320, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/home/ingemar/H?mtningar/Python-3.1.2/Lib/socketserver.py", line 614, in __init__
    self.handle()
  File "/home/ingemar/H?mtningar/Python-3.1.2/Lib/http/server.py", line 352, in handle
    self.handle_one_request()
  File "/home/ingemar/H?mtningar/Python-3.1.2/Lib/http/server.py", line 346, in handle_one_request
    method()
  File "/home/ingemar/H?mtningar/Python-3.1.2/Lib/xmlrpc/server.py", line 472, in do_POST
    self.send_header("X-traceback", traceback.format_exc())
  File "/home/ingemar/H?mtningar/Python-3.1.2/Lib/http/server.py", line 410, in send_header
    self.wfile.write(("%s: %s\r\n" % (keyword, value)).encode('ASCII', 'strict'))
UnicodeEncodeError: 'ascii' codec can't encode character '\xe4' in position 71: ordinal not in range(128)
test test_xmlrpc failed -- Traceback (most recent call last):
  File "/home/ingemar/H?mtningar/Python-3.1.2/Lib/test/test_xmlrpc.py", line 555, in test_fail_with_info
    p.pow(6,8)
xmlrpc.client.ProtocolError: <ProtocolError for 127.0.0.1:46081/RPC2: 500 Internal Server Error>

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/ingemar/H?mtningar/Python-3.1.2/Lib/test/test_xmlrpc.py", line 562, in test_fail_with_info
    self.assertTrue(e.headers.get("X-traceback") is not None)
AssertionError: False is not True

test_xmlrpc_net
test_xmlrpc_net skipped -- Use of the `network' resource not enabled
test_zipfile
test_zipfile64
test_zipfile64 skipped -- test requires loads of disk-space bytes and a long time to run
test_zipimport
test_zipimport_support
test_zlib
312 tests OK.
2 tests failed:
    test_cmd_line test_xmlrpc
22 tests skipped:
    test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp
    test_codecmaps_kr test_codecmaps_tw test_curses test_kqueue
    test_nis test_ossaudiodev test_pep277 test_smtpnet
    test_socketserver test_startfile test_timeout test_tk
    test_ttk_guionly test_urllib2net test_urllibnet test_winreg
    test_winsound test_xmlrpc_net test_zipfile64
Those skips are all expected on linux2.
make: *** [test] Fel 1
...
-----------------------------------------------------------------------------------------------------







Those two test don't like the Swedish dotted character "?" in the folder name.
I renamed the folder into pure ASCII and restarted: 
./configure,  make,  make test,  sudo make install.
Everything worked as expected:
.....
314 tests OK.
22 tests skipped:
.....

----------
components: None
messages: 117128
nosy: ingemar
priority: normal
severity: normal
status: open
title: Installation "make test", two fails if non-ascii path
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9918>
_______________________________________

From report at bugs.python.org  Wed Sep 22 12:34:36 2010
From: report at bugs.python.org (qpatata)
Date: Wed, 22 Sep 2010 10:34:36 +0000
Subject: [New-bugs-announce] [issue9919] gdbinit lineno result is one line
	in excess
In-Reply-To: <1285151676.58.0.234965887204.issue9919@psf.upfronthosting.co.za>
Message-ID: <1285151676.58.0.234965887204.issue9919@psf.upfronthosting.co.za>


New submission from qpatata <qpatata at gmail.com>:

Thanks a lot to all python teams for your excel.lent work.

When latest version of gdbinit macros is used to debug with gdb a python 2.4 session, the result from lineno macro seems one line more than the correct one.

If we compare the gdb macro:

define lineno
    set $__continue = 1
    set $__co = f->f_code
    set $__lasti = f->f_lasti
    set $__sz = ((PyStringObject *)$__co->co_lnotab)->ob_size/2
    set $__p = (unsigned char *)((PyStringObject *)$__co->co_lnotab)->ob_sval
    set $__li = $__co->co_firstlineno
    set $__ad = 0
    while ($__sz-1 >= 0 && $__continue)
      set $__sz = $__sz - 1
      set $__ad = $__ad + *$__p
      set $__p = $__p + 1
      if ($__ad > $__lasti)
	set $__continue = 0
      end
      set $__li = $__li + *$__p
      set $__p = $__p + 1
    end
    printf "%d", $__li
end

with the related C source code in libpython.py

    def addr2line(self, addrq):
        '''
        Get the line number for a given bytecode offset

        Analogous to PyCode_Addr2Line; translated from pseudocode in
        Objects/lnotab_notes.txt
        '''
        co_lnotab = self.pyop_field('co_lnotab').proxyval(set())

        # Initialize lineno to co_firstlineno as per PyCode_Addr2Line
        # not 0, as lnotab_notes.txt has it:
        lineno = int_from_int(self.field('co_firstlineno'))

        addr = 0
        for addr_incr, line_incr in zip(co_lnotab[::2], co_lnotab[1::2]):
            addr += ord(addr_incr)
            if addr > addrq:
                return lineno
            lineno += ord(line_incr)
        return lineno

we see that if addr  is greater than addrq, the python codes returns immedialty, but the gdb macro adds a new delta of lines before exit the loop.

Kind regards.

----------
messages: 117133
nosy: qpatata
priority: normal
severity: normal
status: open
title: gdbinit lineno result is one line in excess
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9919>
_______________________________________

From report at bugs.python.org  Wed Sep 22 16:13:08 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 22 Sep 2010 14:13:08 +0000
Subject: [New-bugs-announce] [issue9920] test_cmath on atan fails on AIX
In-Reply-To: <1285164788.53.0.85582412597.issue9920@psf.upfronthosting.co.za>
Message-ID: <1285164788.53.0.85582412597.issue9920@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

test_cmath will fail with the following error on AIX:

======================================================================
FAIL: test_specific_values (test.test_cmath.CMathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/buildbot/buildbot-aix6/py3k-aix6-xlc/build/Lib/test/test_cmath.py", line 350, in test_specific_values
    msg=error_message)
  File "/san_cis/home/cis/buildbot/buildbot-aix6/py3k-aix6-xlc/build/Lib/test/test_cmath.py", line 94, in rAssertAlmostEqual
    'got {!r}'.format(a, b))
AssertionError: atan0000: atan(complex(0.0, 0.0))
Expected: complex(0.0, 0.0)
Received: complex(0.0, -0.0)
Received value insufficiently close to expected value.


There is a test concerning tanh in configure, which may be related:
checking whether tanh preserves the sign of zero... yes

----------
components: Library (Lib)
messages: 117141
nosy: sable
priority: normal
severity: normal
status: open
title: test_cmath on atan fails on AIX
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9920>
_______________________________________

From report at bugs.python.org  Wed Sep 22 17:22:57 2010
From: report at bugs.python.org (Radu Grigore)
Date: Wed, 22 Sep 2010 15:22:57 +0000
Subject: [New-bugs-announce] [issue9921] os.path.join('x','') behavior
In-Reply-To: <1285168977.46.0.728141650864.issue9921@psf.upfronthosting.co.za>
Message-ID: <1285168977.46.0.728141650864.issue9921@psf.upfronthosting.co.za>


New submission from Radu Grigore <radugrigore at gmail.com>:

The docs say that "the return value is the concatenation of path1, and optionally path2, etc., with exactly one directory separator (os.sep) inserted between components, unless path2 is empty."

But os.path.join('x','') returns 'x/' in which path1 and path2 *are* separated by exactly one os.sep, even though path2 is empty.

Either the docs or the implementation should be updated.

----------
components: Library (Lib)
messages: 117146
nosy: rgrig
priority: normal
severity: normal
status: open
title: os.path.join('x','') behavior
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9921>
_______________________________________

From report at bugs.python.org  Thu Sep 23 00:06:39 2010
From: report at bugs.python.org (geremy condra)
Date: Wed, 22 Sep 2010 22:06:39 +0000
Subject: [New-bugs-announce] [issue9922] subprocess.getstatusoutput and bytes
In-Reply-To: <1285193199.71.0.119462884073.issue9922@psf.upfronthosting.co.za>
Message-ID: <1285193199.71.0.119462884073.issue9922@psf.upfronthosting.co.za>


New submission from geremy condra <debatem1 at gmail.com>:

It looks like subprocess.getstatusoutput on 3.2a1 tries to coerce to UTF-8, which fails when dealing with bytes. This demonstrates the behavior nearly all the time for me on Ubuntu 10.04:

>>> import subprocess
>>> subprocess.getstatusoutput('dd if=/dev/random bs=1K count=1')

Here's the tracebacks from a few runs:

>>> subprocess.getstatusoutput('dd if=/dev/random bs=1K count=1')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.2/subprocess.py", line 585, in getstatusoutput
    text = pipe.read()
  File "/usr/local/lib/python3.2/codecs.py", line 300, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xcb in position 3: invalid continuation byte
>>> subprocess.getstatusoutput('dd if=/dev/random bs=1K count=1')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.2/subprocess.py", line 585, in getstatusoutput
    text = pipe.read()
  File "/usr/local/lib/python3.2/codecs.py", line 300, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xe4 in position 2: invalid continuation byte
>>> subprocess.getstatusoutput('dd if=/dev/random bs=1K count=1')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.2/subprocess.py", line 585, in getstatusoutput
    text = pipe.read()
  File "/usr/local/lib/python3.2/codecs.py", line 300, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xac in position 0: invalid start byte
>>> subprocess.getstatusoutput('dd if=/dev/random bs=1K count=1')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.2/subprocess.py", line 585, in getstatusoutput
    text = pipe.read()
  File "/usr/local/lib/python3.2/codecs.py", line 300, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xf1 in position 0: invalid continuation byte
>>> 

And here's the version info:

Python 3.2a1 (r32a1:83318, Aug 13 2010, 22:32:03) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.

----------
components: Library (Lib)
messages: 117156
nosy: debatem1
priority: normal
severity: normal
status: open
title: subprocess.getstatusoutput and bytes
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9922>
_______________________________________

From report at bugs.python.org  Thu Sep 23 05:03:56 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Thu, 23 Sep 2010 03:03:56 +0000
Subject: [New-bugs-announce] [issue9923] mailcap module may will not work on
	non-POSIX platforms	if MAILCAPS env variable is set
In-Reply-To: <1285211036.93.0.380980799093.issue9923@psf.upfronthosting.co.za>
Message-ID: <1285211036.93.0.380980799093.issue9923@psf.upfronthosting.co.za>


New submission from Gregory Nofi <crackityjones2004-p at yahoo.com>:

mailcap.getcaps() has a call to mailcap.listmailcapfiles(), which returns a list of all mailcap files found on the system.

listmailcapfiles() first looks for the MAILCAPS environment variable. If it exists, it converts the string value into a list by splitting it on ":". This will not work on platforms that use other path separators, like Windows (";").

Attached are patches that use os.pathsep instead.

For more information about the MAILCAPS variable, see Appendix A in RFC 1524 (http://tools.ietf.org/html/rfc1524.html).

----------
assignee: ronaldoussoren
components: Library (Lib), Macintosh, Windows
files: mailcap_trunk.py
messages: 117163
nosy: gnofi, ronaldoussoren
priority: normal
severity: normal
status: open
title: mailcap module may will not work on non-POSIX platforms if MAILCAPS env variable is set
type: behavior
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file18969/mailcap_trunk.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9923>
_______________________________________

From report at bugs.python.org  Thu Sep 23 05:56:06 2010
From: report at bugs.python.org (mike bayer)
Date: Thu, 23 Sep 2010 03:56:06 +0000
Subject: [New-bugs-announce] [issue9924] sqlite3 SELECT does not BEGIN a
	transaction, but should according to spec
In-Reply-To: <1285214166.49.0.269440190097.issue9924@psf.upfronthosting.co.za>
Message-ID: <1285214166.49.0.269440190097.issue9924@psf.upfronthosting.co.za>


New submission from mike bayer <mike_mp at zzzcomputing.com>:

Copying this bug from the pysqlite tracker, at http://code.google.com/p/pysqlite/issues/detail?id=21 , as the issue has been opened for two days with no reply. (side node - should sqlite3 bugs be reported here or on the pysqlite tracker ?)  The text below was originally written by Randall Nortman:

Pysqlite does not open a transaction in the database until a DML statement is encountered (INSERT, UPDATE, or DELETE).  A DQL (SELECT) statement will not cause a transaction to be opened if one is not already opened.  This is the documented behavior, but it is not what is intended by the spec (PEP 249).  The spec intends a transaction to always be open (per the spec author), and this is what happens in other DB-API drivers.  For more information, see the this DB-SIG mailing list post (by the PEP 249 author):

http://mail.python.org/pipermail/db-sig/2010-September/005645.html

For additional background, see this thread on the SQLAlchemy mailing list, which is the source of the attached test case:

http://groups.google.com/group/sqlalchemy/browse_thread/thread/2f47e28c1fcdf9e6/0ef1666759ce0724#0ef1666759ce0724

What steps will reproduce the problem?
1. See attached test case.  Run it as is, and the final conn1.commit() statement will complete successfully.
2. Uncomment the c2.execute("BEGIN") line and run again; this time conn1.commit() hangs until a timeout, then a "Database is locked" error is returned.

What is the expected output? What do you see instead?

The BEGIN should be issued implicitly, and even without doing it explicitly, the commit should block and then return the DB locked error.

What version of the product are you using? On what operating system?

Python 2.6.6 with its built-in sqlite3 module, on Debian Squeeze x86.

import sqlite3
import os

if os.path.exists("file.db"):
    os.unlink("file.db")
    
conn1 = sqlite3.connect("file.db")

c1 = conn1.cursor()

c1.execute("PRAGMA read_uncommitted=SERIALIZABLE")

c1.execute("""create table foo (id integer primary key, data varchar(30))""")
c1.execute("insert into foo(id, data) values (1, 'data1')")
c1.close()
conn1.commit()

c1 = conn1.cursor()
c1.execute("select * from foo where id=1")
row1 = c1.fetchone()
c1.close()

conn2 = sqlite3.connect("file.db")
c2 = conn2.cursor()

c2.execute("PRAGMA read_uncommitted=SERIALIZABLE")

# sqlite3 should be doing this automatically.
# when called, conn1's commit blocks
#c2.execute("BEGIN")
c2.execute("select * from foo where id=1")
row2 = c2.fetchone()
c2.close()

c1 = conn1.cursor()
c1.execute("update foo set data='data2'")

print "About to commit conn1..."
conn1.commit()

----------
components: Library (Lib)
messages: 117167
nosy: zzzeek
priority: normal
severity: normal
status: open
title: sqlite3 SELECT does not BEGIN a transaction, but should according to spec
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9924>
_______________________________________

From report at bugs.python.org  Thu Sep 23 15:46:14 2010
From: report at bugs.python.org (Stephan Bellegy)
Date: Thu, 23 Sep 2010 13:46:14 +0000
Subject: [New-bugs-announce] [issue9925] Idle doesn't launch
In-Reply-To: <1285249574.15.0.491090079116.issue9925@psf.upfronthosting.co.za>
Message-ID: <1285249574.15.0.491090079116.issue9925@psf.upfronthosting.co.za>


New submission from Stephan Bellegy <stephan.bellegy at gmail.com>:

Environment is Win7, 32bits. User has Admin rights.

I haven't coded in Python at the office for a while and had a little script to write. Thus, I decided to upgrade from 2.6 to 2.7 (that is : 2.6 was already there and functionnal as far as I remind it and was the first install of Python on the new PC)

2.7 installation run without problems nor warnings, as usual.
But then Idle didn't launch. No message. No Python process running in the background. So I launched it via a shell and grabbed an error message :
IOError: [Errno 13] Permission denied: 'C:\\Users\\Foobar\\.idlerc\\recent-files.lst'

Then I googled and found http://bugs.python.org/issue1743

Deleting ~\.idlerc\ did the trick and now Idle runs fine.

So the bug 1743 isn't clearly solved and this is what I suspect :
My Windows is localized in French. From the DOS Shell, the User Dir is C:\Users\FOOBAR
but Windows Explorer displays in its address bar : C:\Utilisateurs\FOOBAR
Maybe the problem comes from here ?

----------
components: IDLE, Installation
messages: 117184
nosy: Stephan.Bellegy
priority: normal
severity: normal
status: open
title: Idle doesn't launch
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9925>
_______________________________________

From report at bugs.python.org  Thu Sep 23 16:32:48 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 23 Sep 2010 14:32:48 +0000
Subject: [New-bugs-announce] [issue9926] Wrapped TestSuite subclass does not
	get __call__ executed
In-Reply-To: <1285252368.31.0.189981048833.issue9926@psf.upfronthosting.co.za>
Message-ID: <1285252368.31.0.189981048833.issue9926@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

In Python 3.2, when inheriting from TestSuite, it is no longer possible to override __call__ (e.g. to introduce a TestSuite setUp and tearDown).
The __call__ method will not be called anymore.

Instead, if the object has a _wrapped_run defined (which it will, since it inherits from TestSuite), then this is called instead. Overriding _wrapped_run is a work-around, however, this being a private method, overriding it is probably not a good idea.

----------
assignee: michael.foord
messages: 117192
nosy: loewis, michael.foord
priority: normal
severity: normal
status: open
title: Wrapped TestSuite subclass does not get __call__ executed
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9926>
_______________________________________

From report at bugs.python.org  Thu Sep 23 17:39:08 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 23 Sep 2010 15:39:08 +0000
Subject: [New-bugs-announce] [issue9927] Leak around
	GetFinalPathNameByHandle (Windows)
In-Reply-To: <1285256348.46.0.508900650323.issue9927@psf.upfronthosting.co.za>
Message-ID: <1285256348.46.0.508900650323.issue9927@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

I've found there are leaks around GetFinalPathNameByHandle in
Modules/posixmodule.c. (Leaks when function fails)

I hope attached patch will fix this.

----------
components: Windows
files: py3k_fix_leak_around_GetFinalPathNameByHandle.patch
keywords: patch
messages: 117197
nosy: ocean-city
priority: normal
severity: normal
status: open
title: Leak around GetFinalPathNameByHandle (Windows)
versions: Python 3.2
Added file: http://bugs.python.org/file18979/py3k_fix_leak_around_GetFinalPathNameByHandle.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9927>
_______________________________________

From report at bugs.python.org  Thu Sep 23 19:44:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 23 Sep 2010 17:44:20 +0000
Subject: [New-bugs-announce] [issue9928] weird oddity with bz2 context
	manager
In-Reply-To: <1285263860.75.0.0295269513822.issue9928@psf.upfronthosting.co.za>
Message-ID: <1285263860.75.0.0295269513822.issue9928@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I haven't investigated but this is weird (especially the fact that it doesn't *always* happen). There might be a problem with SETUP_WITH or perhaps the method cache:

>>> import bz2
>>> f = bz2.BZ2File('foo.bz2', 'wb')
>>> with f: pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: __exit__
>>> f.__enter__().__exit__(None, None, None)
>>>

----------
components: Interpreter Core, Library (Lib)
messages: 117210
nosy: amaury.forgeotdarc, arigo, benjamin.peterson, pitrou
priority: normal
severity: normal
status: open
title: weird oddity with bz2 context manager
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9928>
_______________________________________

From report at bugs.python.org  Thu Sep 23 20:15:42 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 23 Sep 2010 18:15:42 +0000
Subject: [New-bugs-announce] [issue9929] subprocess.Popen unbuffered not
	work (windows)
In-Reply-To: <1285265742.42.0.656694330002.issue9929@psf.upfronthosting.co.za>
Message-ID: <1285265742.42.0.656694330002.issue9929@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Following script hangs on Python3.x.

from subprocess import *
import sys

p = Popen([sys.executable, "-c", "import sys; print(sys.stdin.read(1))"], stdin=PIPE)
p.stdin.write(b'x')
p.wait()

This is because unbuffered functionality of
subprocess.Popen is disabled. Is this still needed?

I confirmed test_subprocess passes with the attached
patch.

----------
components: Windows
files: py3k_fix_unbuffered_in_subprocess.patch
keywords: patch
messages: 117213
nosy: ocean-city
priority: normal
severity: normal
status: open
title: subprocess.Popen unbuffered not work (windows)
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file18980/py3k_fix_unbuffered_in_subprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9929>
_______________________________________

From report at bugs.python.org  Thu Sep 23 20:39:52 2010
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 23 Sep 2010 18:39:52 +0000
Subject: [New-bugs-announce] [issue9930] Incorrect semantics of __radd__
	method for builtin types
In-Reply-To: <1285267192.74.0.813927105785.issue9930@psf.upfronthosting.co.za>
Message-ID: <1285267192.74.0.813927105785.issue9930@psf.upfronthosting.co.za>


New submission from Mark Shannon <marks at dcs.gla.ac.uk>:

Attached program fails.
See comments in file for details and possible diagnosis

----------
files: binary_op_mimic.py
messages: 117216
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Incorrect semantics of __radd__ method for builtin types
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file18981/binary_op_mimic.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9930>
_______________________________________

From report at bugs.python.org  Thu Sep 23 22:27:12 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 23 Sep 2010 20:27:12 +0000
Subject: [New-bugs-announce] [issue9931] test_ttk_guionly hangs on XP5
In-Reply-To: <1285273632.39.0.298869124825.issue9931@psf.upfronthosting.co.za>
Message-ID: <1285273632.39.0.298869124825.issue9931@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

test_ttk_guionly hangs on x86 XP5 buldbot.
But it doesn't hang on test_tk. Former shows
widget but latter doesn't on my machine.

http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/1348/steps/test/logs/stdio

----------
components: Tests, Tkinter, Windows
messages: 117230
nosy: ocean-city
priority: normal
severity: normal
status: open
title: test_ttk_guionly hangs on XP5
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9931>
_______________________________________

From report at bugs.python.org  Thu Sep 23 22:39:08 2010
From: report at bugs.python.org (Adam Nemecek)
Date: Thu, 23 Sep 2010 20:39:08 +0000
Subject: [New-bugs-announce] [issue9932] List of sets initialization
	behavior problems
In-Reply-To: <1285274348.08.0.841759888392.issue9932@psf.upfronthosting.co.za>
Message-ID: <1285274348.08.0.841759888392.issue9932@psf.upfronthosting.co.za>


New submission from Adam Nemecek <adamnemecek at gmail.com>:

I'm not sure if this is the intended behavior, but it seems unusual to me.
a = [set([]) for i in range(2)] evaluates to a list [set([]),set([])] and
b= 2*[set([])] evaluates to [set([]),set([])].
Nothing wrong here. 
Nevertheless, if I do a[0].add(1), a has the value [set([1]), set([])] but  b[0].add(1) evaluates to [set([1]), set([1])]. 
I understand that in list b, all of the sets refer to the same object in memory, nevertheless, I do not feel like this is the correct behavior.

----------
components: None
messages: 117231
nosy: adamnemecek
priority: normal
severity: normal
status: open
title: List of sets initialization behavior problems
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9932>
_______________________________________

From report at bugs.python.org  Fri Sep 24 01:48:35 2010
From: report at bugs.python.org (Kamil Kisiel)
Date: Thu, 23 Sep 2010 23:48:35 +0000
Subject: [New-bugs-announce] [issue9933] os module does not have the
	documented EX_NOTFOUND	attribute
In-Reply-To: <1285285715.98.0.332304645374.issue9933@psf.upfronthosting.co.za>
Message-ID: <1285285715.98.0.332304645374.issue9933@psf.upfronthosting.co.za>


New submission from Kamil Kisiel <kisielk at users.sourceforge.net>:

The library documentation (http://docs.python.org/library/os.html) states:

"""
os.EX_NOTFOUND
Exit code that means something like ?an entry was not found?.

Availability: Unix.

New in version 2.3.
"""

However, on both my Linux and OS X installs of OS X this happens:

python
Python 2.6.2 (r262:71600, Oct 24 2009, 03:15:21) 
[GCC 4.4.1 [gcc-4_4-branch revision 150839]] on linux2
Type "help", "copyright", "credits" or "license" for more information.
im>>> import os
>>> os.EX_NOTFOUND
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'EX_NOTFOUND'
>>> 


Unfortunately I don't have another Python version available to test with at the moment so I'm not sure if this affects other versions as well.

----------
components: Library (Lib)
messages: 117245
nosy: kisielk
priority: normal
severity: normal
status: open
title: os module does not have the documented EX_NOTFOUND attribute
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9933>
_______________________________________

From report at bugs.python.org  Fri Sep 24 02:02:08 2010
From: report at bugs.python.org (Retro)
Date: Fri, 24 Sep 2010 00:02:08 +0000
Subject: [New-bugs-announce] [issue9934] Python Docs Typo
In-Reply-To: <1285286528.33.0.133742788875.issue9934@psf.upfronthosting.co.za>
Message-ID: <1285286528.33.0.133742788875.issue9934@psf.upfronthosting.co.za>


New submission from Retro <vinetouu at gmail.com>:

http://docs.python.org/distutils/sourcedist.html#manifest-related-options

Please visit the above link and note the typo in:
-o is a sortcut for --manifest-only.

Should be:
-o is a shortcut for --manifest-only.

The word "sortcut" is a typo. Please fix it to "shortcut". Thanks.

----------
assignee: docs at python
components: Documentation
messages: 117248
nosy: Retro, docs at python
priority: normal
severity: normal
status: open
title: Python Docs Typo
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9934>
_______________________________________

From report at bugs.python.org  Fri Sep 24 03:07:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Sep 2010 01:07:04 +0000
Subject: [New-bugs-announce] [issue9935] Faster pickling of instances
In-Reply-To: <1285290424.33.0.0824621979691.issue9935@psf.upfronthosting.co.za>
Message-ID: <1285290424.33.0.0824621979691.issue9935@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is a bunch of assorted optimizations which make pickling of user-defined classes quite a bit faster.

Example on a minimal instance:

$ python -m timeit -s "import pickle; import collections, __main__; __main__.X=type('X', (), {}); x=X()" "pickle.dumps(x)"
-> before: 100000 loops, best of 3: 8.11 usec per loop
-> after: 100000 loops, best of 3: 2.95 usec per loop

Example on a namedtuple:

$ python -m timeit -s "import pickle; import collections, __main__; __main__.X=collections.namedtuple('X', 'a'); x=X(5)" "pickle.dumps(x)"
-> before: 100000 loops, best of 3: 9.52 usec per loop
-> after: 100000 loops, best of 3: 3.78 usec per loop

Unladen Swallow's pickling benchmark:

### pickle ###
Min: 0.792903 -> 0.704288: 1.1258x faster
Avg: 0.796241 -> 0.706073: 1.1277x faster
Significant (t=39.374217)
Stddev: 0.00410 -> 0.00307: 1.3342x smaller
Timeline: http://tinyurl.com/38elzvv

----------
components: Library (Lib)
files: pickleinst.patch
keywords: patch
messages: 117253
nosy: alexandre.vassalotti, belopolsky, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Faster pickling of instances
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file18986/pickleinst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9935>
_______________________________________

From report at bugs.python.org  Fri Sep 24 04:55:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 24 Sep 2010 02:55:55 +0000
Subject: [New-bugs-announce] [issue9936] trace misreports "missing" lines
In-Reply-To: <1285296955.25.0.310844622187.issue9936@psf.upfronthosting.co.za>
Message-ID: <1285296955.25.0.310844622187.issue9936@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

With the attached traceme.py, 


$ python -m trace -m -s -c  traceme.py
lines   cov%   module   (path)
    2    50%   traceme   (traceme.py)
$ cat traceme.cover 
       x = (1,
>>>>>>      2,
    1:      3)

This is wrong because all lines in traceme.py are executed.

----------
files: traceme.py
messages: 117257
nosy: belopolsky
priority: normal
severity: normal
status: open
title: trace misreports "missing" lines
Added file: http://bugs.python.org/file18990/traceme.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9936>
_______________________________________

From report at bugs.python.org  Fri Sep 24 11:17:17 2010
From: report at bugs.python.org (Iwasa Kazmi)
Date: Fri, 24 Sep 2010 09:17:17 +0000
Subject: [New-bugs-announce] [issue9937] _winreg.EnumValue causes MemoryError
In-Reply-To: <1285319837.21.0.430903654303.issue9937@psf.upfronthosting.co.za>
Message-ID: <1285319837.21.0.430903654303.issue9937@psf.upfronthosting.co.za>


New submission from Iwasa Kazmi <kzmizzz at gmail.com>:

_winreg.EnumValue causes MemoryError if the name of the value contains multibyte unicode characters.

I'm using 2.6.6.
I think it is relevant to Isssue #2810.

----------
components: Windows
messages: 117264
nosy: kzmi
priority: normal
severity: normal
status: open
title: _winreg.EnumValue causes MemoryError
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9937>
_______________________________________

From report at bugs.python.org  Fri Sep 24 16:31:30 2010
From: report at bugs.python.org (Jay T)
Date: Fri, 24 Sep 2010 14:31:30 +0000
Subject: [New-bugs-announce] [issue9938] Documentation for argparse
	interactive use
In-Reply-To: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za>
Message-ID: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za>


New submission from Jay T <jaytula at gmail.com>:

I want to create a custom interactive shell where I continually do 
parse_args.  Like the following: 
parser = argparse.ArgumentParser() 
command = raw_input() 
while(True): 
  args = parser.parse_args(shlex.split(command)) 
  # Do some magic stuff 
  command = raw_input() 
The problem is that if I give it invalid input, it errors and exits 
with a help message.

I learned from argparse-users group that you can override the exit method like the following:

class MyParser(ArgumentParser): 
  def exit(self, status=0, message=None): 
    # do whatever you want here 

I would be nice to have this usage documented perhaps along with best practices for doing help messages in this scenario.

----------
assignee: docs at python
components: Documentation
messages: 117287
nosy: docs at python, jayt
priority: normal
severity: normal
status: open
title: Documentation for argparse interactive use
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9938>
_______________________________________

From report at bugs.python.org  Fri Sep 24 17:19:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Sep 2010 15:19:22 +0000
Subject: [New-bugs-announce] [issue9939] Add a pipe type (FIFO) to the io
	module
In-Reply-To: <1285341562.44.0.992846065146.issue9939@psf.upfronthosting.co.za>
Message-ID: <1285341562.44.0.992846065146.issue9939@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

While writing tests for nntplib, it came to me that a PipeIO or BytesPipeIO would be useful (I actually wrote a minimal one). It would be a non-seekable in-memory bytes buffer with distinct read and write pointers, so as to act like a system FIFO or a socket.makefile() object. A pure Python implementation would probably be sufficient, since the main use would be for test purposes. What do you think?

(you may point to os.pipe() but it has problems such as limited buffer size: try to write many bytes to the write end and it will block until the other end tries to read something)

----------
components: Library (Lib)
messages: 117292
nosy: benjamin.peterson, pitrou, stutzbach
priority: normal
severity: normal
status: open
title: Add a pipe type (FIFO) to the io module
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9939>
_______________________________________

From report at bugs.python.org  Fri Sep 24 17:41:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Sep 2010 15:41:56 +0000
Subject: [New-bugs-announce] [issue9940] Strange error reporting with "with"
	statement
In-Reply-To: <1285342916.31.0.472051249531.issue9940@psf.upfronthosting.co.za>
Message-ID: <1285342916.31.0.472051249531.issue9940@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Under 3.2 and 3.1:

>>> with open("foo", "wb") as x: pass
... 
>>> with open("foo", "wb") as (x, y): pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
io.UnsupportedOperation: read

Similar oddities under 2.7:

>>> with open("foo", "wb") as (x, y): pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: File not open for reading
>>> with io.open("foo", "wb") as (x, y): pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
io.UnsupportedOperation: read

----------
components: Interpreter Core, Library (Lib)
messages: 117299
nosy: benjamin.peterson, pitrou, stutzbach
priority: normal
severity: normal
status: open
title: Strange error reporting with "with" statement
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9940>
_______________________________________

From report at bugs.python.org  Fri Sep 24 18:57:48 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 24 Sep 2010 16:57:48 +0000
Subject: [New-bugs-announce] [issue9941] Unify trace and profile interfaces
In-Reply-To: <1285347468.19.0.483467963743.issue9941@psf.upfronthosting.co.za>
Message-ID: <1285347468.19.0.483467963743.issue9941@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

The trace and profile modules provide similar functionality, but have some gratuitous differences in their APIs and command line interfaces.

For example, the method to trace a single call is Trace.runfunc, but almost identical Profile method is called "runcall".

The CLIs provided by the two modules are vastly different: profile splits out formatting of the results into a separate module, pstats, while trace module includes many options to control the output of traced runs.

This situation leeds to an unnecessary burden on users who need to learn two different ways to do very similar things.

----------
assignee: belopolsky
components: Library (Lib)
messages: 117309
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: Unify trace and profile interfaces
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9941>
_______________________________________

From report at bugs.python.org  Fri Sep 24 19:52:39 2010
From: report at bugs.python.org (Kevin Hunter)
Date: Fri, 24 Sep 2010 17:52:39 +0000
Subject: [New-bugs-announce] [issue9942] Allow memory sections to be OS
	MERGEABLE
In-Reply-To: <1285350759.4.0.118127426287.issue9942@psf.upfronthosting.co.za>
Message-ID: <1285350759.4.0.118127426287.issue9942@psf.upfronthosting.co.za>


New submission from Kevin Hunter <hunteke at earlham.edu>:

Should Python enable a way for folks to inform the OS of MADV_MERGEABLE memory?

I can't speak for other OSs, but Linux added the ability for processes to inform the kernel that they have memory that will likely not change for a while in 2.6.32.  This is done through the madvise syscall with MADV_MERGEABLE.

http://www.kernel.org/doc/Documentation/vm/ksm.txt

After initial conversations in IRC, it was suggested that this would be difficult in the Python layer, but that the OS doesn't care what byte page it's passed as "mergeable".  Thus when I, as an application programmer, know that I have some objects that will be around "for awhile", and that won't change, I can let the OS know that it might be beneficial to merge them.

I suggest this might be a library because it may only be useful for certain projects.

----------
components: Library (Lib)
messages: 117317
nosy: hunteke
priority: normal
severity: normal
status: open
title: Allow memory sections to be OS MERGEABLE
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9942>
_______________________________________

From report at bugs.python.org  Fri Sep 24 21:44:19 2010
From: report at bugs.python.org (Geoffrey Bache)
Date: Fri, 24 Sep 2010 19:44:19 +0000
Subject: [New-bugs-announce] [issue9943] TypeError message became less
	helpful in Python 2.7
In-Reply-To: <1285357459.53.0.518722150406.issue9943@psf.upfronthosting.co.za>
Message-ID: <1285357459.53.0.518722150406.issue9943@psf.upfronthosting.co.za>


New submission from Geoffrey Bache <gjb1002 at users.sourceforge.net>:

Consider the following code:

### keywords.py

def f(**kw):
    print arg, kw

f("hello", keyword=True)

and compare the behaviour in Python 2.6 and Python 2.7:

$ python keywords.py 
Traceback (most recent call last):
  File "keywords.py", line 5, in <module>
    f("hello", keyword=True)
TypeError: f() takes exactly 0 non-keyword arguments (1 given)

$ python2.7 keywords.py
Traceback (most recent call last):
  File "keywords.py", line 5, in <module>
    f("hello", keyword=True)
TypeError: f() takes exactly 0 arguments (2 given)

The error message from 2.6 is I would say a more accurate description of the situation.

----------
components: Interpreter Core
messages: 117327
nosy: gjb1002
priority: normal
severity: normal
status: open
title: TypeError message became less helpful in Python 2.7
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9943>
_______________________________________

From report at bugs.python.org  Sat Sep 25 00:15:44 2010
From: report at bugs.python.org (Jon Clements)
Date: Fri, 24 Sep 2010 22:15:44 +0000
Subject: [New-bugs-announce] [issue9944] Typo in doc for itertools recipe of
	consume
In-Reply-To: <1285366544.01.0.313980902629.issue9944@psf.upfronthosting.co.za>
Message-ID: <1285366544.01.0.313980902629.issue9944@psf.upfronthosting.co.za>


New submission from Jon Clements <joncle at googlemail.com>:

Very low priority.

def consume(iterator, n):
    "Advance the iterator n-steps ahead. If n is none, consume entirely."
    # Use functions that consume iterators at C speed.
    if n is None:
        # feed the entire iterator into a zero-length deque
        collections.deque(iterator, maxlen=0)
    else:
        # advance to the emtpy slice starting at position n
        next(islice(iterator, n, n), None)

Hardly a show stoppper, and not me worth submitting a patch, but "emtpy" should be "empty". Just thought I'd make note of it before I forgot.

----------
assignee: docs at python
components: Documentation
messages: 117339
nosy: docs at python, joncle
priority: normal
severity: normal
status: open
title: Typo in doc for itertools recipe of consume
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9944>
_______________________________________

From report at bugs.python.org  Sat Sep 25 15:27:33 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Sat, 25 Sep 2010 13:27:33 +0000
Subject: [New-bugs-announce] [issue9945] Improper locking in logging
In-Reply-To: <1285421253.55.0.777992318976.issue9945@psf.upfronthosting.co.za>
Message-ID: <1285421253.55.0.777992318976.issue9945@psf.upfronthosting.co.za>


New submission from Armin Ronacher <armin.ronacher at active-4.com>:

I found a a useless lock acquiring in the 27 maintenance branch in logging and a missing one as well:

Logger.removeHandler() locks around a handler lock, however the code executed in this lock is not depending on anything of that lock.  However there is a race condition when two pieces of code try to remove the same handler at the same time because between the if and the remove() no locking takes place.

I would recommend this instead (and also add locking to the addHandler):

    def addHandler(self, hdlr):
        """
        Add the specified handler to this logger.
        """
        _acquireLock()
        try:
            if hdlr not in self.handlers:
                self.handlers.append(hdlr)
        finally:
            _releaseLock()

    def removeHandler(self, hdlr):
        """
        Remove the specified handler from this logger.
        """
        _acquireLock()
        try:
            if hdlr in self.handlers:
                self.handlers.remove(hdlr)
        finally:
            _releaseLock()

I suppose in 3.x there might be something similar.

----------
assignee: vinay.sajip
components: Library (Lib)
messages: 117364
nosy: aronacher, vinay.sajip
priority: normal
severity: normal
status: open
title: Improper locking in logging
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9945>
_______________________________________

From report at bugs.python.org  Sat Sep 25 15:58:38 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 25 Sep 2010 13:58:38 +0000
Subject: [New-bugs-announce] [issue9946] lock use in logging
In-Reply-To: <1285423118.6.0.459283406836.issue9946@psf.upfronthosting.co.za>
Message-ID: <1285423118.6.0.459283406836.issue9946@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

>From logging.Logger:

    def removeHandler(self, hdlr):
        """
        Remove the specified handler from this logger.
        """
        if hdlr in self.handlers:
            hdlr.acquire()
            try:
                self.handlers.remove(hdlr)
            finally:
                hdlr.release()

I don't see what the use is for locking the handler.  The only shared resource that is accessed is self.handlers, which is not locked by the handler lock.

----------
assignee: vinay.sajip
components: Library (Lib)
keywords: easy
messages: 117368
nosy: georg.brandl, vinay.sajip
priority: normal
severity: normal
status: open
title: lock use in logging
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9946>
_______________________________________

From report at bugs.python.org  Sat Sep 25 16:17:40 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Sat, 25 Sep 2010 14:17:40 +0000
Subject: [New-bugs-announce] [issue9947] Weird locking in logging config
	system
In-Reply-To: <1285424260.64.0.915728022787.issue9947@psf.upfronthosting.co.za>
Message-ID: <1285424260.64.0.915728022787.issue9947@psf.upfronthosting.co.za>


New submission from Armin Ronacher <armin.ronacher at active-4.com>:

Another case of improper locking in logging.  The stopListening() method of the logging config acquires the logging lock, but it doesn't do it early enough.  In order for this function to be thread safe it would have to lock before the if.

Currently that lock used is useless because it locks assigning to a single attribute assignment and a global assignment that is never checked to existence besides the stopListening() function.

The attached patch proposes moving the lock before the if to make it threadsafe, but in all fairness sake that method is probably never executed from more than one thread.

----------
assignee: vinay.sajip
files: logging-config-threadsafety.patch
keywords: patch
messages: 117370
nosy: aronacher, vinay.sajip
priority: normal
severity: normal
status: open
title: Weird locking in logging config system
versions: Python 2.7
Added file: http://bugs.python.org/file19007/logging-config-threadsafety.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9947>
_______________________________________

From report at bugs.python.org  Sat Sep 25 16:32:30 2010
From: report at bugs.python.org (Armin Ronacher)
Date: Sat, 25 Sep 2010 14:32:30 +0000
Subject: [New-bugs-announce] [issue9948] findCaller is slow and loses case
	information on Windows
In-Reply-To: <1285425150.17.0.662006958911.issue9948@psf.upfronthosting.co.za>
Message-ID: <1285425150.17.0.662006958911.issue9948@psf.upfronthosting.co.za>


New submission from Armin Ronacher <armin.ronacher at active-4.com>:

findCaller() on loses case information on the files on Windows and has in general a really bad performance.  The attached patch does not depend on filename comparisions and instead compares the object identity of the caller's global namespace against the one from the logging module.

----------
assignee: vinay.sajip
components: Library (Lib)
files: find-caller.patch
keywords: patch
messages: 117373
nosy: aronacher, vinay.sajip
priority: normal
severity: normal
status: open
title: findCaller is slow and loses case information on Windows
versions: Python 2.7
Added file: http://bugs.python.org/file19008/find-caller.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9948>
_______________________________________

From report at bugs.python.org  Sat Sep 25 17:03:14 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 25 Sep 2010 15:03:14 +0000
Subject: [New-bugs-announce] [issue9949] os.path.realpath on Windows does
	not follow symbolic links
In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za>
Message-ID: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

In Lib/ntpath.py:

# realpath is a no-op on systems without islink support
realpath = abspath


However, Windows Vista and newer support symbolic links and other Python methods support them.

(noticed this through source code inspection; haven't actually tested it)

----------
components: Library (Lib)
messages: 117374
nosy: brian.curtin, eric.smith, jaraco, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: os.path.realpath on Windows does not follow symbolic links
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9949>
_______________________________________

From report at bugs.python.org  Sat Sep 25 21:07:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Sep 2010 19:07:48 +0000
Subject: [New-bugs-announce] [issue9950] socket.sendall() crash when
	receiving a signal
In-Reply-To: <1285441668.88.0.256888401487.issue9950@psf.upfronthosting.co.za>
Message-ID: <1285441668.88.0.256888401487.issue9950@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This was introduced by r74426 which addressed issue1628205. socket.sendall() calls PyErr_CheckSignals() (and potentially returns to the caller) without having the GIL.

>>> import socket
>>> c, s = socket.socketpair()
>>> s.sendall(b"x"*(100 * 1024**2))
^C^CFatal Python error: PyThreadState_Get: no current thread

----------
components: Library (Lib)
messages: 117385
nosy: gregory.p.smith, pitrou
priority: normal
severity: normal
status: open
title: socket.sendall() crash when receiving a signal
type: crash
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9950>
_______________________________________

From report at bugs.python.org  Sun Sep 26 01:38:48 2010
From: report at bugs.python.org (Arnon Yaari)
Date: Sat, 25 Sep 2010 23:38:48 +0000
Subject: [New-bugs-announce] [issue9951] introduce bytes.hex method
In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za>
Message-ID: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za>


New submission from Arnon Yaari <wiggin15 at gmail.com>:

Following up on these discussions:
http://psf.upfronthosting.co.za/roundup/tracker/issue3532
http://www.gossamer-threads.com/lists/python/dev/863892

I'm submitting a patch to add bytes.hex method in accordance to PEP 358.
The code was taken from binascii so it should be "tested".
Also added bytearray.hex and fixed the documentation and testing.

There are additional things to discuss, for example:
* multiple and different implementations of tohex\fromhex - in binascii, sha1module, bytes, bytearray...
* binascii's functions which perform the same thing, but those functions and the rest of binascii's functions receive and return wrong types. I would fix this but it breaks compatibility.

----------
components: Interpreter Core
files: bytes.hex.diff
keywords: patch
messages: 117397
nosy: wiggin15
priority: normal
severity: normal
status: open
title: introduce bytes.hex method
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19018/bytes.hex.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9951>
_______________________________________

From report at bugs.python.org  Sun Sep 26 13:03:00 2010
From: report at bugs.python.org (Martin Rinehart)
Date: Sun, 26 Sep 2010 11:03:00 +0000
Subject: [New-bugs-announce] [issue9952] Martin Rinehart wants to stay in
	touch on LinkedIn
In-Reply-To: <139977402.6246160.1285498974918.JavaMail.app@ech3-cdn11.prod>
Message-ID: <139977402.6246160.1285498974918.JavaMail.app@ech3-cdn11.prod>


New submission from Martin Rinehart <MartinRinehart at gmail.com>:

LinkedIn
------------

I'd like to add you to my professional network on LinkedIn.

- Martin Rinehart

Martin Rinehart
Student at Strayer Online
Greater New York City Area

Confirm that you know Martin Rinehart
https://www.linkedin.com/e/-3qcne3-gejswd6s-6f/isd/1711537782/WJZqc_fZ/

----------
files: unnamed
messages: 117410
nosy: MartinRinehart
priority: normal
severity: normal
status: open
title: Martin Rinehart wants to stay in touch on LinkedIn
Added file: http://bugs.python.org/file19023/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9952>
_______________________________________
-------------- next part --------------

<html>
  <body>

  

<table border="0" width="550" cellpadding="0" cellspacing="0" style="max-width:550px; border-top:4px solid #39C; font: 12px arial, sans-serif; margin: 0 auto;"><tr><td>  
  <h1 style="color: #000; font: bold 23px arial; margin:5px 0;" >LinkedIn</h1>

<div style="font:13px arial, sans-serif; width:540px">  
    
    <p>
      I'd like to add you to my professional network on LinkedIn.<br/>
<br/>
- Martin Rinehart
    </p>
    
    <table cellpadding="0" cellspacing="0" style="margin-bottom: 10px;">
      <tr>
        <td style="font: 13px arial, sans-serif; width: 490px;">
          <div style="padding: 5px 5px 5px 0">
            Martin Rinehart<br>
                  Student at Strayer Online
            <br>
                  Greater New York City Area
          </div>
          </div>
        </td>
      </tr>
    </table>

    <p>
              <a style="background-color:#ffcc00; display:inline-block; border-right: 1px solid #7a5a20; border-bottom: 1px solid #7a5a20; padding:10px; text-decoration: none; color: #000; text-align: center; white-space:none; font-weight: bold;" href="https://www.linkedin.com/e/-3qcne3-gejswd6s-6f/isd/1711537782/WJZqc_fZ/EML-invg_59/">Confirm that you know Martin</a>
    </p>
</div>



  <p style="width: 550px; margin: 3px auto; font: 10px arial, sans-serif; color: #999;">&#169; 2010, LinkedIn Corporation</p>
<img src="http://www.linkedin.com/emimp/-3qcne3-gejswd6s-6f.gif" style="width:1px; height:1px;"/></body>
</html>

From report at bugs.python.org  Sun Sep 26 15:52:52 2010
From: report at bugs.python.org (yuri)
Date: Sun, 26 Sep 2010 13:52:52 +0000
Subject: [New-bugs-announce] [issue9953] 2 scripts running from crontab
	simultaneously reference	the same instance of a variable
In-Reply-To: <1285509172.89.0.598446218983.issue9953@psf.upfronthosting.co.za>
Message-ID: <1285509172.89.0.598446218983.issue9953@psf.upfronthosting.co.za>


New submission from yuri <toozik at gmail.com>:

Originally the problem was that one script used a logger instance initialized in another script, and, as a result, log entries were "signed" by the later one.

Setup: python 3.1.1, Suse Linux enterprise server 9

2 scripts are scheduled in crontab as follows:
*/1 * * * * /my_path/python/test1.py > /dev/null 2>&1
*/1 * * * * /my_path/python/test2.py > /dev/null 2>&1

Each script does:
1) gets a logger instance and adds FileHandler, 
2) prints to its log the current time and PID, 
3) prints ID of the logger instance, 
4) prints ID and value of some variable
5) sleeps for 3 sec, 
6) prints the current time again.

Result: each script prints the same IDs of the variables

test1.py
______________________________
#!/usr/local/bin/python3
import logging
from logging import FileHandler
from datetime import datetime
import time
import os
import sys
log = logging.getLogger('MyLog1')
log.setLevel(logging.INFO)
logFilePath = os.path.join(os.path.realpath(os.path.dirname(sys.argv[0])), 'log')
dh = FileHandler(os.path.join(logFilePath, 'log1'))
log.addHandler(dh)
someVariable = 9
log.info(str(datetime.now()) + ' PID=' + str(os.getpid()))
log.info('logger ID=' + str(id(log)))
log.info('someVariable ID=' + str(id(someVariable)) + 'value=' + str(someVariable))
time.sleep(3)
log.info(str(datetime.now()) + ' PID=' + str(os.getpid()))

test2.py:
_________________________________
#!/usr/local/bin/python3
import logging
from logging import FileHandler
from datetime import datetime
import time
import os
import sys
log = logging.getLogger('MyLog2')
log.setLevel(logging.INFO)
logFilePath = os.path.join(os.path.realpath(os.path.dirname(sys.argv[0])), 'log')
dh = FileHandler(os.path.join(logFilePath, 'log2'))
log.addHandler(dh)
someVariable = 10
log.info(str(datetime.now()) + ' PID=' + str(os.getpid()))
log.info('logger ID=' + str(id(log)))
log.info('someVariable ID=' + str(id(someVariable)) + 'value=' + str(someVariable))
time.sleep(3)
log.info(str(datetime.now()) + ' PID=' + str(os.getpid()))

Result:

log1:
2010-09-26 15:45:01.531460 PID=5704
logger ID=182908380624
someVariable ID=7167488value=9
2010-09-26 15:45:04.535591 PID=5704

log2:
2010-09-26 15:45:01.528691 PID=5705
logger ID=182908380624
someVariable ID=7167520value=10
2010-09-26 15:45:04.534598 PID=5705

If I change value of someVariable to 9 in the both scripts, I have:

log1:
2010-09-26 15:48:01.488008 PID=6036
logger ID=182908380624
someVariable ID=7167488value=9
2010-09-26 15:48:04.491977 PID=6036

log2:
2010-09-26 15:48:01.490214 PID=6035
logger ID=182908380624
someVariable ID=7167488value=9
2010-09-26 15:48:04.494991 PID=6035

----------
components: Interpreter Core
messages: 117416
nosy: yuri
priority: normal
severity: normal
status: open
title: 2 scripts running from crontab simultaneously reference the same instance of a variable
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9953>
_______________________________________

From report at bugs.python.org  Sun Sep 26 16:32:26 2010
From: report at bugs.python.org (Dan L)
Date: Sun, 26 Sep 2010 14:32:26 +0000
Subject: [New-bugs-announce] [issue9954] include sqlite3.exe in
	PythonXX/Scripts
In-Reply-To: <1285511546.38.0.691891047401.issue9954@psf.upfronthosting.co.za>
Message-ID: <1285511546.38.0.691891047401.issue9954@psf.upfronthosting.co.za>


New submission from Dan L <choralreef at naver.com>:

since sqlite3 is included in the standard library, it would be useful to have access to the command line tool that's part of sqlite.  Including the command-line binary for each respective OS in the respective Scripts or bin folder would allow python users to create a connection in order to examine their sqlite databases and perform some manual operations easily.  While the tool isn't in python, it's not that big of a file and such a tool is a pretty fundamental part of having a database(miniaturized or not).

----------
components: Library (Lib)
messages: 117418
nosy: jdan
priority: normal
severity: normal
status: open
title: include sqlite3.exe in PythonXX/Scripts
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9954>
_______________________________________

From report at bugs.python.org  Sun Sep 26 21:01:35 2010
From: report at bugs.python.org (Zbynek Winkler)
Date: Sun, 26 Sep 2010 19:01:35 +0000
Subject: [New-bugs-announce] [issue9955] multiprocessing.Pipe segmentation
	fault when recv of	unpicklable object
In-Reply-To: <1285527695.71.0.573625122377.issue9955@psf.upfronthosting.co.za>
Message-ID: <1285527695.71.0.573625122377.issue9955@psf.upfronthosting.co.za>


New submission from Zbynek Winkler <zbynek.winkler at gmail.com>:

$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from lxml import etree
>>> from pickle import dumps
>>> from multiprocessing import Pipe
>>> n = etree.Element('new')
>>> dumps(n)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/pickle.py", line 1366, in dumps
    Pickler(file, protocol).dump(obj)
  File "/usr/lib/python2.6/pickle.py", line 224, in dump
    self.save(obj)
  File "/usr/lib/python2.6/pickle.py", line 306, in save
    rv = reduce(self.proto)
  File "/usr/lib/python2.6/copy_reg.py", line 70, in _reduce_ex
    raise TypeError, "can't pickle %s objects" % base.__name__
TypeError: can't pickle _Element objects
>>> p1, p2 = Pipe()
>>> p1.send(n)
>>> p2.recv()
Segmentation fault

----------
components: Library (Lib)
messages: 117427
nosy: Zbynek.Winkler
priority: normal
severity: normal
status: open
title: multiprocessing.Pipe segmentation fault when recv of unpicklable object
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9955>
_______________________________________

From report at bugs.python.org  Mon Sep 27 01:44:29 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sun, 26 Sep 2010 23:44:29 +0000
Subject: [New-bugs-announce] [issue9956] memoryview type documentation lacks
	versionadded
In-Reply-To: <1285544669.44.0.903225365456.issue9956@psf.upfronthosting.co.za>
Message-ID: <1285544669.44.0.903225365456.issue9956@psf.upfronthosting.co.za>


New submission from Andreas St?hrk <andy-python at hammerhartes.de>:

Title says all, attached is a patch against trunk (2.7). I'm not familiar with what version is correct for the Python 3 documentation.

----------
assignee: docs at python
components: Documentation
files: stdtypes-memoryview-2.7.patch
keywords: patch
messages: 117432
nosy: Trundle, docs at python, pitrou
priority: normal
severity: normal
status: open
title: memoryview type documentation lacks versionadded
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file19025/stdtypes-memoryview-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9956>
_______________________________________

From report at bugs.python.org  Mon Sep 27 04:02:31 2010
From: report at bugs.python.org (Ryan Kelly)
Date: Mon, 27 Sep 2010 02:02:31 +0000
Subject: [New-bugs-announce] [issue9957] SpooledTemporayFile.truncate should
	take size parameter
In-Reply-To: <1285552951.71.0.864499786785.issue9957@psf.upfronthosting.co.za>
Message-ID: <1285552951.71.0.864499786785.issue9957@psf.upfronthosting.co.za>


New submission from Ryan Kelly <ryan at rfk.id.au>:

Both file.truncate() and StringIO.truncate() accept an optional "size" parameter to truncate the file to a specific size.  SpooledTemporaryFile should accept a similar parameter and pass it on.

The only tricky part is that truncate can potentially increase the size of a file, so it needs to check the max size and rollover if appropriate.

Patch is against py3k branch; should work on trunk modulo the use of b"xxx" in the tests.

----------
components: Library (Lib)
files: spooledtemporaryfile_truncate.patch
keywords: patch
messages: 117436
nosy: rfk
priority: normal
severity: normal
status: open
title: SpooledTemporayFile.truncate should take size parameter
type: behavior
Added file: http://bugs.python.org/file19027/spooledtemporaryfile_truncate.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9957>
_______________________________________

From report at bugs.python.org  Mon Sep 27 14:25:44 2010
From: report at bugs.python.org (Valentin Kuznetsov)
Date: Mon, 27 Sep 2010 12:25:44 +0000
Subject: [New-bugs-announce] [issue9958] (c)elementTree missing children
In-Reply-To: <1285590344.49.0.534410398751.issue9958@psf.upfronthosting.co.za>
Message-ID: <1285590344.49.0.534410398751.issue9958@psf.upfronthosting.co.za>


New submission from Valentin Kuznetsov <vkuznet at gmail.com>:

Hi, I found that parsing XML file with identical structure leads to missing children item at some point. In my test case which I attach it happens at id=183. Basically I have XML with bunch of elements of the following structure:

<processed_dataset id='0'>
        <path dataset_path='/aaa/0'/>
</processed_dataset>
<processed_dataset id='1'>
        <path dataset_path='/aaa/0'/>
</processed_dataset>
....

when I parse them recursively, all, except the one with id=183, are parsed identically. The one with id=183 does not contain children. I tried the code with python 2.6 and python 2.7 on Mac and Linux. Bug exists in both version of ElementTree and cElementTree. Code and testbed XML are attached. Please untar and run as python test_bug.py.
Thanks,
Valentin

----------
files: em_bug.tar
messages: 117440
nosy: vkuznet
priority: normal
severity: normal
status: open
title: (c)elementTree missing children
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file19028/em_bug.tar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9958>
_______________________________________

From report at bugs.python.org  Mon Sep 27 15:23:04 2010
From: report at bugs.python.org (akira)
Date: Mon, 27 Sep 2010 13:23:04 +0000
Subject: [New-bugs-announce] [issue9959] int(math.log(4,
	2)) == 1 instead of 2
In-Reply-To: <1285593784.18.0.168096323949.issue9959@psf.upfronthosting.co.za>
Message-ID: <1285593784.18.0.168096323949.issue9959@psf.upfronthosting.co.za>


New submission from akira <4kir4.1i at gmail.com>:

$ python3.1 -c'import math; f = math.log(4,2); print(int(f), f.as_integer_ratio())'
2 (2, 1)

$ python3.2 -c'import math; f = math.log(4,2); print(int(f), f.as_integer_ratio())'
1 (9007199254740991, 4503599627370496)

Python 3.2a2+ (py3k:85028, Sep 27 2010, 16:46:11) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> f = math.log(32, 2)
>>> f
4.999999999999999
>>> int(f)
4
>>> f.as_integer_ratio()
(5629499534213119, 1125899906842624)

I'm not sure whether it is a bug, but it is an unexpected change in behavior between 3.1 and 3.2.

----------
components: Library (Lib)
messages: 117444
nosy: akira
priority: normal
severity: normal
status: open
title: int(math.log(4,2)) == 1 instead of 2
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9959>
_______________________________________

From report at bugs.python.org  Mon Sep 27 17:11:36 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 27 Sep 2010 15:11:36 +0000
Subject: [New-bugs-announce] [issue9960] test_structmembers fails on s390x
	(bigendian 64-bit):	int/Py_ssize_t issue
In-Reply-To: <1285600296.08.0.731959847047.issue9960@psf.upfronthosting.co.za>
Message-ID: <1285600296.08.0.731959847047.issue9960@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

test test_structmembers crashed -- <type 'exceptions.ValueError'>:
string too long
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-2.7/Lib/test/regrtest.py", line 863, in runtest_inner
    the_package = __import__(abstest, globals(), locals(), [])
  File "/builddir/build/BUILD/Python-2.7/Lib/test/test_structmembers.py", line 12, in <module>
    9.99999, 10.1010101010, "hi")
ValueError: string too long

_testcapimodule.c: test_structmembers_new's fmt has:
  "s#"
and these args:
  &s, &string_len

for grabbing this data:
    const char *s = NULL;
    Py_ssize_t string_len = 0;

However, the module doesn't define PY_SSIZE_T_CLEAN, which leads to &string_len being treated as an (int*) rather than a (Py_ssize_t*) and thus written to with just the first 32-bits of the size, rather than the full size.

The PyArgs_ call without PY_SSIZE_T_CLEAN writes the size of the string (2) through (int*)&string_len, writing 0x00000002 to the first 4 bytes, setting the 64-bit "string_len" value to 0x0000000200000000 i.e. 2^34, wildly too large for the iirc 5 byte buffer.

Confirmed in gdb:
  (gdb) p string_len
  $2 = 8589934592

  (gdb) p /x string_len
  $3 = 0x200000000

Am attaching a patch (against 2.7 maintenance branch) which defines PY_SSIZE_T_CLEAN; doing so requires updating another int to be a Py_ssize_t in that module, within test_u_code.


http://docs.python.org/c-api/arg.html lists "u# (Unicode) [Py_UNICODE *, int]" and has no reference to the effect of PY_SSIZE_T_CLEAN on the "u#" format specifier.  My reading of Python/getargs.c is that this macro does affect "u#" in a manner analogous to "s#"; does this documentation need clarifying?

----------
components: Tests
files: python-test_structmembers.patch
keywords: easy, patch
messages: 117448
nosy: dmalcolm
priority: normal
severity: normal
stage: patch review
status: open
title: test_structmembers fails on s390x (bigendian 64-bit): int/Py_ssize_t issue
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file19029/python-test_structmembers.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9960>
_______________________________________

From report at bugs.python.org  Mon Sep 27 17:30:23 2010
From: report at bugs.python.org (Bill Hawkes)
Date: Mon, 27 Sep 2010 15:30:23 +0000
Subject: [New-bugs-announce] [issue9961] Identity Crisis! variable
	assignment using strftime fails	comparison test.
In-Reply-To: <1285601423.86.0.66942906829.issue9961@psf.upfronthosting.co.za>
Message-ID: <1285601423.86.0.66942906829.issue9961@psf.upfronthosting.co.za>


New submission from Bill Hawkes <williamhawkesjr at yahoo.com>:

See below. When variable assignment is used with strftime for the day of the week, it fails comparison checks for the days of the week. Even when using the str() function it still fails. Manual entry of variable assignment is required for a successful comparison. This pretty well defeats the purpose of computer programming (automation). There seems to be a real identity crisis here!

$ python3
Python 3.0rc1+ (py3k, Oct 28 2008, 09:23:29) 
[GCC 4.3.2] on linux2
>>> import time
>>> from datetime import date
>>> today = date.today()
>>> print("This line will always print")
This line will always print
>>> myday = today.fromordinal(today.toordinal() - 31)
>>> printthis = myday.strftime("%m-%d-%y. %d %b %Y is a %A on the %d day of %B.")
>>> print("%s" % printthis)
08-27-10. 27 Aug 2010 is a Friday on the 27 day of August.
>>> # dow is Day Of Week variable
... dow = myday.strftime("%A")
>>> chkval = dow
>>> dow is chkval
True
>>> print("dow is %s" % dow)
dow is Friday
>>> print("chkval is %s" % chkval)
chkval is Friday
>>> print("%s" % dow)
Friday
>>> print("%s" % chkval)
Friday
>>> dow is chkval
True
>>> if dow is 'Sunday':
...    cntbck = 0
... elif dow is 'Monday':
...    cntbck = 1
... elif dow is 'Tuesday':
...    cntbck = 2
... elif dow is 'Wednesday':
...    cntbck = 3
... elif dow is 'Thursday':
...    cntbck = 4
... elif dow is 'Friday':
...    cntbck = 5
... elif dow is 'Saturday':
...    cntbck = 6
... else:
...    cntbck = 'undefined'
...    print("What day is it? It is %s" % dow)
... 
What day is it? It is Friday
>>> print('finished with script')
finished with script
>>> dow is 'Friday'
False
>>> dow = 'Friday'
>>> dow is 'Friday'
True
>>> chkval
'Friday'
>>> dow
'Friday'
>>> chkval is dow
False
>>>  chkval is 'Friday'
False
>>> chkval
'Friday'
>>> chkval = str(chkval)
>>> chkval
'Friday'
>>> chkval is 'Friday'
False
>>> cntbck
'undefined'
>>>

----------
components: Interpreter Core
messages: 117449
nosy: BillHawkes
priority: normal
severity: normal
status: open
title: Identity Crisis! variable assignment using strftime fails comparison test.
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9961>
_______________________________________

From report at bugs.python.org  Mon Sep 27 23:38:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 27 Sep 2010 21:38:35 +0000
Subject: [New-bugs-announce] [issue9962] GzipFile doesn't have peek()
In-Reply-To: <1285623515.75.0.317234760361.issue9962@psf.upfronthosting.co.za>
Message-ID: <1285623515.75.0.317234760361.issue9962@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

GzipFile claims to implement BufferedIOBase but doesn't have peek().

----------
components: Library (Lib)
messages: 117476
nosy: nirai, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: GzipFile doesn't have peek()
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9962>
_______________________________________

From report at bugs.python.org  Tue Sep 28 00:26:35 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 Sep 2010 22:26:35 +0000
Subject: [New-bugs-announce] [issue9963] test_sysconfig when LDFLAGS defined
	in the user's	environment
In-Reply-To: <1285626395.1.0.70736928165.issue9963@psf.upfronthosting.co.za>
Message-ID: <1285626395.1.0.70736928165.issue9963@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

test_sysconfig.test_ldshared_value is failing for me on Mac because my LDFLAGS environment variable is being defined twice in what sysconfig.get_config_var('LDFLAGS') returns. This fails in a comparison against sysconfig.get_config_var('LDSHARED') as the values are only set once::

AssertionError: '-L/Users/brett/.slash/_/lib -L/Users/brett/.local/lib  -L/Users/brett/.slash/_/lib -L/Users/brett/.local/lib' not found in 'clang  -L/Users/brett/.slash/_/lib -L/Users/brett/.local/lib -bundle -undefined dynamic_lookup'

I suspect what is happening is sysconfig is using PY_LDFLAGS, which uses both CONFIGURE_LDFLAGS *and* LDFLAGS when the Makefile is run. This leads to LDFLAGS being set twice if it was pulled from the user's environment variable

----------
components: Library (Lib)
messages: 117484
nosy: brett.cannon
priority: deferred blocker
severity: normal
stage: needs patch
status: open
title: test_sysconfig when LDFLAGS defined in the user's environment
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9963>
_______________________________________

From report at bugs.python.org  Tue Sep 28 00:27:00 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 27 Sep 2010 22:27:00 +0000
Subject: [New-bugs-announce] [issue9964] Test failures with -OO
In-Reply-To: <1285626420.9.0.187351711939.issue9964@psf.upfronthosting.co.za>
Message-ID: <1285626420.9.0.187351711939.issue9964@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

When I run the test suite (py3k branch) with -OO I get 42 failures. Most of these look like they are caused by the same (or a similar) problem (attempting to run doctests from now-non-existent docstrings).

The tests that fail are:

When I run with -OO I get 42 test failures. Most of them look like they are due to missing docstrings but some are likely to be due to missing asserts.

42 tests failed:
    test_bisect test_cmd test_code test_collections test_compileall
    test_ctypes test_decimal test_deque test_descrtut test_dictcomps
    test_difflib test_dis test_distutils test_doctest test_extcall
    test_generators test_genexps test_getopt test_http_cookies
    test_import test_itertools test_json test_lib2to3 test_listcomps
    test_math test_metaclass test_pdb test_pickle test_pickletools
    test_pyclbr test_setcomps test_syntax test_threading_local
    test_tokenize test_unpack test_unpack_ex test_urllib2 test_weakref
    test_xml_etree test_xml_etree_c test_zipimport
    test_zipimport_support

Typical tracebacks (one explicitly calling doctest code, the other through test.support):

Traceback (most recent call last):
  File "Lib/test/test_collections.py", line 3, in <module>
    import unittest, doctest, operator
  File "/compile/py3k/Lib/doctest.py", line 97, in <module>
    import unittest, difflib, pdb, tempfile
  File "/compile/py3k/Lib/pdb.py", line 1348, in <module>
    __doc__ += getattr(Pdb, 'do_' + _command).__doc__.strip() + '\n\n'
AttributeError: 'NoneType' object has no attribute 'strip'

Traceback (most recent call last):
  File "Lib/test/test_code.py", line 169, in <module>
    test_main()
  File "Lib/test/test_code.py", line 164, in test_main
    run_doctest(test_code, verbose)
  File "/compile/py3k/Lib/test/support.py", line 1142, in run_doctest
    import doctest
  File "/compile/py3k/Lib/doctest.py", line 97, in <module>
    import unittest, difflib, pdb, tempfile
  File "/compile/py3k/Lib/pdb.py", line 1348, in <module>
    __doc__ += getattr(Pdb, 'do_' + _command).__doc__.strip() + '\n\n'
AttributeError: 'NoneType' object has no attribute 'strip'


Issue 6292 was previously closed when all tests ran successfully with -OO, so this is a more recent regression.

----------
components: Tests
messages: 117485
nosy: michael.foord, r.david.murray
priority: normal
severity: normal
status: open
title: Test failures with -OO
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9964>
_______________________________________

From report at bugs.python.org  Tue Sep 28 02:07:48 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 28 Sep 2010 00:07:48 +0000
Subject: [New-bugs-announce] [issue9965] Loading malicious pickle may cause
	excessive memory usage
In-Reply-To: <1285632468.19.0.235987005106.issue9965@psf.upfronthosting.co.za>
Message-ID: <1285632468.19.0.235987005106.issue9965@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti <alexandre at peadrop.com>:

This was mentioned during the review of issue #9410
(http://codereview.appspot.com/1694050/diff/2001/3001#newcode347), however we forgot to fix this.

The new array-based memo for the Unpickler class assumes incorrectly that memo indices are always contiguous. This is not the case. And due to this, the following pickle will cause Unpickler to use about 3GB of memory to store the memo array.

./python -c "import pickle; pickle.loads(b'\x80\x02]r\xff\xff\xff\x06.')"

To fix this, we can add code to fall-back to a dictionary-based memo when the memo keys are not contiguous.

----------
components: Extension Modules
messages: 117492
nosy: alexandre.vassalotti
priority: critical
severity: normal
stage: needs patch
status: open
title: Loading malicious pickle may cause excessive memory usage
type: security
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9965>
_______________________________________

From report at bugs.python.org  Tue Sep 28 02:34:45 2010
From: report at bugs.python.org (Florent Gallaire)
Date: Tue, 28 Sep 2010 00:34:45 +0000
Subject: [New-bugs-announce] [issue9966] platform : a boolean to know easily
	when a system is posix
In-Reply-To: <1285634085.25.0.52252512228.issue9966@psf.upfronthosting.co.za>
Message-ID: <1285634085.25.0.52252512228.issue9966@psf.upfronthosting.co.za>


New submission from Florent Gallaire <fgallaire at gmail.com>:

Hi,

The platform module could provide a boolean to know easily if a system is posix or not.

The expected result, when the system is posix :

>>> import platform
>>> platform.isposix
True

otherwise :

>>> import platform
>>> platform.isposix
False

Here is a patch to do so. It also provides an update for the platform
documentation and a test case.

Best regards

Florent Gallaire

----------
components: Library (Lib)
files: platform_isposix_boolean.py
messages: 117495
nosy: fgallaire
priority: normal
severity: normal
status: open
title: platform : a boolean to know easily when a system is posix
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file19039/platform_isposix_boolean.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9966>
_______________________________________

From report at bugs.python.org  Tue Sep 28 03:57:46 2010
From: report at bugs.python.org (Tokio Kikuchi)
Date: Tue, 28 Sep 2010 01:57:46 +0000
Subject: [New-bugs-announce] [issue9967] encoded_word regular expression
	in	email.header.decode_header()
In-Reply-To: <1285639066.52.0.877288279278.issue9967@psf.upfronthosting.co.za>
Message-ID: <1285639066.52.0.877288279278.issue9967@psf.upfronthosting.co.za>


New submission from Tokio Kikuchi <tkikuchi at users.sourceforge.net>:

Regular expression ecre for RFC2047 encoded_word in email.header module have bugs:

1. encoded_word should be separated by SPACEs in both leading and trailing ends.  Current expression take care only trailing end.

2. encoded_text in the third part of encoded_word should not include literal ? or SPACE.

Also, ecre should not match against multiline.

The patch includes two test cases for test/test_email.py

----------
components: Library (Lib)
files: email_header_ecrefix.patch
keywords: patch
messages: 117500
nosy: tkikuchi
priority: normal
severity: normal
status: open
title: encoded_word regular expression in email.header.decode_header()
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file19041/email_header_ecrefix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9967>
_______________________________________

From report at bugs.python.org  Tue Sep 28 13:58:16 2010
From: report at bugs.python.org (phep)
Date: Tue, 28 Sep 2010 11:58:16 +0000
Subject: [New-bugs-announce] [issue9968] Let cgi.FieldStorage have named
	uploaded file
In-Reply-To: <1285675096.14.0.24974141754.issue9968@psf.upfronthosting.co.za>
Message-ID: <1285675096.14.0.24974141754.issue9968@psf.upfronthosting.co.za>


New submission from phep <patrice.pillot at teletopie.net>:

Hi,

Presently, in cgi.FieldStorage, uploaded file are accessible through a file-like object created by a call to tempfile.TemporaryFile(), probably in order to ensure the file is deleted when the process terminates.

The problem is that when one wants to save the data to some permanent location, one does not have other choice thant read() from this file descriptor then write() to the desired place, which means the file data shall be duplicated. This is greatly undesirable when the uploaded file is huge.

Replacing the call to tempfile.TemporaryFile() by a call to tempfile.NamedTemporaryFile() (available from 2.3) would have the following advantages :
1) no impact on existing code,
2) saving a file would be as simple as invoking os.link(fieldstorage['filenamefield'].file.name, "/some/path")
3) There would be no need to duplicate data anymore.

The sole real inconvenience of this change would be to update the documentation accordingly.

tia,

phep

----------
components: Extension Modules
messages: 117512
nosy: phep
priority: normal
severity: normal
status: open
title: Let cgi.FieldStorage have named uploaded file
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9968>
_______________________________________

From report at bugs.python.org  Tue Sep 28 15:17:19 2010
From: report at bugs.python.org (Meador Inge)
Date: Tue, 28 Sep 2010 13:17:19 +0000
Subject: [New-bugs-announce] [issue9969] tokenize: add support for
	tokenizing 'str' objects
In-Reply-To: <1285679839.5.0.180278126855.issue9969@psf.upfronthosting.co.za>
Message-ID: <1285679839.5.0.180278126855.issue9969@psf.upfronthosting.co.za>


New submission from Meador Inge <meadori at gmail.com>:

Currently with 'py3k' only 'bytes' objects are accepted for tokenization:

>>> import io
>>> import tokenize
>>> tokenize.tokenize(io.StringIO("1+1").readline)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/minge/Code/python/py3k/Lib/tokenize.py", line 360, in tokenize
    encoding, consumed = detect_encoding(readline)
  File "/Users/minge/Code/python/py3k/Lib/tokenize.py", line 316, in detect_encoding
    if first.startswith(BOM_UTF8):
TypeError: Can't convert 'bytes' object to str implicitly
>>> tokenize.tokenize(io.BytesIO(b"1+1").readline)
<generator object _tokenize at 0x1007566e0>

In a discussion on python-dev (http://www.mail-archive.com/python-dev at python.org/msg52107.html) it was generally considered to be a good idea to add support for tokenizing 'str' objects as well.

----------
messages: 117516
nosy: meador.inge
priority: normal
severity: normal
stage: needs patch
status: open
title: tokenize: add support for tokenizing 'str' objects
type: feature request
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9969>
_______________________________________

From report at bugs.python.org  Tue Sep 28 15:22:00 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 28 Sep 2010 13:22:00 +0000
Subject: [New-bugs-announce] [issue9970] PyMemoryView_FromBuffer is not
	documented
In-Reply-To: <1285680120.22.0.180975662294.issue9970@psf.upfronthosting.co.za>
Message-ID: <1285680120.22.0.180975662294.issue9970@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

PyMemoryView_FromBuffer() in Include/memoryobject.h is undocumented.

The function name seems to indicate that it intended to be a public API.

----------
assignee: docs at python
components: Documentation
messages: 117518
nosy: docs at python, ronaldoussoren
priority: normal
severity: normal
status: open
title: PyMemoryView_FromBuffer is not documented
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9970>
_______________________________________

From report at bugs.python.org  Tue Sep 28 17:19:02 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 28 Sep 2010 15:19:02 +0000
Subject: [New-bugs-announce] [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

The readinto() method is intended to offer better performance than read() by allowing the caller to read into a preallocated buffer rather than constantly allocate and deallocate buffers.

However, bufferediobase_readinto() calls read(), so the extra allocations and deallocations happen anyway.  On a related note, buffered_readinto() has a comment reading "TODO: use raw.readinto() instead!" which should be explored.

I can write a patch for this, but it will probably be awhile before I get to it.  Anyone else who feels inspired should feel free to write one. :-)

----------
assignee: stutzbach
components: IO
messages: 117530
nosy: benjamin.peterson, pitrou, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: Optimize BufferedReader.readinto
type: performance
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Tue Sep 28 17:22:20 2010
From: report at bugs.python.org (Lisandro Dalcin)
Date: Tue, 28 Sep 2010 15:22:20 +0000
Subject: [New-bugs-announce] [issue9972] PyGILState_XXX missing in Python
	builds without threads
In-Reply-To: <1285687340.14.0.296693885275.issue9972@psf.upfronthosting.co.za>
Message-ID: <1285687340.14.0.296693885275.issue9972@psf.upfronthosting.co.za>


New submission from Lisandro Dalcin <dalcinl at gmail.com>:

I've built Python-2.6.5 form with this :

$ ./configure --without-threads --prefix=$HOME/python-without-threads
$ make && make install

$ cd ~/python-without-threads/lib
$ nm libpython2.6.so | grep PyGILState
$ 

At Include/pystate.h,  PyGILState_{Ensure|Release} are not protected with #ifdef WITH_THREADS

At Python/pystate.c PyGILState_{Ensure|Release} are implemented in a block protected with #ifdef WITH_THREADS

AFAIK, this happens in all Python versions back to 2.3 and up to 3.2

----------
messages: 117531
nosy: dalcinl
priority: normal
severity: normal
status: open
title: PyGILState_XXX missing in Python builds without threads
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9972>
_______________________________________

From report at bugs.python.org  Tue Sep 28 18:34:20 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 28 Sep 2010 16:34:20 +0000
Subject: [New-bugs-announce] [issue9973] Sometimes buildbot fails to cleanup
	working copy
In-Reply-To: <1285691660.36.0.731785440446.issue9973@psf.upfronthosting.co.za>
Message-ID: <1285691660.36.0.731785440446.issue9973@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Sometimes, buildbot fails to clean working copy.

/////////////////////////////////////////////

(snip)
Clean started: Project: _hashlib, Configuration: Debug|Win32
Deleting intermediate and output files for project '_hashlib', configuration 'Debug|Win32'
_hashlib : error PRJ0008 : Could not delete file 'c:\buildslave\2.7.moore-windows\build\PCbuild\_hashlib_d.pyd'.
Make sure that the file is not open by another process and is not write-protected.
_hashlib - 1 error(s), 0 warning(s)

Build complete: 8 Projects succeeded, 17 Projects failed, 1 Projects skipped

/////////////////////////////////////////////

This might cause checkout error next time. Maybe attached
patch can improve this situation. Thanks.

----------
components: Tests
files: py3k_buildbot_error_in_clean_faze.patch
keywords: buildbot, patch
messages: 117536
nosy: ocean-city
priority: normal
severity: normal
status: open
title: Sometimes buildbot fails to cleanup working copy
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19047/py3k_buildbot_error_in_clean_faze.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9973>
_______________________________________

From report at bugs.python.org  Tue Sep 28 19:31:05 2010
From: report at bugs.python.org (=?utf-8?q?Brian_Boss=C3=A9?=)
Date: Tue, 28 Sep 2010 17:31:05 +0000
Subject: [New-bugs-announce] [issue9974] tokenizer.untokenize not invariant
	with line continuations
In-Reply-To: <1285695065.99.0.439423855227.issue9974@psf.upfronthosting.co.za>
Message-ID: <1285695065.99.0.439423855227.issue9974@psf.upfronthosting.co.za>


New submission from Brian Boss? <penrif at gmail.com>:

Executing the following code against a py file which contains line continuations generates an assert:
import tokenize
foofile = open(filename, "r")
tokenize.untokenize(list(tokenize.generate_tokens(foofile.readline)))

(note, the list() is important due to issue #8478)

The assert triggered is:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\lib\tokenize.py", line 262, in untokenize
    return ut.untokenize(iterable)
  File "C:\Python27\lib\tokenize.py", line 198, in untokenize
    self.add_whitespace(start)
  File "C:\Python27\lib\tokenize.py", line 187, in add_whitespace
    assert row <= self.prev_row
AssertionError

I have tested this in 2.6.5, 2.7 and 3.1.2.  The line numbers may differ but the stack is otherwise identical between these versions.

Example input code:
foo = \
   3

If the assert is removed, the code generated is still incorrect.  For example, the input:
foo = 3
if foo == 5 or \
   foo == 1
    pass

becomes:
foo = 3
if foo == 5 orfoo == 1
    pass

which besides not having the line continuation, is functionally incorrect.

I'm wrapping my head around the functionality of this module and am willing to do the legwork to get a fix in.  Ideas on how to go about it are more than welcome.

Ironic aside:  this bug is present when tokenize.py itself is used as input.

----------
components: Library (Lib)
messages: 117538
nosy: Brian.Boss?
priority: normal
severity: normal
status: open
title: tokenizer.untokenize not invariant with line continuations
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9974>
_______________________________________

From report at bugs.python.org  Tue Sep 28 20:35:46 2010
From: report at bugs.python.org (Vilmos Nebehaj)
Date: Tue, 28 Sep 2010 18:35:46 +0000
Subject: [New-bugs-announce] [issue9975] Incorrect use of flowinfo and
	scope_id in IPv6 sockaddr	tuple
In-Reply-To: <1285698946.58.0.377750793336.issue9975@psf.upfronthosting.co.za>
Message-ID: <1285698946.58.0.377750793336.issue9975@psf.upfronthosting.co.za>


New submission from Vilmos Nebehaj <v.nebehaj at gmail.com>:

Module/socketmodule.c incorrectly treats both sockaddr_in6->sin6_flowinfo and sockaddr_in6->sin6_scope_id as signed integers.  They are 32-bit unsigned integers (even though sin6_flowinfo is just 20 bits).

sin6_flowinfo also lacks the necessary endian conversions when an IPv6 sockaddr tuple is parsed or returned.  This makes it difficult to deal with sockets using sin6_flowinfo and deviates from RFCs.  With the use of a signed int it also makes impossible to use flowinfo values that are larger than 2^31 if converted to little endian byte order (socketmodule.c raising an overflow exception).

sin6_scope_id has meaning only on the local machine (as an interface index), thus no endian conversion is needed for it.

----------
components: Library (Lib)
files: python_flowinfo.patch
keywords: patch
messages: 117540
nosy: vnebehaj
priority: normal
severity: normal
status: open
title: Incorrect use of flowinfo and scope_id in IPv6 sockaddr tuple
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file19049/python_flowinfo.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9975>
_______________________________________

From report at bugs.python.org  Tue Sep 28 22:14:44 2010
From: report at bugs.python.org (Matthew Woodcraft)
Date: Tue, 28 Sep 2010 20:14:44 +0000
Subject: [New-bugs-announce] [issue9976] Make TestCase._formatMessage public
In-Reply-To: <1285704884.2.0.185747132173.issue9976@psf.upfronthosting.co.za>
Message-ID: <1285704884.2.0.185747132173.issue9976@psf.upfronthosting.co.za>


New submission from Matthew Woodcraft <matthew at woodcraft.me.uk>:

It would be pleasant if TestCase._formatMessage, or something similar,
could be made part of the documented API; I think pretty much anyone
writing a custom TypeEqualityFunc is going to end up reimplementing it.

(This is the code that makes the TestCase.longMessage attribute take
effect.)

----------
messages: 117543
nosy: mattheww, michael.foord
priority: normal
severity: normal
status: open
title: Make TestCase._formatMessage public
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9976>
_______________________________________

From report at bugs.python.org  Tue Sep 28 22:15:22 2010
From: report at bugs.python.org (Matthew Woodcraft)
Date: Tue, 28 Sep 2010 20:15:22 +0000
Subject: [New-bugs-announce] [issue9977] TestCase.assertItemsEqual's
	description of differences
In-Reply-To: <1285704922.32.0.659854668668.issue9977@psf.upfronthosting.co.za>
Message-ID: <1285704922.32.0.659854668668.issue9977@psf.upfronthosting.co.za>


New submission from Matthew Woodcraft <matthew at woodcraft.me.uk>:

TestCase.assertItemsEqual uses two different techniques to describe the
differences in the inputs that it compares.

If the inputs are sortable, it sorts them and then uses
assertSequenceEqual to describe the difference between them considered
as ordered sequences.

Otherwise, it uses unittest.util.unorderable_list_difference, which
is essentially a multiset comparison.

In practice, I think the output from unorderable_list_difference is
usually more readable, so I wonder if something of that kind should be
made the default.


Example:

a = [('b', (2, 3)), ('w', (3, 4))]
b = [('x', (2, 3)), ('w', (3, 4))]
case.assertItemsEqual(a, b)


unorderable_list_difference gives

Expected, but missing:
    [('b', (2, 3))]
Unexpected, but present:
    [('x', (2, 3))]


while the current assertItemsEqual gives

Sequences differ: [('b', (2, 3)), ('w', (3, 4))] != [('w', (3, 4)), ('x', (2, 3))]

First differing element 0:
('b', (2, 3))
('w', (3, 4))

- [('b', (2, 3)), ('w', (3, 4))]
+ [('w', (3, 4)), ('x', (2, 3))]


In general, I think that the 'first differing element' paragraph that
assertSequenceEqual produces is as likely to be misleading as it is to
be helpful (when we're really comparing unordered sequences).

----------
messages: 117545
nosy: mattheww, michael.foord
priority: normal
severity: normal
status: open
title: TestCase.assertItemsEqual's description of differences
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9977>
_______________________________________

From report at bugs.python.org  Wed Sep 29 01:14:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Sep 2010 23:14:00 +0000
Subject: [New-bugs-announce] [issue9978] test_os failures on XP-4 buildbot
In-Reply-To: <1285715640.05.0.77400346639.issue9978@psf.upfronthosting.co.za>
Message-ID: <1285715640.05.0.77400346639.issue9978@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This has started showing up since r85073.

======================================================================
ERROR: test_CTRL_BREAK_EVENT (test.test_os.Win32KillTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_os.py", line 1068, in test_CTRL_BREAK_EVENT
    self._kill_with_event(signal.CTRL_BREAK_EVENT, "CTRL_BREAK_EVENT")
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_os.py", line 1039, in _kill_with_event
    os.kill(proc.pid, event)
WindowsError: [Error 5] Access is denied

http://www.python.org/dev/buildbot/builders/x86%20XP-4%203.x

----------
components: Library (Lib), Tests, Windows
keywords: buildbot
messages: 117561
nosy: brian.curtin, ocean-city, pitrou, tim.golden
priority: normal
severity: normal
stage: needs patch
status: open
title: test_os failures on XP-4 buildbot
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9978>
_______________________________________

From report at bugs.python.org  Wed Sep 29 02:20:50 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Sep 2010 00:20:50 +0000
Subject: [New-bugs-announce] [issue9979] Create PyUnicode_AsWideCharString()
	function
In-Reply-To: <1285719650.86.0.122072445011.issue9979@psf.upfronthosting.co.za>
Message-ID: <1285719650.86.0.122072445011.issue9979@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

PyUnicode_AsWideChar() doesn't merge surrogate pairs on a system with 32 bits wchar_t and Python compiled in narrow mode (sizeof(wchar_t) == 4 and sizeof(Py_UNICODE) == 2) => see issue #8670.

It is not easy to fix this problem because the callers of PyUnicode_AsWideChar() suppose that the output (wide character) string has the same length (in character) than the input (PyUnicode) string (suppose that sizeof(wchar_t) == sizeof(Py_UNICODE)). And PyUnicode_AsWideChar() doesn't write nul character at the end if the output string is truncated.

To prepare this change, a new PyUnicode_AsWideCharString() function would help because it does compute the size of the output buffer (whereas PyUnicode_AsWideChar() requires the output buffer in an argument).

Attached patch implements it:
-------
/* Convert the Unicode object to a wide character string. The output string
   always ends with a nul character. If size is not NULL, write the number of
   wide characters (including the final nul character) into *size.

   Returns a buffer allocated by PyMem_Alloc() (use PyMem_Free() to free it) on
   success. On error, returns NULL and *size is undefined. */

PyAPI_FUNC(wchar_t*) PyUnicode_AsWideCharString(
    PyUnicodeObject *unicode,   /* Unicode object */
    Py_ssize_t *size            /* number of characters of the result */
    );
-------

----------
components: Interpreter Core, Unicode
files: pyunicode_aswidecharstring.patch
keywords: patch
messages: 117566
nosy: haypo
priority: normal
severity: normal
status: open
title: Create PyUnicode_AsWideCharString() function
versions: Python 3.2
Added file: http://bugs.python.org/file19054/pyunicode_aswidecharstring.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9979>
_______________________________________

From report at bugs.python.org  Wed Sep 29 05:11:32 2010
From: report at bugs.python.org (Kiriakos Vlahos)
Date: Wed, 29 Sep 2010 03:11:32 +0000
Subject: [New-bugs-announce] [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>


New submission from Kiriakos Vlahos <pyscripter at gmail.com>:

I am the author of PyScripter a popular python IDE (pyscripter.googlecode.com).  Following a user report I found out that str(float) occasionally produces wrong results with Python 2.7 and 3.1.

eg.
>>> str(38210.0)  //wrong
'3820:.0'
>>> str(37210.0) // correct
'37210.0'
>>> str(36210.0)  //wrong
'3620:.0'

This only happens with the embedded python engine which uses the pythonxx.dll of the official distribution.  It does not happen using the stand alone interpreter of the PyScripter remote engine.

The recent changes in Python 3.2a2 fix this issue.
Any ideas why the embedded Python would give different results from the stand alone interpreter?

----------
components: Interpreter Core, Windows
messages: 117574
nosy: Kiriakos.Vlahos
priority: normal
severity: normal
status: open
title: str(float) failure
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Wed Sep 29 08:28:38 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 29 Sep 2010 06:28:38 +0000
Subject: [New-bugs-announce] [issue9981] let make_buildinfo use a temporary
	directory on windows
In-Reply-To: <1285741718.07.0.0571419018875.issue9981@psf.upfronthosting.co.za>
Message-ID: <1285741718.07.0.0571419018875.issue9981@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

make_buildinfo currently creates temporary files getbuildinfo2.c and getbuildinfo.o in the current build directory.  This update allows the caller to specify a temp directory to put those files in.
The PCBuild pythoncore.vcproj now makes use of this, to put the.c and .o files in the current temporary directory $(IntDir).

This makes it possible to compile multiple project configurations in parallel, with tools such as incredibuild, without fearing that each will trample the other's getbuildinfo files.

Also removed an unnecessary 64 bit config for make_buildinfo.

----------
components: Interpreter Core
messages: 117576
nosy: krisvale
priority: normal
severity: normal
status: open
title: let make_buildinfo use a temporary directory on windows
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9981>
_______________________________________

From report at bugs.python.org  Wed Sep 29 10:40:27 2010
From: report at bugs.python.org (Marvin Mundry)
Date: Wed, 29 Sep 2010 08:40:27 +0000
Subject: [New-bugs-announce] [issue9982] Pointer problem in initializing
	array of arrays
In-Reply-To: <1285749627.74.0.65331145627.issue9982@psf.upfronthosting.co.za>
Message-ID: <1285749627.74.0.65331145627.issue9982@psf.upfronthosting.co.za>


New submission from Marvin Mundry <marvin.mun at gmx.de>:

>>> m1=[[0,0,0,0]]*4
>>> m1
[[0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0]]
>>> m1[0][0]+=1
>>> m1
[[1, 0, 0, 0], [1, 0, 0, 0], [1, 0, 0, 0], [1, 0, 0, 0]]

after initializing an array of arrays as done in the first line of the code snippet all elements in the array point to the same object in memory.

----------
components: None
messages: 117581
nosy: mastermarv
priority: normal
severity: normal
status: open
title: Pointer problem in initializing array of arrays
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9982>
_______________________________________

From report at bugs.python.org  Wed Sep 29 13:11:42 2010
From: report at bugs.python.org (david)
Date: Wed, 29 Sep 2010 11:11:42 +0000
Subject: [New-bugs-announce] [issue9983] please add a large NOTE explaining
	that urllib does not	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>


New submission from david <db.pub.mail at gmail.com>:

please add a large NOTE explaining that urllib does not perform any ssl validation.

----------
assignee: docs at python
components: Documentation
messages: 117596
nosy: db, docs at python
priority: normal
severity: normal
status: open
title: please add a large NOTE explaining that urllib does not perform any ssl validation
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9983>
_______________________________________

From report at bugs.python.org  Wed Sep 29 13:17:38 2010
From: report at bugs.python.org (david)
Date: Wed, 29 Sep 2010 11:17:38 +0000
Subject: [New-bugs-announce] [issue9984] please add a large NOTE explaining
	that urllib2 does not	perform any ssl validation
In-Reply-To: <1285759058.32.0.409782287474.issue9984@psf.upfronthosting.co.za>
Message-ID: <1285759058.32.0.409782287474.issue9984@psf.upfronthosting.co.za>


New submission from david <db.pub.mail at gmail.com>:

please add a large NOTE explaining that urllib2 does not perform any ssl (for https connection) validation out of the box. 
Also see 9983 for urrlib.

----------
messages: 117601
nosy: db
priority: normal
severity: normal
status: open
title: please add a large NOTE explaining that urllib2 does not perform any ssl validation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9984>
_______________________________________

From report at bugs.python.org  Wed Sep 29 16:32:19 2010
From: report at bugs.python.org (Marien Zwart)
Date: Wed, 29 Sep 2010 14:32:19 +0000
Subject: [New-bugs-announce] [issue9985] difflib.SequenceMatcher has
	slightly buggy and	undocumented caching behavior
In-Reply-To: <1285770739.15.0.805040100323.issue9985@psf.upfronthosting.co.za>
Message-ID: <1285770739.15.0.805040100323.issue9985@psf.upfronthosting.co.za>


New submission from Marien Zwart <m_zwart at 123mail.org>:

SequenceMatcher caches the result of get_matching_blocks and get_opcodes. There are some problems with this:

What get_matching_blocks caches is a list of tuples. The first call does not return that list: it returns map(Match._make, self.matching_blocks) (converting the tuples to namedtuples). Subsequent calls just return self.matching_blocks directly. Especially in python 3 and up this is weird, since the first call returns a map object while later calls return a list.

This caching behavior is not documented, so calling code may mutate the returned list. One example of calling code is difflib itself: get_grouped_opcodes mutates the result of get_opcodes (a cached list). I am not sure if the right fix is to have get_grouped_opcodes copy before it mutates or to have get_opcodes return a copy.

Snippet demonstrating both bugs:

matcher = difflib.SequenceMatcher(a='aaaaaaaabc', b='aaaaaaaadc')
print(list(matcher.get_matching_blocks()))
# This should print the same thing, but it does not:
print(list(matcher.get_matching_blocks()))

print(matcher.get_opcodes())
print(list(matcher.get_grouped_opcodes()))
# This should print the same thing as the previous get_opcodes()
# list, but it does not:
print(matcher.get_opcodes())

----------
components: Library (Lib)
messages: 117612
nosy: marienz
priority: normal
severity: normal
status: open
title: difflib.SequenceMatcher has slightly buggy and undocumented caching behavior
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9985>
_______________________________________

From report at bugs.python.org  Wed Sep 29 16:54:14 2010
From: report at bugs.python.org (Amber Jain)
Date: Wed, 29 Sep 2010 14:54:14 +0000
Subject: [New-bugs-announce] [issue9986] PDF files of python docs have text
	missing
In-Reply-To: <1285772054.59.0.857308007062.issue9986@psf.upfronthosting.co.za>
Message-ID: <1285772054.59.0.857308007062.issue9986@psf.upfronthosting.co.za>


New submission from Amber Jain <i.amber.jain at gmail.com>:

CC: docs at python.org

I was planning to print the official python "2.7" tutorial: http://docs.python.org/tutorial/index.html.
So, I went over to Download page: http://docs.python.org/download.html and downloaded the PDF file. But the PDF have some missing text due to width of page being less than number of chars to put on a line.
For example, please have a look at page-21 (Section 3.1.3 titled "Unicode Strings"). It has an incomplete line from HTML documentation.
Here's a screenshot of what I see (and mean):
http://amberj.devio.us/pub/screenshots/pdfdoc.png

There's a line somewhere in the middle of screenshot which goes out of boundary of PDF document and fails to put out-of-boundary text on newline.
>From what I had read, it seems that this happens only with 'code snippets' in tutorial. This is probably a problem with convertor (HTML to PDF?).

Can you guys please fix it?
Thanks a lot.

----------
components: None
messages: 117614
nosy: amberj
priority: normal
severity: normal
status: open
title: PDF files of python docs have text missing
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9986>
_______________________________________

From report at bugs.python.org  Wed Sep 29 18:09:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 16:09:23 +0000
Subject: [New-bugs-announce] [issue9987] usenetrc option broken
In-Reply-To: <1285776563.1.0.517353919652.issue9987@psf.upfronthosting.co.za>
Message-ID: <1285776563.1.0.517353919652.issue9987@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The nntplib cleanup broke the "usenetrc" option to NNTP:


Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_nntplib.py", line 167, in setUp
    self.server = NNTP(self.NNTP_HOST, timeout=TIMEOUT)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/nntplib.py", line 937, in __init__
    readermode, usenetrc, timeout)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/nntplib.py", line 329, in __init__
    auth = credentials.authenticators(host)
NameError: global name 'host' is not defined

----------
assignee: pitrou
components: Library (Lib)
messages: 117627
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: usenetrc option broken
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9987>
_______________________________________

From report at bugs.python.org  Wed Sep 29 19:23:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Sep 2010 17:23:23 +0000
Subject: [New-bugs-announce] [issue9988] test_warnings fails with
	PYTHONFSENCODING=latin-1 on	UNIX/BSD
In-Reply-To: <1285781003.02.0.409003653893.issue9988@psf.upfronthosting.co.za>
Message-ID: <1285781003.02.0.409003653893.issue9988@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

$ PYTHONFSENCODING=latin-1 ./python Lib/test/test_warnings.py 
...
======================================================================
FAIL: test_nonascii (__main__.CEnvironmentVariableTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_warnings.py", line 731, in test_nonascii
    "['ignore:Deprecaci?nWarning']".encode('utf-8'))
AssertionError: b"['ignore:Deprecaci\\udcf3nWarning']" != b"['ignore:Deprecaci\xc3\xb3nWarning']"

======================================================================
FAIL: test_nonascii (__main__.PyEnvironmentVariableTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_warnings.py", line 731, in test_nonascii
    "['ignore:Deprecaci?nWarning']".encode('utf-8'))
AssertionError: b"['ignore:Deprecaci\\udcf3nWarning']" != b"['ignore:Deprecaci\xc3\xb3nWarning']"

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

The problem is that subprocess encodes PYTHONWARNINGS environment variable value with the filesystem encoding, whereas Py_main() decodes the variable value with the locale encoding.

History of how the variable is read in py3k:
 - #7301: r79880 creates this variable, use mbstowcs() and PySys_AddWarnOption()
 - #7301: r80066 uses setlocale(LC_ALL, ""), and replaces mbstowcs() by _Py_char2wchar() (to support surrogates)
 - #8589: r81358 creates PySys_AddWarnOptionUnicode() and replaces _Py_char2wchar() by PyUnicode_DecodeFSDefault()
 - #8589: r84694 replaces PyUnicode_DecodeFSDefault() by _Py_char2wchar() + PyUnicode_FromWideChar() "because the PyCodec machinery is not ready yet"
 - #8589: r84731 uses PyUnicode_FromString() (utf-8) on Mac OS X

----------
components: Tests, Unicode
messages: 117631
nosy: haypo
priority: normal
severity: normal
status: open
title: test_warnings fails with PYTHONFSENCODING=latin-1 on UNIX/BSD
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9988>
_______________________________________

From report at bugs.python.org  Wed Sep 29 20:34:54 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 29 Sep 2010 18:34:54 +0000
Subject: [New-bugs-announce] [issue9989] ctypes bitfield problem
In-Reply-To: <1285785294.07.0.231109223206.issue9989@psf.upfronthosting.co.za>
Message-ID: <1285785294.07.0.231109223206.issue9989@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

The following program should print "0xdead" but instead prints "0x0".  This came from the following stackoverflow question:
http://stackoverflow.com/questions/3824617/python-structure-always-stuck-at-0-no-matter-what-value-you-assign-to-it

import ctypes
class Blah(ctypes.Structure):
    _fields_ = [("a", ctypes.c_uint64, 64),
                ("b", ctypes.c_uint16, 16),
                ("c", ctypes.c_uint8, 8),
                ("d", ctypes.c_uint8, 8)]

x = Blah(0xDEAD,0xBEEF,0x44,0x12)
print(hex(x.a))

----------
components: Library (Lib)
messages: 117637
nosy: stutzbach, theller
priority: normal
severity: normal
stage: unit test needed
status: open
title: ctypes bitfield problem
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9989>
_______________________________________

From report at bugs.python.org  Wed Sep 29 21:03:38 2010
From: report at bugs.python.org (Lenard Lindstrom)
Date: Wed, 29 Sep 2010 19:03:38 +0000
Subject: [New-bugs-announce] [issue9990] PyMemoryView_FromObject alters the
	Py_buffer after	calling PyObject_GetBuffer when ndim 1
In-Reply-To: <1285787018.03.0.476755592717.issue9990@psf.upfronthosting.co.za>
Message-ID: <1285787018.03.0.476755592717.issue9990@psf.upfronthosting.co.za>


New submission from Lenard Lindstrom <len-l at telus.net>:

If an exporter returns a Py_buffer with ndim 1, PyMemoryView_FromObject changes the shape and strides pointer fields to point to a local Py_buffer array field. This array field is undocumented. Any heap memory these pointers reference is lost. Should the exporter's bf_releasebuffer later try and free the memory, the Python interpreter may segfault.

Attached is a demonstration program. Its output is:

Accessing buffer directly...
Accessing buffer through a memory view...
* View->shape has changed.
Done.

where the third line shows bf_releasebuffer has detected a changed pointer.

----------
components: Interpreter Core
files: bufrel.c.gz
messages: 117644
nosy: kermode
priority: normal
severity: normal
status: open
title: PyMemoryView_FromObject alters the Py_buffer after calling PyObject_GetBuffer when ndim 1
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file19060/bufrel.c.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9990>
_______________________________________

From report at bugs.python.org  Thu Sep 30 00:15:34 2010
From: report at bugs.python.org (Jonathan Niehof)
Date: Wed, 29 Sep 2010 22:15:34 +0000
Subject: [New-bugs-announce] [issue9991] xmlrpc client ssl check faulty
In-Reply-To: <1285798534.22.0.74771320533.issue9991@psf.upfronthosting.co.za>
Message-ID: <1285798534.22.0.74771320533.issue9991@psf.upfronthosting.co.za>


New submission from Jonathan Niehof <jniehof at lanl.gov>:

This has been reported before (#6494, #7987) and closed as "You need to build Python with SSL support." However, this error is raised even if ssl support is included.

The SSL check in xmlrpc.client for Python 3.1 is:
if not hasattr(socket, "ssl")
but ssl was removed from socket and into its own class for Py3k. So one workaround, provided ssl support is available:

import socket
if not hasattr(socket, 'ssl')
    socket.ssl = None
import xmlrpc.client

at which point everything works fine.

The attached patch fixes the bug, checking for ssl support based on the existence of http.client.HTTPSConnection, which is similar to the check in Python 2.7.

----------
components: Library (Lib)
files: xmlrpc_client_ssl_check.patch
keywords: patch
messages: 117667
nosy: jniehof
priority: normal
severity: normal
status: open
title: xmlrpc client ssl check faulty
type: crash
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19061/xmlrpc_client_ssl_check.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9991>
_______________________________________

From report at bugs.python.org  Thu Sep 30 00:36:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Sep 2010 22:36:23 +0000
Subject: [New-bugs-announce] [issue9992] Command line arguments are not
	correctly decoded if	locale and fileystem encodings are different
In-Reply-To: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>
Message-ID: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

On UNIX/BSD systems, Python decodes arguments with the locale encoding, whereas subprocess encodes arguments with the fileystem encoding. If both encodings are differents, we have a problem.

There was already the issue #4388 but it was closed because it was specific to old versions of Mac OS X. With the PYTHONFSENCODING environment variable (added to Python 3.2), it is easy to trigger this issue: run Python with a filesystem encoding different than the locale encoding. Attached script demonstrates the bug.

--

I see two possible encodings to encode and decode command line arguments (with surrogateescape error handler):

 (a) filesystem encoding
 (b) locale encoding

Decode Python command line arguments is one of the first operation executed when running Python, in the main() function. We don't have import machinery or codec API available at this moment. So I don't see how we can use the filesystem encoding here. Read issue #9630 to see how complex it is to use the filesystem encoding when initializing Python.

Use the locale encoding is easier because we already have _Py_char2wchar() and _Py_wchar2char() functions to decode/encode with the locale encoding and the surrogateescape error handler. These functions use the wchar_t* type which is less pratical than PyUnicodeObject*, but it is an advantage because wchar_t* type doesn't need Python to be completly initialized (whereas some PyUnicode methods loads modules, eg. encode and decode).

In #8775, I proposed to create a new variable to store the "command line encoding": sys.getcmdlineencoding(). But this issue was closed because there was only one use case: #4388 (which was closed but not fixed).

I don't know, or don't really care, how sys.getcmdlineencoding() should be initialized. The important point is that we have to use the same encoding to decode and encode command line arguments.

--

I don't really know if using another encoding is the right solution. The problem is maybe that the filesystem encoding should not be controlable by the user?

And what about environment variables: should we continue to encode and decode them with the filesystem encoding, or should we use the new "command line encoding"?

----------
components: Interpreter Core, Unicode
files: locale_fs_encoding.py
messages: 117669
nosy: haypo
priority: normal
severity: normal
status: open
title: Command line arguments are not correctly decoded if locale and fileystem encodings are different
versions: Python 3.2
Added file: http://bugs.python.org/file19062/locale_fs_encoding.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Thu Sep 30 01:03:12 2010
From: report at bugs.python.org (Jonathan Niehof)
Date: Wed, 29 Sep 2010 23:03:12 +0000
Subject: [New-bugs-announce] [issue9993] shutil.move fails on symlink source
In-Reply-To: <1285801392.69.0.814963089991.issue9993@psf.upfronthosting.co.za>
Message-ID: <1285801392.69.0.814963089991.issue9993@psf.upfronthosting.co.za>


New submission from Jonathan Niehof <jniehof at lanl.gov>:

shutil.move does not behave as I expect when moving a symlink across filesystems. (This is when src itself is a symlink, not when it is a directory tree including symlinks.)

-If src is a symlink to file, rather than moving the symlink, it copies the contents of the file
-If src is a symlink to a directory, rather than moving the symlink, it copies the contents of the directory to a new directory
-If src is a dangling symlink, it errors out

Attached patch against the py3k branch adds tests for these cases and adds the expected behaviour, which is to recreate the symlink.

(I have encountered this on 2.6 - current SVN; it is probably in 2.5 as well but I have not confirmed.)

----------
components: Library (Lib)
files: shutil_move_symlinks.patch
keywords: patch
messages: 117673
nosy: jniehof
priority: normal
severity: normal
status: open
title: shutil.move fails on symlink source
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19063/shutil_move_symlinks.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9993>
_______________________________________

From report at bugs.python.org  Thu Sep 30 09:01:37 2010
From: report at bugs.python.org (David)
Date: Thu, 30 Sep 2010 07:01:37 +0000
Subject: [New-bugs-announce] [issue9994] Python becoming orphaned over ssh
In-Reply-To: <1285830097.12.0.730062200867.issue9994@psf.upfronthosting.co.za>
Message-ID: <1285830097.12.0.730062200867.issue9994@psf.upfronthosting.co.za>


New submission from David <wizzardx at gmail.com>:

Hi, I mentioned this on the mailing list over here:

http://mail.python.org/pipermail/python-list/2010-September/1256407.html

I think it's a Python bug, so reposting it here:

-------------
Hi there, I have a strange situation.

If I do this:

1. Make a script /tmp/test.py on a remote server, with this contents:

#!/usr/bin/python
from subprocess import check_call
check_call(['ping', 'www.google.com'])

2. Call the script like this over SSH:

ssh root at testbox /tmp/test.py

3. Interrupt the script with Ctrl+C.

Then what happens:

The SSH session terminates, as expected.

However:

On the testing box, the Python script is still running, and so is the
ping session.

However, if I make an equivalent shell script, /tmp/test.sh, with this contents:

#!/bin/bash
ping www.google.com

And then run it over ssh like this:

ssh root at testbox /tmp/test.sh

And then hit Ctrl+C, then the shell script and ping are both
interrupted remotely, as expected.

Here is how 'pstree -p' looks for the python script on the test box,
before Ctrl+C:

<init (1) up here>
??sshd(1158)???sshd(19756)???test.py(19797)???ping(19798)
?            ??sshd(20233)???bash(20269)???pstree(19875)

And after Ctrl+C:

<init (1) up here>
??sshd(1158)???sshd(20233)???bash(20269)???pstree(20218)
??test.py(19797)???ping(19798)

Basically, the server-side sshd sub-process has disconnected, but the
Python script (and it's ping subprocess) have become orphaned, and now
belong to the init process.

Note, this only seems to happen if Python is executing a subprocess,
and only while Python is being run through a non-interactive ssh
session.

How can I make Python behave better? I want it to close down itself
and it's subprocess, and not orphan itself when I hit ctrl+C

PS:

The Python version on the testing box: 2.6.4, and the box itself is
running Ubuntu Karmic. Also, it's not just ping, but other utilities,
eg wget.

PPS:

I did also try adding logic to the python script, to keep an eye on
all the ppids (parent, grandparent, etc), and then to interrupt itself
and kill it's subprocess, but that doesn't seem to work: For whatever
reason, Python seems to be unable to kill it's subprocess in this
situation. The Python process closes, and ping becomes a child of
init. But I can then kill ping manually, from a separate ssh session.
-------------

I've seen this in both Python 2.6 and Python 3.1.

----------
components: Library (Lib)
messages: 117700
nosy: wizzardx
priority: normal
severity: normal
status: open
title: Python becoming orphaned over ssh
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9994>
_______________________________________

From report at bugs.python.org  Thu Sep 30 11:27:22 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 30 Sep 2010 09:27:22 +0000
Subject: [New-bugs-announce] [issue9995] "setup.py register sdist upload"
	requires pass to be saved
In-Reply-To: <1285838842.84.0.5702466564.issue9995@psf.upfronthosting.co.za>
Message-ID: <1285838842.84.0.5702466564.issue9995@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

That's very annoying that distutils asks to save your pass when uploading to PyPI, but refuses to upload if you refuse. So you end up with storing your password in cleartext.

Try the next command to see what I mean:

setup.py register sdist upload

----------
assignee: tarek
components: Distutils
messages: 117713
nosy: eric.araujo, tarek, techtonik
priority: normal
severity: normal
status: open
title: "setup.py register sdist upload" requires pass to be saved
type: security
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9995>
_______________________________________

From report at bugs.python.org  Thu Sep 30 14:03:23 2010
From: report at bugs.python.org (Arnon Yaari)
Date: Thu, 30 Sep 2010 12:03:23 +0000
Subject: [New-bugs-announce] [issue9996] binascii should convert unicode
	strings
In-Reply-To: <1285848203.41.0.985893389249.issue9996@psf.upfronthosting.co.za>
Message-ID: <1285848203.41.0.985893389249.issue9996@psf.upfronthosting.co.za>


New submission from Arnon Yaari <wiggin15 at gmail.com>:

binascii is currently bytes-only, although the "a" in a2b\b2a should refer to unicode strings.
This patch fixes all a2b functions to take str type and all b2a functions to return str types.
This was discussed several times, for example:
http://www.gossamer-threads.com/lists/python/dev/863892
http://bugs.python.org/issue4770#msg78475
As discussed, the required behavior in Python 3k is that a2b should convert str to bytes and vice versa, and this was implemented in this patch.

This patch breaks backward compatibility in several functions... It also required fixing several files under Lib (although most cases were simplified), and also to change the interface of the base64 and quopri modules (this was also requested, e.g. http://bugs.python.org/issue4769).
Note that there already was a small change in this behavior from 3.1 to 3.2 (http://bugs.python.org/issue4770) - b2a_hex and b2a_qp COULD receive strings as input in 3.1 and this was changed in 3.2, so technically, compatibility was already broken...

The patch includes updates to the standard library, the tests and documentation.
rlecode and rledecode were left untouched because they are not a2b\b2a functions per se - they work on the input and output of the hqx functions (maybe it's a good idea to add new a2b\b2a functions for rle_hqx).

Any thoughts are welcome.

----------
components: Interpreter Core
files: binascii.diff
keywords: patch
messages: 117727
nosy: wiggin15
priority: normal
severity: normal
status: open
title: binascii should convert unicode strings
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19067/binascii.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9996>
_______________________________________

From report at bugs.python.org  Thu Sep 30 14:17:41 2010
From: report at bugs.python.org (Ivo van der Wijk)
Date: Thu, 30 Sep 2010 12:17:41 +0000
Subject: [New-bugs-announce] [issue9997] function named 'top' gets
	unexpected namespace/scope	behaviour
In-Reply-To: <1285849061.79.0.383989167237.issue9997@psf.upfronthosting.co.za>
Message-ID: <1285849061.79.0.383989167237.issue9997@psf.upfronthosting.co.za>


New submission from Ivo van der Wijk <python.org at in.m3r.nl>:

This issue is also discussed on Stackoverflow: http://stackoverflow.com/q/3828611/320057

The following code

def top(deck):
    pass

def b():
    global deck

results in the error "SyntaxError: name 'deck' is local and global" (slightly different for 3.x). This is strange by itself, and is caused by special namespace behaviour attached to the "top" symbol. Renaming the "top" function actually solves the error!

More technical details are in the stackoverflow link above.

----------
components: Interpreter Core
messages: 117731
nosy: iivvoo
priority: normal
severity: normal
status: open
title: function named 'top' gets unexpected namespace/scope behaviour
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9997>
_______________________________________

From report at bugs.python.org  Thu Sep 30 16:45:10 2010
From: report at bugs.python.org (Jonathan Niehof)
Date: Thu, 30 Sep 2010 14:45:10 +0000
Subject: [New-bugs-announce] [issue9998] find_library should search
	LD_LIBRARY_PATH on linux
In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za>
Message-ID: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za>


New submission from Jonathan Niehof <jniehof at lanl.gov>:

It's come up on occasion (#2936, http://osdir.com/ml/python.ctypes/2008-05/msg00046.html) that ctypes find_library doesn't search LD_LIBRARY_PATH for libraries, which is different behaviour from the runtime linker. The attached patch adds this search.

Unfortunately I can't conceive of a reasonable unit test for this (compiling a shared library in setUp seems a bit overkill.)

----------
assignee: theller
components: ctypes
files: ctypes_ld_lib_path.patch
keywords: patch
messages: 117738
nosy: jniehof, theller
priority: normal
severity: normal
status: open
title: find_library should search LD_LIBRARY_PATH on linux
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19068/ctypes_ld_lib_path.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9998>
_______________________________________

From report at bugs.python.org  Thu Sep 30 17:29:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 30 Sep 2010 15:29:10 +0000
Subject: [New-bugs-announce] [issue9999] test_shutil cross-file-system tests
	are fragile (may not	test what they pruport to test)
In-Reply-To: <1285860550.74.0.246130427134.issue9999@psf.upfronthosting.co.za>
Message-ID: <1285860550.74.0.246130427134.issue9999@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

In investigating issue 9993, I noticed that test_shutil wants to test things that require cross-file-system links, and arranges to have such links by creating a files and directories in the cwd and using tempfile.  Presumably the hope (and the comments make it clear it is a hope) is that frequently these will be different filesystems.  This is likely to be true on some systems (principally those that put /tmp on a memory file system), there is no guarantee that it is true for any system in the buildbot fleet (for example).

In addition, relatively recent changes to regrtest ensure that when the tests are run for an installed Python, the cwd is *guaranteed* to be in the same file system as things created by tempfile, since in that case the tempfile module is used by regrtest to run all tests in a temporary cwd.

It is this latter case that most concerns me and prompts this bug report, since a distribution should be able to reasonably expect that running the tests after installation (either real or sandboxed) should in fact test python on the target system.

Unfortunately I don't currently have a suggestion for how to reliably create a cross-file-system link for testing purposes.

----------
components: Tests
messages: 117744
nosy: r.david.murray, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_shutil cross-file-system tests are fragile (may not test what they pruport to test)
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9999>
_______________________________________

From report at bugs.python.org  Thu Sep 30 17:48:15 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 30 Sep 2010 15:48:15 +0000
Subject: [New-bugs-announce] [issue10000] mark more tests as CPython specific
In-Reply-To: <1285861695.5.0.301447830736.issue10000@psf.upfronthosting.co.za>
Message-ID: <1285861695.5.0.301447830736.issue10000@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

When porting pypy to 2.7, we found that many tests actually exercise features specific to CPython, either the garbage collector, or the precise memory layout (__sizeof__).
They should be marked as such, and skipped when run with pypy.

----------
messages: 117746
nosy: amaury.forgeotdarc
priority: normal
severity: normal
status: open
title: mark more tests as CPython specific

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10000>
_______________________________________

From report at bugs.python.org  Thu Sep 30 19:46:47 2010
From: report at bugs.python.org (Lenard Lindstrom)
Date: Thu, 30 Sep 2010 17:46:47 +0000
Subject: [New-bugs-announce] [issue10001] ~Py_buffer.obj field is
	undocumented, though not hidden
In-Reply-To: <1285868807.58.0.617972550499.issue10001@psf.upfronthosting.co.za>
Message-ID: <1285868807.58.0.617972550499.issue10001@psf.upfronthosting.co.za>


New submission from Lenard Lindstrom <len-l at telus.net>:

Python 3.2a2+ (py3k:85072M, Sep 29 2010, 12:11:17) (from SVN)
[GCC 4.4.5 20100728 (prerelease)] on linux2 (Debian squeeze)

The ~Py_buffer.obj field is undocumented. Yet memoryview, that acts as a wrapper, includes the field in gc traversal. Also, if the field is not initialized by bf_getbuffer its value can be indeterminate. For memoryview the gc can crash (see attached C demo program).

----------
components: Interpreter Core
files: bufobj.c.gz
messages: 117754
nosy: kermode
priority: normal
severity: normal
status: open
title: ~Py_buffer.obj field is undocumented, though not hidden
versions: Python 3.2
Added file: http://bugs.python.org/file19069/bufobj.c.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10001>
_______________________________________

From report at bugs.python.org  Thu Sep 30 23:37:09 2010
From: report at bugs.python.org (joblack)
Date: Thu, 30 Sep 2010 21:37:09 +0000
Subject: [New-bugs-announce] [issue10002] Installer doesn't install on
	Windows Server 2008	DataCenter R2
In-Reply-To: <1285882629.62.0.145594356076.issue10002@psf.upfronthosting.co.za>
Message-ID: <1285882629.62.0.145594356076.issue10002@psf.upfronthosting.co.za>


New submission from joblack <johannes.black at gmail.com>:

I tried to install the 32 Bit Python 2.7 Version (32 Bit version because of some 32 bit plugins) on a Windows Server 2008 DataCenter R2 and short at the end it throws the attached error message.

Have you tried your Python 2.7 on a Windows Server 2008 R2?

----------
components: Installation
files: python27bug.png
messages: 117760
nosy: joblack
priority: normal
severity: normal
status: open
title: Installer doesn't install on Windows Server 2008 DataCenter R2
versions: Python 2.7
Added file: http://bugs.python.org/file19071/python27bug.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10002>
_______________________________________