From report at bugs.python.org  Mon Feb  1 00:23:49 2010
From: report at bugs.python.org (Brian Harring)
Date: Sun, 31 Jan 2010 23:23:49 +0000
Subject: [New-bugs-announce] [issue7824] assertion error in 2to3
In-Reply-To: <1264980229.62.0.257206789858.issue7824@psf.upfronthosting.co.za>
Message-ID: <1264980229.62.0.257206789858.issue7824@psf.upfronthosting.co.za>


New submission from Brian Harring <ferringb at gmail.com>:

Under py3.1, translation of the attached file works fine- under py3.2, goes boom however.

Nothing custom in use here in terms of 2to3- there is some compatibility code in use w/in the module but that's not affecting the translator in my testing.

assertion error follows-

RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
Traceback (most recent call last):
  File "/usr/bin/2to3", line 6, in <module>
    sys.exit(main("lib2to3.fixes"))
  File "/home/ferringb/python-svn/Lib/lib2to3/main.py", line 165, in main
    options.processes)
  File "/home/ferringb/python-svn/Lib/lib2to3/refactor.py", line 613, in refactor
    items, write, doctests_only)
  File "/home/ferringb/python-svn/Lib/lib2to3/refactor.py", line 273, in refactor
    self.refactor_file(dir_or_file, write, doctests_only)
  File "/home/ferringb/python-svn/Lib/lib2to3/refactor.py", line 653, in refactor_file
    *args, **kwargs)
  File "/home/ferringb/python-svn/Lib/lib2to3/refactor.py", line 325, in refactor_file
    tree = self.refactor_string(input, filename)
  File "/home/ferringb/python-svn/Lib/lib2to3/refactor.py", line 355, in refactor_string
    self.refactor_tree(tree, name)
  File "/home/ferringb/python-svn/Lib/lib2to3/refactor.py", line 389, in refactor_tree
    self.traverse_by(self.post_order_heads, tree.post_order())
  File "/home/ferringb/python-svn/Lib/lib2to3/refactor.py", line 415, in traverse_by
    node.replace(new)
  File "/home/ferringb/python-svn/Lib/lib2to3/pytree.py", line 135, in replace
    assert self.parent is not None, str(self)
AssertionError:
    def __init__(self, get_keys_func, get_val_func):
        """
        @param get_keys_func: either a container, or func to call to get keys.
        @param get_val_func: a callable that is JIT called
            with the key requested.
        """
        if not isinstance(get_val_func, collections.Callable):
            raise TypeError("get_val_func isn't a callable")
        if hasattr(get_keys_func, "__iter__"):
            self._keys = get_keys_func
            self._keys_func = None
        else:
            if not isinstance(get_keys_func, collections.Callable):
                raise TypeError(
                    "get_keys_func isn't iterable or callable")
            self._keys_func = get_keys_func
        self._val_func = get_val_func
        self._vals = {}

If y'all need more than just the mappings.py file, this is from http://pkgcore.org/trac/pkgcore/browser/ferringb/snakeoil-dev/ , or just grab the most recent release at http://pkgcore.org/releases/snakeoil/snakeoil-0.3.6.tar.bz2 (both trunk and most recent blow up).

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: mappings.py
messages: 98634
nosy: ferringb
severity: normal
status: open
title: assertion error in 2to3
versions: Python 3.2
Added file: http://bugs.python.org/file16073/mappings.py

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

From report at bugs.python.org  Mon Feb  1 00:48:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2010 23:48:23 +0000
Subject: [New-bugs-announce] [issue7825] test_threadsignals leaks references
In-Reply-To: <1264981703.5.0.296078231343.issue7825@psf.upfronthosting.co.za>
Message-ID: <1264981703.5.0.296078231343.issue7825@psf.upfronthosting.co.za>


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

test_threadsignals leaks references. I'm unable to understand where. Maybe somewhere around Py_AddPendingCall()?
---------
$ ./python Lib/test/regrtest.py -R 3:2: test_threadsignals
test_threadsignals
beginning 5 repetitions
12345
.....
test_threadsignals leaked [8, 8] references, sum=16
1 test failed:
    test_threadsignals
---------

----------
components: Interpreter Core
messages: 98636
nosy: haypo
severity: normal
status: open
title: test_threadsignals leaks references
type: resource usage
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb  1 01:59:12 2010
From: report at bugs.python.org (Brian Harring)
Date: Mon, 01 Feb 2010 00:59:12 +0000
Subject: [New-bugs-announce] [issue7826] support caching for 2to3
In-Reply-To: <1264985952.93.0.779639488883.issue7826@psf.upfronthosting.co.za>
Message-ID: <1264985952.93.0.779639488883.issue7826@psf.upfronthosting.co.za>


New submission from Brian Harring <ferringb at gmail.com>:

Bit like unittest, right now it's rather hard to extend 2to3 for caching support (and other outputs) w/out duplicating the main function.

Attached is a patch that allows the refactoring tool class to be passed in- at the very least, this patch is enough to remove some of the nastier monkey patching tricks I had to level to inline caching support into 2to3.

Actual caching patch will follow shortly; roughly what it does is track the md5 of the original source and use that as a lookup to the transformed version.

That caching support isn't useful to the majority of users, but for developers w/ buildslaves it's a very useful reduction in runtime- for example, for 6 buildslaves I run for pkgcore (a py2k source that we translate upon install to py3k if the target is py3k), if the cache is primed this is a reduction of 20s to 1.8s.  Two minutes cpu time across the slaves brought down to ~11s.

As said, I understand it's a corner case, so getting the caching into 2to3 directly may not be possible.

This initial patch however makes it *way* easier to do inline the caching into 2to3 without having to copy/paste main (or do some heinous monkeypatching).

Patch is against svn trunk; doesn't apply cleanly to 3.1/2.6, but that's  just a minor modification to make it so.

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: allow_alternate_output_tools.patch
keywords: patch
messages: 98639
nosy: ferringb
severity: normal
status: open
title: support caching for 2to3
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file16077/allow_alternate_output_tools.patch

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

From report at bugs.python.org  Mon Feb  1 02:53:41 2010
From: report at bugs.python.org (Andrew Dalke)
Date: Mon, 01 Feb 2010 01:53:41 +0000
Subject: [New-bugs-announce] [issue7827] recv_into() argument 1 must be
	pinned buffer, not bytearray
In-Reply-To: <1264989221.02.0.754334241076.issue7827@psf.upfronthosting.co.za>
Message-ID: <1264989221.02.0.754334241076.issue7827@psf.upfronthosting.co.za>


New submission from Andrew Dalke <dalke at dalkescientific.com>:

In Python 2.6 and Python 2.7a2+, I can't socket.recv_into(a byte array instance).

I get a TypeError which complains about a "pinned buffer". I have only an inkling of what that means. Since an array.array("b") works there, and  since it works in Python 3.1.1, and since I thought the point of a bytearray was to make things like recv_into easier, I think this exception is a bug in Python 2.6 and 2.7.

Here's my reproducibles: 

Python 2.6.1 (r261:67515, Jul  7 2009, 23:51:51) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin 
Type "help", "copyright", "credits" or "license" for more information. 
>>> import socket 
>>> sock = socket.socket() 
>>> sock.connect( ("python.org", 80) ) 
>>> sock.send(b"GET / HTTP/1.0\r\n\r\n") 
18 
>>> buf = bytearray(b" " * 10) 
>>> sock.recv_into(buf) 

Traceback (most recent call last): 
  File "<stdin>", line 1, in <module> 
TypeError: recv_into() argument 1 must be pinned buffer, not bytearray 

I expected a bytearray to work there. In fact, I thought the point of 
bytearray was to allow this to work. 
By comparison, an array of bytes does work: 
>>> import array 
>>> arr = array.array("b") 
>>> arr.extend(map(ord, "This is a test")) 
>>> len(arr) 
14 
>>> sock.recv_into(arr) 
14 
>>> arr
array('b', [72, 84, 84, 80, 47, 49, 46, 49, 32, 51, 48, 50, 32, 70]) 
>>> "".join(map(chr, arr))
'HTTP/1.1 302 F' 

I don't even know what a "pinned buffer" means, and searching 
python.org isn't helpful.

Using a bytearray in Python 3.1.1 *does* work: 
Python 3.1.1 (r311:74480, Jan 31 2010, 23:07:16) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin 
Type "help", "copyright", "credits" or "license" for more information. 
>>> import socket 
>>> sock = socket.socket() 
>>> sock.connect( ("python.org", 80) ) 
>>> sock.send(b"GET / HTTP/1.0\r\n\r\n") 
18 
>>> buf = bytearray(b" " * 10) 
>>> sock.recv_into(buf) 
10 
>>> buf 
bytearray(b'HTTP/1.1 3') 

For reference, here's an example with 2.7a2+ (freshly built out of version control) showing that it does not work there.

Python 2.7a2+ (trunk:74969:77901M, Feb  1 2010, 02:44:24) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> sock = socket.socket()
>>> sock.connect( ("python.org", 80)  )
>>> b = bytearray(b" " * 10)
>>> sock.recv_into(b)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: recv_into() argument 1 must be pinned buffer, not bytearray
>>>

----------
components: IO
messages: 98644
nosy: dalke
severity: normal
status: open
title: recv_into() argument 1 must be pinned buffer, not bytearray
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Mon Feb  1 05:51:58 2010
From: report at bugs.python.org (nudgenudge)
Date: Mon, 01 Feb 2010 04:51:58 +0000
Subject: [New-bugs-announce] [issue7828] chr() and ord() documentation for
	wide characters
In-Reply-To: <1264999918.27.0.407460194608.issue7828@psf.upfronthosting.co.za>
Message-ID: <1264999918.27.0.407460194608.issue7828@psf.upfronthosting.co.za>


New submission from nudgenudge <pybug at sogetthis.com>:

The documentation of chr() and ord() fails to mention that on narrow Unicode builds, chr(n) will return a surrogate pair (hence a 2-character string) for n>=65536 and that ord(s) will accept a 2-character string if it's a surrogate pair.

Example:
Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> list(chr(123456))
['\ud838', '\ude40']
>>> len(chr(123456))
2
>>> ord(chr(123456))
123456
>>>

----------
assignee: georg.brandl
components: Documentation
messages: 98648
nosy: georg.brandl, nudgenudge
severity: normal
status: open
title: chr() and ord() documentation for wide characters
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Feb  1 14:25:16 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 01 Feb 2010 13:25:16 +0000
Subject: [New-bugs-announce] [issue7829] dis module documentation gives no
	indication of the	dangers of bytecode inspection
In-Reply-To: <1265030716.3.0.107246651396.issue7829@psf.upfronthosting.co.za>
Message-ID: <1265030716.3.0.107246651396.issue7829@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

>From python-dev:

On Fri, Jan 29, 2010 at 15:04,  <exarkun at twistedmatrix.com> wrote:
> On 10:47 pm, tjreedy at udel.edu wrote:
>>
>> On 1/29/2010 4:19 PM, Collin Winter wrote:
>>>
>>> On Fri, Jan 29, 2010 at 7:22 AM, Nick Coghlan<ncoghlan at gmail.com> wrote:
>>
>>> Agreed. We originally switched Unladen Swallow to wordcode in our
>>> 2009Q1 release, and saw a performance improvement from this across the
>>> board. We switched back to bytecode for the JIT compiler to make
>>> upstream merger easier. The Unladen Swallow benchmark suite should
>>> provided a thorough assessment of the impact of the wordcode ->
>>> bytecode switch. This would be complementary to a JIT compiler, rather
>>> than a replacement for it.
>>>
>>> I would note that the switch will introduce incompatibilities with
>>> libraries like Twisted. IIRC, Twisted has a traceback prettifier that
>>> removes its trampoline functions from the traceback, parsing CPython's
>>> bytecode in the process. If running under CPython, it assumes that the
>>> bytecode is as it expects. We broke this in Unladen's wordcode switch.
>>> I think parsing bytecode is a bad idea, but any switch to wordcode
>>> should be advertised widely.
>>
>> Several years, there was serious consideration of switching to a
>> registerbased vm, which would have been even more of a change. Since I
>> learned 1.4, Guido has consistently insisted that the CPython vm is not part
>> of the language definition and, as far as I know, he has rejected any byte-
>> code hackery in the stdlib. While he is not one to, say, randomly permute
>> the codes just to frustrate such hacks, I believe he has always considered
>> vm details private and subject to change and any usage thereof 'at one's own
>> risk'.
>
> Language to such effect might be a useful addition to this page (amongst
> others, perhaps):
>
>  http://docs.python.org/library/dis.html
>
> which very clearly and helpfully lays out quite a number of APIs which can
> be used to get pretty deep into the bytecode.  If all of this is subject to
> be discarded at the first sign that doing so might be beneficial for some
> reason, don't keep it a secret that people need to join python-dev to learn.
>

Can you file a bug and assign it to me?

-Brett

----------
assignee: georg.brandl
components: Documentation
messages: 98661
nosy: exarkun, georg.brandl
severity: normal
status: open
title: dis module documentation gives no indication of the dangers of bytecode inspection

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

From report at bugs.python.org  Mon Feb  1 20:07:31 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 01 Feb 2010 19:07:31 +0000
Subject: [New-bugs-announce] [issue7830] Flatten nested functools.partial
In-Reply-To: <1265051251.66.0.305258896073.issue7830@psf.upfronthosting.co.za>
Message-ID: <1265051251.66.0.305258896073.issue7830@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <alexander.belopolsky at gmail.com>:

Currently applying functools.partial to a callable that is already functools.partial object results in a nested object:

>>> from functools import partial
>>> def f(a,b,c): pass
... 
>>> p = partial(partial(f, 1), 2)
>>> p.func, p.args
(<functools.partial object at 0x100431d60>, (2,))


Proposed patch makes partial(partial(f, 1), 2) return partial(f, 1, 2) instead:
>>> p.func, p.args
(<function f at 0x10055d3a8>, (1, 2))

This patch is partially (no pun intended) motivated by a patch submitted by Christophe Simonis for issue4331. Christophe's patch flattens nested partials for a specific case of using partials as bound methods.

As proposed, the patch will enable flattening for subclasses of functools.partial, but will return a baseclass instance.  Flattening will also discard any state attached to the nested partial such as __name__, __doc__, etc or any subclass data.  I believe this is the right behavior, but this caveat is the reason I classify this patch as a "feature request" rather than "performance" or "resource usage".

----------
components: Library (Lib)
files: no-nested-partial.diff
keywords: patch
messages: 98674
nosy: Alexander.Belopolsky
severity: normal
status: open
title: Flatten nested functools.partial
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16083/no-nested-partial.diff

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

From report at bugs.python.org  Mon Feb  1 20:47:43 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 01 Feb 2010 19:47:43 +0000
Subject: [New-bugs-announce] [issue7831] cmp() is missing in 3.x
In-Reply-To: <1265053663.2.0.424350297065.issue7831@psf.upfronthosting.co.za>
Message-ID: <1265053663.2.0.424350297065.issue7831@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

The cmp(a, b) function is missing in 3.0.

This change is slightly documented in Doc/whatsnew/3.0.rst:
"The cmp() function should be treated as gone."

There's no "-3" warning and no 2to3 fixer for it.

----------
messages: 98680
nosy: flox
priority: normal
severity: normal
status: open
title: cmp() is missing in 3.x
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Feb  1 22:43:34 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 01 Feb 2010 21:43:34 +0000
Subject: [New-bugs-announce] [issue7832] assertSameElements([0, 1, 1], [0, 0,
	1]) does not fail
In-Reply-To: <1265060614.0.0.0935976543838.issue7832@psf.upfronthosting.co.za>
Message-ID: <1265060614.0.0.0935976543838.issue7832@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

The current behavior of "assertSameElements" is not correctly documented.

The unit test confirm that it is a tested behaviour.

However it seems more useful to provide a method which compares the actual count of each element in both sequences.
There's already some use cases in the stdlib test suite.

Proposed behavior:

Success: assertSameElements([1, None, None], [None, 1, None])
Failure: assertSameElements([1, None, None], [1, 1, 1, None])

----------
messages: 98692
nosy: ezio.melotti, flox, gregory.p.smith
priority: normal
severity: normal
status: open
title: assertSameElements([0, 1, 1], [0, 0, 1]) does not fail
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Feb  1 23:12:53 2010
From: report at bugs.python.org (Christoph Gohlke)
Date: Mon, 01 Feb 2010 22:12:53 +0000
Subject: [New-bugs-announce] [issue7833] Bdist_wininst installers fail to
	load extensions built	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>


New submission from Christoph Gohlke <cgohlke at uci.edu>:

Wininst-9.0.exe and wininst-9.0-amd64.exe are missing MSVCRT90 dependencies in the embedded manifest.

While testing installers of pywin32 <http://sourceforge.net/projects/pywin32/> version 214 built with Python 2.6.4 and the msvc9compiler_stripruntimes_regexp2.diff patch from Issue4120 <http://bugs.python.org/issue4120>, I noticed that the post_install script fails with an ImportError while trying to load extensions without embedded MSVCRT90 manifest:

Traceback (most recent call last):
  File "<string>", line 601, in <module>
  File "<string>", line 311, in install
  File "<string>", line 149, in LoadSystemModule
ImportError: DLL load failed: The specified module could not be found.

The code that fails is:

    mod = imp.load_module(modname, None, filename, ('.dll', 'rb', imp.C_EXTENSION))

where modname='pywintypes' and filename points to an existing 'pywintypes26.dll' file. 

The post_install script runs fine when executed from the main python.exe interpreter.

A possible fix is to embed a MSVCRT90 dependency into wininst-9.0.exe and wininst-9.0-amd64.exe using the following linker switches:

/MANIFESTDEPENDENCY:"type='Win32' name='Microsoft.VC90.CRT' version='9.0.21022.8' processorArchitecture='X86' publicKeyToken='1fc8b3b9a1e18e3b'"

/MANIFESTDEPENDENCY:"type='Win32' name='Microsoft.VC90.CRT' version='9.0.21022.8' processorArchitecture='amd64' publicKeyToken='1fc8b3b9a1e18e3b'" 

See also <http://msdn.microsoft.com/en-us/library/ew0y5khy.aspx>

A patch against the Python 2.6 PCbuild\bdist_wininst.vcproj is attached. I tested it with Python 2.6.4, 32 and 64 bit, and pywin32 214 installers built with the following command:

  python.exe setup.py bdist_wininst --user-access-control=auto --install-script=wxpython_win_post_install.py

----------
assignee: tarek
components: Distutils, Windows
files: bdist_wininst.vcproj.patch
keywords: patch
messages: 98694
nosy: cgohlke, tarek
severity: normal
status: open
title: Bdist_wininst installers fail to load extensions built with Issue4120 patch
versions: Python 2.6
Added file: http://bugs.python.org/file16086/bdist_wininst.vcproj.patch

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

From report at bugs.python.org  Tue Feb  2 01:13:34 2010
From: report at bugs.python.org (Mathew Martineau)
Date: Tue, 02 Feb 2010 00:13:34 +0000
Subject: [New-bugs-announce] [issue7834] socket.connect() no longer works
	with AF_BLUETOOTH L2CAP	sockets
In-Reply-To: <1265069614.13.0.295096684445.issue7834@psf.upfronthosting.co.za>
Message-ID: <1265069614.13.0.295096684445.issue7834@psf.upfronthosting.co.za>


New submission from Mathew Martineau <mat at martineau.name>:

The sockaddr_l2 struct used with connect() has changed in recent versions of the Linux kernel.  There is a new l2_cid member.

connect() only works with L2CAP sockets if l2_cid is set to 0.

Suggest initializing the whole sockaddr_l2 struct to 0 in getsockaddrarg() (socketmodule.c).

----------
components: Extension Modules
messages: 98700
nosy: Mathew.Martineau
severity: normal
status: open
title: socket.connect() no longer works with AF_BLUETOOTH L2CAP sockets
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/issue7834>
_______________________________________

From report at bugs.python.org  Tue Feb  2 10:55:04 2010
From: report at bugs.python.org (David Kirkby)
Date: Tue, 02 Feb 2010 09:55:04 +0000
Subject: [New-bugs-announce] [issue7836] Add /usr/sfw/lib to OpenSSL search
	path for Solaris.
In-Reply-To: <1265104504.64.0.0631825253097.issue7836@psf.upfronthosting.co.za>
Message-ID: <1265104504.64.0.0631825253097.issue7836@psf.upfronthosting.co.za>


New submission from David Kirkby <david.kirkby at onetel.net>:

In the top level setup.py there is a list of directories searched for the OpenSSL libraries. 

       ssl_libs = find_library_file(self.compiler, 'ssl',lib_dirs,
                                     ['/usr/local/ssl/lib',
                                      '/usr/contrib/ssl/lib/'
                                     ] )



 # Detect SSL support for the socket module (via _ssl)
        search_for_ssl_incs_in = [
                              '/usr/local/ssl/include',
                              '/usr/contrib/ssl/include/'

On Solaris 10, (but not Open Solaris), OpenSSL comes as part of the operating system, but the libraries reside in /usr/sfw/lib. 

drkirkby at kestrel:~$ ls  /usr/sfw/lib/libssl*
/usr/sfw/lib/libssl.so        /usr/sfw/lib/libssl.so.0.9.7

Could you simply add /usr/sfw/lib to the library search path, so they are found on Solaris 10? 

The include files reside in /usr/sfw/include/openssl

on Solaris 10.

----------
components: Build
messages: 98725
nosy: drkirkby
severity: normal
status: open
title: Add /usr/sfw/lib to OpenSSL search path for Solaris.
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Tue Feb  2 11:32:56 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 02 Feb 2010 10:32:56 +0000
Subject: [New-bugs-announce] [issue7837] assertSameElements doesn't filter
	enough py3k warnings
In-Reply-To: <1265106776.19.0.232903733304.issue7837@psf.upfronthosting.co.za>
Message-ID: <1265106776.19.0.232903733304.issue7837@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

In assertSameElements ( Lib/unittest/case.py ) there's a filter for py3k warning that checks for warning about dict comparisons but not for comparisons of unequal types. If python is run with the -3 flag and a non-hashable sequence with elements of different types is passed to assertSameElements the warning is not silenced. There's also a third warning that might be raised if among the elements there's a builtin function or method.

Patch attached.

----------
components: Library (Lib), Tests
files: issue7837.patch
keywords: easy, needs review, patch, patch
messages: 98726
nosy: ezio.melotti, flox, michael.foord
priority: normal
severity: normal
stage: patch review
status: open
title: assertSameElements doesn't filter enough py3k warnings
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file16097/issue7837.patch

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

From report at bugs.python.org  Tue Feb  2 18:00:24 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 02 Feb 2010 17:00:24 +0000
Subject: [New-bugs-announce] [issue7838] Undocumented subprocess functions
	on Windows
In-Reply-To: <1265130024.2.0.807929500007.issue7838@psf.upfronthosting.co.za>
Message-ID: <1265130024.2.0.807929500007.issue7838@psf.upfronthosting.co.za>


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

On Windows, the subprocess module makes use of functions publicly exposed by PC/_subprocess.c to interact with Win32 API functions. However, no documentation exists for these functions, neither in the online docs nor in docstrings.

----------
assignee: georg.brandl
components: Documentation, Windows
keywords: easy
messages: 98749
nosy: brian.curtin, georg.brandl
priority: normal
severity: normal
stage: needs patch
status: open
title: Undocumented subprocess functions on Windows
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/issue7838>
_______________________________________

From report at bugs.python.org  Tue Feb  2 20:08:04 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Feb 2010 19:08:04 +0000
Subject: [New-bugs-announce] [issue7839] Popen should raise ValueError if
	pass a string when	shell=False or a list when shell=True
In-Reply-To: <1265137684.99.0.487285282872.issue7839@psf.upfronthosting.co.za>
Message-ID: <1265137684.99.0.487285282872.issue7839@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Currently Popen accepts either a string or a list regardless of the value of 'shell'.  In the shell=False case, a string is interpreted as the command name, no matter what it actually is.  In the shell=True case, a list is interpreted as args[0] being the string to pass to sh -c, and the remaining elements are passed as additional arguments to sh.

Neither of these behaviors is particularly useful.  It is easy enough to put the command name in a single element list with shell=False, and as far as I've been able to tell there is nothing useful you can do with passing arguments to sh after the '-c [command'] argument.

Further, the current behavior leads to common mistakes and misunderstandings, especially the acceptance of a string when shell=False.  The inexperienced user will pass the complete command string, and get the confusing error message "No such file or directory".

The behavior when passing a list when shell=True is even more mysterious.  In this case, all elements of the list after args[0] appear to the programmer as if they are ignored.  This problem is made worse by the fact that the documentation for this case makes it sound as if multiple strings *can* be passed; this confusion at least will be cleared up by the patch from issue 6760.

I would like to see Popen changed so that when shell=False, passing a string for args results in a ValueError, and likewise when shell=True, passing a list results in a ValueError.

Since this is a backward incompatible change, we'd need to first deprecate the current behavior in 3.2, and then introduce the ValueError in 3.3.  While this would be annoying to those people who needed to change their programs, I think it would be worth it for the improved error feedback the revised API would provide.

----------
components: Library (Lib)
keywords: easy
messages: 98754
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: Popen should raise ValueError if pass a string when shell=False or a list when shell=True
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Tue Feb  2 23:34:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Feb 2010 22:34:48 +0000
Subject: [New-bugs-announce] [issue7840] Lib/ctypes/test/test_pep3118.py
	should not shadow the	memoryview() builtin
In-Reply-To: <1265150088.78.0.228755954807.issue7840@psf.upfronthosting.co.za>
Message-ID: <1265150088.78.0.228755954807.issue7840@psf.upfronthosting.co.za>


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

test_pep3118.py creates a dummy memoryview class and says "It can be removed when the py3k memoryview object is backported". Since memoryview has been backported to trunk, it should be removed.

----------
assignee: theller
components: Tests, ctypes
messages: 98760
nosy: pitrou, theller
priority: normal
severity: normal
stage: needs patch
status: open
title: Lib/ctypes/test/test_pep3118.py should not shadow the memoryview() builtin
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Feb  2 23:46:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Feb 2010 22:46:02 +0000
Subject: [New-bugs-announce] [issue7841] test_capi fails when run more than
	once
In-Reply-To: <1265150762.77.0.853473335422.issue7841@psf.upfronthosting.co.za>
Message-ID: <1265150762.77.0.853473335422.issue7841@psf.upfronthosting.co.za>


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

For some reason it only fails in py3k, not trunk.

test_capi
beginning 5 repetitions
12345
test test_capi crashed -- <class 'AssertionError'>: PyDateTime_CAPI somehow initialized
1 test failed:
    test_capi
[101007 refs]

----------
assignee: benjamin.peterson
components: Tests
messages: 98763
nosy: benjamin.peterson, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_capi fails when run more than once
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Feb  2 23:50:04 2010
From: report at bugs.python.org (Nigel Heron)
Date: Tue, 02 Feb 2010 22:50:04 +0000
Subject: [New-bugs-announce] [issue7842] py_compile.compile SyntaxError
	output
In-Reply-To: <1265151004.56.0.531784942224.issue7842@psf.upfronthosting.co.za>
Message-ID: <1265151004.56.0.531784942224.issue7842@psf.upfronthosting.co.za>


New submission from Nigel Heron <nigel at psycode.com>:

when a syntax error is generated in py_compile.compile(), the wrong arguments are passed to the new PyCompileError exception which in turn passes the wrong args to traceback.format_exception_only() producing the wrong output.

this was fixed in the py3k branch (Revision 56901) but is still broken in 2.6 and 2.7
the attached patch has the same fix but applied to the trunk.

here's a simple test case..

f = open('broken.py','w')
f.write("1 = a  #<-- obvious syntax err\n")
f.close()
import py_compile
py_compile.compile('broken.py')

----------
components: Library (Lib)
files: py_compile_patch.diff
keywords: patch
messages: 98766
nosy: nheron
severity: normal
status: open
title: py_compile.compile SyntaxError output
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file16114/py_compile_patch.diff

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

From report at bugs.python.org  Wed Feb  3 07:34:50 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Wed, 03 Feb 2010 06:34:50 +0000
Subject: [New-bugs-announce] [issue7843] python-dev archives are not updated
In-Reply-To: <1265178890.74.0.190962980731.issue7843@psf.upfronthosting.co.za>
Message-ID: <1265178890.74.0.190962980731.issue7843@psf.upfronthosting.co.za>


New submission from Ilya Sandler <ilya.sandler at gmail.com>:

http://mail.python.org/pipermail/python-dev/ archives have not been updated for a couple of weeks now.

A bug?

----------
messages: 98775
nosy: isandler
severity: normal
status: open
title: python-dev archives are not updated

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

From report at bugs.python.org  Wed Feb  3 14:51:21 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 03 Feb 2010 13:51:21 +0000
Subject: [New-bugs-announce] [issue7844] Add -3 warning for absolute imports.
In-Reply-To: <1265205081.99.0.588324125272.issue7844@psf.upfronthosting.co.za>
Message-ID: <1265205081.99.0.588324125272.issue7844@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

It would be good to have a -3 warning for any use of import in 2.7 whose semantics change in 3.x, as a result of the absolute imports PEP (PEP 328).

----------
components: Interpreter Core
messages: 98781
nosy: mark.dickinson
severity: normal
status: open
title: Add -3 warning for absolute imports.
versions: Python 2.7

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

From report at bugs.python.org  Wed Feb  3 14:58:36 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 03 Feb 2010 13:58:36 +0000
Subject: [New-bugs-announce] [issue7845] complex.__lt__ should return
	NotImplemented instead of	raising TypeError
In-Reply-To: <1265205516.08.0.748801363745.issue7845@psf.upfronthosting.co.za>
Message-ID: <1265205516.08.0.748801363745.issue7845@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Currently in py3k, order comparisons for complex numbers raise a TypeError.  This was necessary in Python 2.x in order to make a complex <-> complex comparison raise an exception.  In 3.x, it's no longer necessary, since if both sides of a comparison return NotImplemented the result of the comparison is a TypeError (in 2.x the result is a value based on comparing the ids).

In py3k, complex.__lt__ could be changed to always return NotImplemented.  This would allow a custom class to implement its own comparisons with complex, and would remove an unnecessary special case.

----------
assignee: mark.dickinson
components: Interpreter Core
messages: 98783
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: complex.__lt__ should return NotImplemented instead of raising TypeError
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Feb  3 16:02:16 2010
From: report at bugs.python.org (Andrew Clegg)
Date: Wed, 03 Feb 2010 15:02:16 +0000
Subject: [New-bugs-announce] [issue7846] Fnmatch cache is never cleared
	during usage
In-Reply-To: <1265209336.56.0.865162695939.issue7846@psf.upfronthosting.co.za>
Message-ID: <1265209336.56.0.865162695939.issue7846@psf.upfronthosting.co.za>


New submission from Andrew Clegg <ancl at pml.ac.uk>:

The fnmatch module has a cache of translation between glob patterns and compiled regular expressions. However this cache is never emptied; only added to. I am writing a python program which as part of its execution checks millions of unique globs - this causes the fnmatch cache to grow enormous.

Attached is a patch to limit the size of the fnmatch cache to 100 (chosen to be the same size as the re module).

----------
components: Library (Lib)
files: fnmatch.patch
keywords: patch
messages: 98786
nosy: andrewclegg
severity: normal
status: open
title: Fnmatch cache is never cleared during usage
versions: Python 2.5
Added file: http://bugs.python.org/file16116/fnmatch.patch

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

From report at bugs.python.org  Wed Feb  3 18:35:07 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 03 Feb 2010 17:35:07 +0000
Subject: [New-bugs-announce] [issue7847] Remove 'python -U' or document it
In-Reply-To: <1265218507.7.0.0697222778425.issue7847@psf.upfronthosting.co.za>
Message-ID: <1265218507.7.0.0697222778425.issue7847@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

Python 2.x supports a -U flag which has the effect largely the same as 'from __future__ import unicode_literals'.  However -U is undocumented anywhere except import.c.  We should either remove -U support from Python 2.7 or document it (and indicate in that documentation that the future import is preferred).

----------
messages: 98791
nosy: barry
severity: normal
status: open
title: Remove 'python -U' or document it
versions: Python 2.7

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

From report at bugs.python.org  Wed Feb  3 19:18:45 2010
From: report at bugs.python.org (Albertas Agejevas)
Date: Wed, 03 Feb 2010 18:18:45 +0000
Subject: [New-bugs-announce] [issue7848] copy.copy corrupts objects that
	return false value from	__getstate__
In-Reply-To: <1265221125.46.0.788083310396.issue7848@psf.upfronthosting.co.za>
Message-ID: <1265221125.46.0.788083310396.issue7848@psf.upfronthosting.co.za>


New submission from Albertas Agejevas <alga at pov.lt>:

When copy.copy is used on an object whose __getstate__ returns 0, it can produce a corrupt copy of an object:

>>> import copy
>>> class Foo(object):
...     def __init__(self):
...        self.value = 0
...     def __getstate__(self):
...        return self.value
...     def __setstate__(self, v):
...        self.value = v
... 
>>> one = Foo()
>>> two = copy.copy(one)
>>> two.value
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'Foo' object has no attribute 'value'

Pickling/unpickling works fine for this object, so this appears to be a bug in copy._reconstruct.

This is not a contrived example, BTrees.Length.Length from ZODB uses such a __getstate__.

----------
components: Library (Lib)
messages: 98793
nosy: alga
severity: normal
status: open
title: copy.copy corrupts objects that return false value from __getstate__
type: behavior
versions: Python 2.5, Python 2.6, Python 3.1

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

From report at bugs.python.org  Wed Feb  3 21:02:32 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 03 Feb 2010 20:02:32 +0000
Subject: [New-bugs-announce] [issue7849] Improve
	"test_support.check_warnings()"
In-Reply-To: <1265227352.4.0.15322999222.issue7849@psf.upfronthosting.co.za>
Message-ID: <1265227352.4.0.15322999222.issue7849@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

Currently this context manager is used in 3 different situations:
 - to silence standard warnings
 - to record warnings in a list, in order to verify them
 - to silence py3k warnings

But it does not accept any parameter, and it does not *check* if the filter is obsolete. It silence *all* warnings, blindly.

I would like to propose an enhancement of this function, which accepts a list of filters as parameters, and which verifies that there's really something to catch.
An optional boolean argument "lazy" can be used to disable the check.
  check_warnings([filter[, ...[, lazy=False]]])

Additionnally, a sister function will filter only the py3k warnings:
  check_py3k_warnings([filter[, ...[, lazy=False]]])

See the patch and its docstring for details.

Note: this context manager could be used to fix the last part of #7092

----------
components: Tests
messages: 98796
nosy: ezio.melotti, flox
priority: high
severity: normal
status: open
title: Improve "test_support.check_warnings()"
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Wed Feb  3 23:40:12 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 03 Feb 2010 22:40:12 +0000
Subject: [New-bugs-announce] [issue7850] platform.system() should be
	"macosx" instead of "Darwin"	on OSX
In-Reply-To: <1265236812.59.0.190434450591.issue7850@psf.upfronthosting.co.za>
Message-ID: <1265236812.59.0.190434450591.issue7850@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

The output of platform.system() should IMO be "macosx" on OSX to ensure that platform.platform() is consistent with distutils.util.get_platform().

The same is true for sys.platform, although it is unclear how much code that would break.

There are two reasons for wanting these changes. First of all the values tend to end up at locations where less sophistated users might see them unless we're careful (tests for 'sys.platform' in scripts, platform names in distributions, ...) and 'darwin' is not obviously related to MacOSX unless you're already quite technical.   The other reason is slightly nit picking: "Darwin" is the name of the kernel and a stand-alone unix based on that, which MacOSX is the name of the entire system which includes much more beyond basic unix stuff.


BTW. I know why sys.platform is "darwin" on OSX, that doesn't mean I have to like it ;-)

----------
components: Library (Lib)
messages: 98801
nosy: ronaldoussoren
severity: normal
status: open
title: platform.system() should be "macosx" instead of "Darwin" on OSX
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Feb  4 00:32:42 2010
From: report at bugs.python.org (Tom Aratyn)
Date: Wed, 03 Feb 2010 23:32:42 +0000
Subject: [New-bugs-announce] [issue7851] WatchedFileHandler needs to be
	references as	handlers.WatchedFileHandler in conf files
In-Reply-To: <1265239962.28.0.699755707671.issue7851@psf.upfronthosting.co.za>
Message-ID: <1265239962.28.0.699755707671.issue7851@psf.upfronthosting.co.za>


New submission from Tom Aratyn <themystic.ca at gmail.com>:

The documentation on using logging configuration files (http://docs.python.org/library/logging.html#configuring-logging) doesn't mention that the WatchedFileHandler needs to be referenced as "handlers.WatchedFileHandler". This behavior is different from most handlers (like FileHandler) which can be referenced without the package prefix. 

This surprise was experienced on python 2.6.4 on Ubuntu 9.10.

----------
assignee: georg.brandl
components: Documentation
messages: 98803
nosy: Tom.Aratyn, georg.brandl
severity: normal
status: open
title: WatchedFileHandler needs to be references as handlers.WatchedFileHandler in conf files
versions: Python 2.6

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

From report at bugs.python.org  Thu Feb  4 10:02:10 2010
From: report at bugs.python.org (Wang Chun)
Date: Thu, 04 Feb 2010 09:02:10 +0000
Subject: [New-bugs-announce] [issue7852] [PATCH] Drop "Computer" from "Apple
	Computer" in plistlib
In-Reply-To: <1265274130.06.0.273637901356.issue7852@psf.upfronthosting.co.za>
Message-ID: <1265274130.06.0.273637901356.issue7852@psf.upfronthosting.co.za>


New submission from Wang Chun <yaohua2000 at gmail.com>:

Apple's official utilities had been dropped the word "Computer". We should follow them.

imac:~$ cat test.py
__import__('plistlib').writePlist({}, 'test.plist')
imac:~$ python test.py
imac:~$ cat test.py
__import__('plistlib').writePlist({}, 'test.plist')
imac:~$ python test.py
imac:~$ cat test.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
</dict>
</plist>
imac:~$ plutil -convert xml1 test.plist
imac:~$ cat test.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict/>
</plist>
imac:~$

----------
components: Library (Lib)
files: plistlib.diff
keywords: patch
messages: 98815
nosy: wangchun
severity: normal
status: open
title: [PATCH] Drop "Computer" from "Apple Computer" in plistlib
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file16123/plistlib.diff

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

From report at bugs.python.org  Thu Feb  4 10:35:09 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 04 Feb 2010 09:35:09 +0000
Subject: [New-bugs-announce] [issue7853] on __exit__(),
	exc_value does not contain the exception.
In-Reply-To: <1265276109.88.0.802756804705.issue7853@psf.upfronthosting.co.za>
Message-ID: <1265276109.88.0.802756804705.issue7853@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

On __exit__(), the 3rd argument "exc_value" should contain the instance of the exception.

But in most cases, it contains only the string representation of the exception.

See attached test case.
Same behavior for KeyError, AttributeError, RuntimeError, ...

----------
components: Interpreter Core
files: case_contextmanager_exit.py
messages: 98817
nosy: flox
priority: high
severity: normal
stage: test needed
status: open
title: on __exit__(), exc_value does not contain the exception.
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file16125/case_contextmanager_exit.py

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

From report at bugs.python.org  Thu Feb  4 19:47:07 2010
From: report at bugs.python.org (allisonlong)
Date: Thu, 04 Feb 2010 18:47:07 +0000
Subject: [New-bugs-announce] [issue7854] term paper
In-Reply-To: <1265309227.46.0.140579300213.issue7854@psf.upfronthosting.co.za>
Message-ID: <1265309227.46.0.140579300213.issue7854@psf.upfronthosting.co.za>


New submission from allisonlong <allisonlong at trash2009.com>:

affordable <a href="http://www.term-paper.biz/custom-term-paper.html">term paper</a> writing services

----------
components: None
messages: 98843
nosy: allisonlong
severity: normal
status: open
title: term paper
type: performance
versions: Python 3.2

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

From report at bugs.python.org  Thu Feb  4 20:17:10 2010
From: report at bugs.python.org (Dino Viehland)
Date: Thu, 04 Feb 2010 19:17:10 +0000
Subject: [New-bugs-announce] [issue7855] Add test cases for ctypes/winreg
	for issues found in	IronPython
In-Reply-To: <1265311030.9.0.277359551887.issue7855@psf.upfronthosting.co.za>
Message-ID: <1265311030.9.0.277359551887.issue7855@psf.upfronthosting.co.za>


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

This adds new test cases for bugs reported by Thomas Heller against IronPython for ctypes and winreg:
   ctypes: the variant bool type isn't supported
   winreg: errno is not correctly set when QueryValue fails

----------
assignee: theller
components: Windows, ctypes
files: patch.diff
keywords: patch
messages: 98844
nosy: DinoV, theller
severity: normal
status: open
title: Add test cases for ctypes/winreg for issues found in IronPython
versions: Python 2.7
Added file: http://bugs.python.org/file16131/patch.diff

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

From report at bugs.python.org  Fri Feb  5 06:07:49 2010
From: report at bugs.python.org (Xuefer x)
Date: Fri, 05 Feb 2010 05:07:49 +0000
Subject: [New-bugs-announce] [issue7856] cannot decode from or encode to
	big5 \xf9\xd8
In-Reply-To: <1265346469.79.0.269704961777.issue7856@psf.upfronthosting.co.za>
Message-ID: <1265346469.79.0.269704961777.issue7856@psf.upfronthosting.co.za>


New submission from Xuefer x <xuefer at gmail.com>:

using iconv:
$ printf "\xf9\xd8" | iconv -f big5 -t utf-8 | xxd
0000000: e8a3 8f                                  ...
$ printf "\xe8\xa3\x8f" | iconv -f utf-8 -t big5 | xxd
0000000: f9d8                                     ..

using python
>>> print "\xf9\xd8".decode("big5")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'big5' codec can't decode bytes in position 0-1: illegal multibyte sequence
>>> print "\xe8\xa3\x8f".decode("utf-8").encode("big5")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'big5' codec can't encode character u'\u88cf' in position 0: illegal multibyte sequence

----------
components: Unicode
messages: 98865
nosy: Xuefer.x
severity: normal
status: open
title: cannot decode from or encode to big5 \xf9\xd8
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Feb  5 14:58:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Feb 2010 13:58:56 +0000
Subject: [New-bugs-announce] [issue7857] test_logging fails
In-Reply-To: <1265378336.27.0.807146257248.issue7857@psf.upfronthosting.co.za>
Message-ID: <1265378336.27.0.807146257248.issue7857@psf.upfronthosting.co.za>


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

First, listening and/or connecting often fails.
Second, the test should use try/finally to release all resources even in case of failure.

This is breaking most buildbots currently: http://www.python.org/dev/buildbot/trunk/


[snip]
test_listen_config_1_ok (test.test_logging.ConfigDictTest) ... Exception in thread Thread-1044:
Traceback (most recent call last):
  File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/threading.py", line 526, in __bootstrap_inner
    self.run()
  File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/threading.py", line 479, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/logging/config.py", line 847, in serve
    server = rcvr(port=port, handler=hdlr)
  File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/logging/config.py", line 827, in __init__
    ThreadingTCPServer.__init__(self, (host, port), handler)
  File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/SocketServer.py", line 406, in __init__
    self.server_bind()
  File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/SocketServer.py", line 417, in server_bind
    self.socket.bind(self.server_address)
  File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/socket.py", line 222, in meth
    return getattr(self._sock,name)(*args)
error: [Errno 98] Address already in use

ok

======================================================================
ERROR: test_listen_config_10_ok (test.test_logging.ConfigDictTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/test/test_logging.py", line 1597, in test_listen_config_10_ok
    self.setup_via_listener(json.dumps(self.config10))
  File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/test/test_logging.py", line 1581, in setup_via_listener
    sock.connect(('localhost', PORT))
  File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/socket.py", line 222, in meth
    return getattr(self._sock,name)(*args)
error: [Errno 111] Connection refused

----------
assignee: vinay.sajip
messages: 98872
nosy: pitrou, vinay.sajip
priority: critical
severity: normal
stage: needs patch
status: open
title: test_logging fails
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/issue7857>
_______________________________________

From report at bugs.python.org  Fri Feb  5 17:07:39 2010
From: report at bugs.python.org (Damien Elmes)
Date: Fri, 05 Feb 2010 16:07:39 +0000
Subject: [New-bugs-announce] [issue7858] os.utime(file, (0, 0,
	)) fails on on vfat, but doesn't fail immediately
In-Reply-To: <1265386059.32.0.591513195746.issue7858@psf.upfronthosting.co.za>
Message-ID: <1265386059.32.0.591513195746.issue7858@psf.upfronthosting.co.za>


New submission from Damien Elmes <resolver at gmail.com>:

It seems like you can't set a modtime of 0 on a vfat partition. This may not be a valid thing to do, but it took me a long time to figure out it was a bad thing, as the error doesn't appear until the next time the error flag is checked:

>>> os.utime("testfile", (0.0,0.0))
>>> import time
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 87] The parameter is incorrect

----------
messages: 98879
nosy: Damien.Elmes
severity: normal
status: open
title: os.utime(file, (0,0,)) fails on on vfat, but doesn't fail immediately
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Fri Feb  5 18:02:09 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 05 Feb 2010 17:02:09 +0000
Subject: [New-bugs-announce] [issue7859] support "with
	self.assertRaises(SomeException) as exc:"	syntax
In-Reply-To: <1265389329.54.0.487777722436.issue7859@psf.upfronthosting.co.za>
Message-ID: <1265389329.54.0.487777722436.issue7859@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

It would be useful to get the actual exception in order to introspect its attributes.

(See some potential uses in "test_dict")

----------
components: Tests
messages: 98882
nosy: flox
priority: normal
severity: normal
status: open
title: support "with self.assertRaises(SomeException) as exc:" syntax
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Feb  5 19:07:50 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 05 Feb 2010 18:07:50 +0000
Subject: [New-bugs-announce] [issue7860] 32-bit Python on 64-bit Windows
	reports incorrect	architecture
In-Reply-To: <1265393270.5.0.356323623138.issue7860@psf.upfronthosting.co.za>
Message-ID: <1265393270.5.0.356323623138.issue7860@psf.upfronthosting.co.za>


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

When running 32-bit Python on a 64-bit version of Windows, therefore running the process in WOW64 mode, platform.machine returns a misleading value. When running in WOW64, the processor architecture is masked to appear as "x86" when the machine is actually "AMD64" (which you see on a 64-bit app on 64-bit OS).

The change involves looking at an environment variable only set on WOW64 processes to see the native architecture. See http://blogs.msdn.com/david.wang/archive/2006/03/26/HOWTO-Detect-Process-Bitness.aspx

The patch does not include any test, as I'm not really sure how you could test this without using the change itself to figure out when it should be tested. Suggestions would be appreciated.

----------
components: Library (Lib), Windows
files: arch_misrepresented.diff
keywords: needs review, patch, patch
messages: 98890
nosy: brian.curtin
priority: normal
severity: normal
stage: patch review
status: open
title: 32-bit Python on 64-bit Windows reports incorrect architecture
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16143/arch_misrepresented.diff

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

From report at bugs.python.org  Fri Feb  5 20:37:32 2010
From: report at bugs.python.org (Thomas Spura)
Date: Fri, 05 Feb 2010 19:37:32 +0000
Subject: [New-bugs-announce] [issue7861] 2to3: "import foo" -> "from .
	import foo"
In-Reply-To: <1265398652.17.0.813820450189.issue7861@psf.upfronthosting.co.za>
Message-ID: <1265398652.17.0.813820450189.issue7861@psf.upfronthosting.co.za>


New submission from Thomas Spura <tomspur at fedoraproject.org>:

My custom setup / testcase for testing the transition "import foo" -> "from . import foo":

mkdir -p test/sub
touch test/sub/__init__.py
touch test/__init__.py

cat >> test/__init__.py << EOF
import sub
EOF

cat >> test.py << EOF
import test
EOF

This won't work with python3 so I ran 2to3 on it:
$ 2to3 .
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: No files need to be modified.

-> Nothing found.

Using the python3 version of 2to3:
$ python3-2to3 .
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: Refactored ./test/__init__.py
--- ./test/__init__.py (original)
+++ ./test/__init__.py (refactored)
@@ -1,1 +1,1 @@
-import sub
+from . import sub
RefactoringTool: Files that need to be modified:
RefactoringTool: ./test/__init__.py


-> python3 version of 2to3 can change it, but Python 2.6.2 is not able to.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 98900
nosy: tomspur
severity: normal
status: open
title: 2to3: "import foo" ->  "from . import foo"
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Fri Feb  5 22:28:20 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 05 Feb 2010 21:28:20 +0000
Subject: [New-bugs-announce] [issue7862] fileio.c: ValueError vs. IOError
	with impossible	operations
In-Reply-To: <1265405300.06.0.973184216127.issue7862@psf.upfronthosting.co.za>
Message-ID: <1265405300.06.0.973184216127.issue7862@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

I think that certain FileIO methods should raise IOError instead of
ValueError when a file operation is attempted with the wrong mode.
The methods of IOBase are documented to raise IOError in these situations.


>>> import io
>>> f = io.open("testfile", "w")
>>> f.read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: not readable
>>> 
>>> f = io.FileIO("testfile", "w")
>>> f.read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: File not open for reading

----------
components: IO
messages: 98909
nosy: pitrou, skrah, stutzbach
severity: normal
status: open
title: fileio.c: ValueError vs. IOError with impossible operations
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Feb  6 00:32:25 2010
From: report at bugs.python.org (Adal Chiriliuc)
Date: Fri, 05 Feb 2010 23:32:25 +0000
Subject: [New-bugs-announce] [issue7863] platform module doesn't detect
	Windows 7
In-Reply-To: <1265412745.93.0.400074024271.issue7863@psf.upfronthosting.co.za>
Message-ID: <1265412745.93.0.400074024271.issue7863@psf.upfronthosting.co.za>


New submission from Adal Chiriliuc <adal.chiriliuc at gmail.com>:

Running python 32 bit on Windows 7 64 bit:
>>> import platform
>>> platform.platform()
'Windows-post2008Server-6.1.7600'

Should be corrected to display
'Windows-7-6.1.7600'

Fix:
>        elif maj == 6:
>            if min == 0:
>                    # ..................
>                    release = 'Vista'
>                else:
>                    if productType == VER_NT_WORKSTATION:
>                        release = 'Vista'
>                    else:
>                        release = '2008Server'
>            elif min == 1:
>                release = '7'
>            else:
>                release = 'post2008Server'

----------
components: Library (Lib)
messages: 98920
nosy: adal
severity: normal
status: open
title: platform module doesn't detect Windows 7
versions: Python 2.6

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

From report at bugs.python.org  Sat Feb  6 05:24:16 2010
From: report at bugs.python.org (Justin Lebar)
Date: Sat, 06 Feb 2010 04:24:16 +0000
Subject: [New-bugs-announce] [issue7864] Deprecation markers in unittest
	docs are unclear
In-Reply-To: <1265430256.2.0.586981350141.issue7864@psf.upfronthosting.co.za>
Message-ID: <1265430256.2.0.586981350141.issue7864@psf.upfronthosting.co.za>


New submission from Justin Lebar <starwiz at gmail.com>:

The documentation for assertTrue/assert_/failUnless reads:

assertTrue(expr, msg=None)
assert_(expr, msg=None)
failUnless(expr, msg=None)
    ...
    Deprecated since version 3.1: failUnless().

The deprecation warning is confusing, since it appears to suggest that failUnless is also deprecated.

Perhaps the last line could read 

  assertTrue and assert_ are deprecated since version 3.1: Use failUnless() instead.

And similarly for the rest of the assertX methods.

----------
assignee: georg.brandl
components: Documentation
messages: 98933
nosy: Justin.Lebar, georg.brandl
severity: normal
status: open
title: Deprecation markers in unittest docs are unclear
versions: Python 3.1

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

From report at bugs.python.org  Sat Feb  6 13:27:08 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Sat, 06 Feb 2010 12:27:08 +0000
Subject: [New-bugs-announce] [issue7865] io close() swallowing exceptions
In-Reply-To: <1265459228.25.0.91197617162.issue7865@psf.upfronthosting.co.za>
Message-ID: <1265459228.25.0.91197617162.issue7865@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

The current semantic of io streams is to swallow IOErrors on close(), eg. in _pyio from the trunk, we have each time constructs like:
try:
     self.flush()
except IOError:
     pass  # If flush() fails, just give up

and in C files :
        /* If flush() fails, just give up */
        if (PyErr_ExceptionMatches(PyExc_IOError))
            PyErr_Clear();

I'd rather advocate letting exceptions flow, as users have the right to know if their io operations lost bytes.
Below is a test case for these swallowed exceptions.


PS : issues like http://bugs.python.org/issue7640 are actually much more crucial, so we shall let them higher priority

----------
components: IO
files: test_error_close.py
messages: 98940
nosy: pakal
severity: normal
status: open
title: io close() swallowing exceptions
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16147/test_error_close.py

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

From report at bugs.python.org  Sat Feb  6 16:55:10 2010
From: report at bugs.python.org (Mezhenin Artyom)
Date: Sat, 06 Feb 2010 15:55:10 +0000
Subject: [New-bugs-announce] [issue7866] it looks like a typo in unittest
In-Reply-To: <1265471710.93.0.463543374636.issue7866@psf.upfronthosting.co.za>
Message-ID: <1265471710.93.0.463543374636.issue7866@psf.upfronthosting.co.za>


New submission from Mezhenin Artyom <a.mezhenin at gmail.com>:

Try to run any test a you will see something like this:

./<TestModule>.py 
.......
----------------------------------------------------------------------
Ran 7 tests in 0.069s

OK

But there is no word "Ran" in English. I think the word is "Run".

----------
components: Tests
messages: 98943
nosy: artech
severity: normal
status: open
title: it looks like a typo in unittest
versions: Python 2.6

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

From report at bugs.python.org  Sat Feb  6 22:04:15 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 06 Feb 2010 21:04:15 +0000
Subject: [New-bugs-announce] [issue7867] Proposed FAQ entry on pass-by-?
	semantics and the meaning	of 'variable' in python
In-Reply-To: <1265490255.73.0.743157337936.issue7867@psf.upfronthosting.co.za>
Message-ID: <1265490255.73.0.743157337936.issue7867@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

A while back, after along discussion about variables and their meaning in Python on the python-list, I wrote up the attached FAQ entry to summarize what I got out of that enlightening discussion.  I'm proposing that this be added to the FAQs.  If this doesn't itself cause too much controversy I'll prepare a doc patch.

----------
assignee: georg.brandl
components: Documentation
files: passbyx.faq
messages: 98956
nosy: georg.brandl, r.david.murray
priority: normal
severity: normal
status: open
title: Proposed FAQ entry on pass-by-? semantics and the meaning of 'variable' in python
type: feature request
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16153/passbyx.faq

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

From report at bugs.python.org  Sat Feb  6 23:06:32 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 06 Feb 2010 22:06:32 +0000
Subject: [New-bugs-announce] [issue7868] add a loggerClass attribute to
	Manager
In-Reply-To: <1265493992.57.0.579633737056.issue7868@psf.upfronthosting.co.za>
Message-ID: <1265493992.57.0.579633737056.issue7868@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

This patch adds a loggerClass attribute to logging's Manager, and a setLoggerClass() function to set it.  If no loggerClass is set, the global _loggerClass is used.  This is for maximum backwards compatibility.

There are no doc updates as the Manager is not documented.

----------
assignee: vinay.sajip
files: logging.diff
keywords: easy, patch, patch
messages: 98964
nosy: georg.brandl, vinay.sajip
priority: high
severity: normal
stage: patch review
status: open
title: add a loggerClass attribute to Manager
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16155/logging.diff

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

From report at bugs.python.org  Sun Feb  7 06:10:18 2010
From: report at bugs.python.org (INADA Naoki)
Date: Sun, 07 Feb 2010 05:10:18 +0000
Subject: [New-bugs-announce] [issue7869] traceback from logging is unusable.
In-Reply-To: <1265519418.35.0.0585940634416.issue7869@psf.upfronthosting.co.za>
Message-ID: <1265519418.35.0.0585940634416.issue7869@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

When exception raised in logging, traceback is shown but it doesn't tell
me which logging code cause the error.

$ cat unusable_traceback.py 
import logging
logging.warn('%s %s', 1) # not enough arguments.

$ python unusable_traceback.py 
Traceback (most recent call last):
  File "/usr/lib/python2.6/logging/__init__.py", line 768, in emit
    msg = self.format(record)
  File "/usr/lib/python2.6/logging/__init__.py", line 648, in format
    return fmt.format(record)
  File "/usr/lib/python2.6/logging/__init__.py", line 436, in format
    record.message = record.getMessage()
  File "/usr/lib/python2.6/logging/__init__.py", line 306, in getMessage
    msg = msg % self.args
TypeError: not enough arguments for format string

----------
components: Library (Lib)
messages: 98981
nosy: naoki
severity: normal
status: open
title: traceback from logging is unusable.
type: behavior
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/issue7869>
_______________________________________

From report at bugs.python.org  Sun Feb  7 13:47:53 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 07 Feb 2010 12:47:53 +0000
Subject: [New-bugs-announce] [issue7870] Duplicate test methods in
	test_memoryio
In-Reply-To: <1265546873.41.0.795914089262.issue7870@psf.upfronthosting.co.za>
Message-ID: <1265546873.41.0.795914089262.issue7870@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

test_memoryio.TextIOTestMixin has duplicate (and conflicting!) definitions of test_relative_seek() and test_textio_properties().

----------
assignee: pitrou
components: Tests
messages: 98994
nosy: georg.brandl, pitrou
priority: high
severity: normal
status: open
title: Duplicate test methods in test_memoryio

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

From report at bugs.python.org  Sun Feb  7 13:53:24 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 07 Feb 2010 12:53:24 +0000
Subject: [New-bugs-announce] [issue7871] Duplicate test method in test_heapq
In-Reply-To: <1265547204.98.0.659112380909.issue7871@psf.upfronthosting.co.za>
Message-ID: <1265547204.98.0.659112380909.issue7871@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

test_heap has a duplicate "test_get_only" test method, and the one that's overwritten seems to end up in an infinite loop.

----------
assignee: rhettinger
messages: 98995
nosy: georg.brandl, rhettinger
severity: normal
status: open
title: Duplicate test method in test_heapq
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Feb  7 14:19:29 2010
From: report at bugs.python.org (Daniel Waterworth)
Date: Sun, 07 Feb 2010 13:19:29 +0000
Subject: [New-bugs-announce] [issue7872] Incorrect error raised on importing
	invalid module via	unittest
In-Reply-To: <1265548769.63.0.955560962057.issue7872@psf.upfronthosting.co.za>
Message-ID: <1265548769.63.0.955560962057.issue7872@psf.upfronthosting.co.za>


New submission from Daniel Waterworth <da.waterworth at googlemail.com>:

The problem is that when you import a module which is inside a package via 'loadTestsFromName' in unittest.TestLoader. If the imported module raises a ImportError this is read to mean that the module itself is unavailable.

To illustrate this I have a small test-case. First run the file runtests.py in python or python3. Next uncomment the first line in test/test.py and run again. The error I receive is:

Traceback (most recent call last):
  File "runtests.py", line 3, in <module>
    suite = unittest.TestLoader().loadTestsFromName("test.test")
  File "/usr/lib/python2.6/unittest.py", line 584, in loadTestsFromName
    parent, obj = obj, getattr(obj, part)
AttributeError: 'module' object has no attribute 'test'

Whereas I believe this should raise an "ImportError: No module named none_existant_module", just like it does when you try to import the module directly.

This would make the error more descriptive and therefore bugs of this nature easier to track down.

----------
components: Library (Lib)
files: testcase.tar.bz2
messages: 98997
nosy: Daniel.Waterworth
severity: normal
status: open
title: Incorrect error raised on importing invalid module via unittest
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file16166/testcase.tar.bz2

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

From report at bugs.python.org  Sun Feb  7 14:20:18 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Feb 2010 13:20:18 +0000
Subject: [New-bugs-announce] [issue7873] Remove precision restriction for
	integer formatting.
In-Reply-To: <1265548818.49.0.927659235166.issue7873@psf.upfronthosting.co.za>
Message-ID: <1265548818.49.0.927659235166.issue7873@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Currently, in trunk:

>>> '%0.116x' % 1
'00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001'
>>> '%0.117x' % 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>

This is intentional, and presumably due to use of a fixed-length buffer somewhere in the formatting internals.  It would be nice (and probably not very hard) to remove this precision restriction.

----------
assignee: mark.dickinson
components: Interpreter Core
keywords: easy
messages: 98998
nosy: eric.smith, mark.dickinson
priority: normal
severity: normal
status: open
title: Remove precision restriction for integer formatting.
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Feb  7 15:51:43 2010
From: report at bugs.python.org (Tobias)
Date: Sun, 07 Feb 2010 14:51:43 +0000
Subject: [New-bugs-announce] [issue7874] logging.basicConfig should raise
	warning/exception on	second call
In-Reply-To: <1265554303.97.0.0565819398913.issue7874@psf.upfronthosting.co.za>
Message-ID: <1265554303.97.0.0565819398913.issue7874@psf.upfronthosting.co.za>


New submission from Tobias <tac at gmx.li>:

logging.basicConfig should raise warning/eception on second call. Why?

logging.basicConfig(filename="/tmp/works.log")
logging.basicConfig(filename="/tmp/worksnot.log")

what do you think does happen? Right - logging goes to "/tmp/worksnot.log". But does not behave that way. The secound call does nothing. Simply bad coding style, an if without an else.

kind regards
Tobias

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 99003
nosy: tocomo
severity: normal
status: open
title: logging.basicConfig should raise warning/exception on second call
type: behavior
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Sun Feb  7 20:02:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 07 Feb 2010 19:02:46 +0000
Subject: [New-bugs-announce] [issue7875] test_multiprocessing / importlib
	failure
In-Reply-To: <1265569366.45.0.612808621772.issue7875@psf.upfronthosting.co.za>
Message-ID: <1265569366.45.0.612808621772.issue7875@psf.upfronthosting.co.za>


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

An interesting bug failure on one of the buildbots. It seems importlib has been enabled as the default import mechanism (when? where?).

test_multiprocessing
Process Process-24:
Traceback (most recent call last):
  File "/home/buildbot/slave/py-build/3.1.norwitz-amd64/build/Lib/multiprocessing/process.py", line 233, in _bootstrap
    self.run()
  File "/home/buildbot/slave/py-build/3.1.norwitz-amd64/build/Lib/multiprocessing/process.py", line 88, in run
    self._target(*self._args, **self._kwargs)
  File "/home/buildbot/slave/py-build/3.1.norwitz-amd64/build/Lib/test/test_multiprocessing.py", line 1210, in _putter
    manager.connect()
  File "/home/buildbot/slave/py-build/3.1.norwitz-amd64/build/Lib/multiprocessing/managers.py", line 477, in connect
    conn = Client(self._address, authkey=self._authkey)
  File "/home/buildbot/slave/py-build/3.1.norwitz-amd64/build/Lib/multiprocessing/connection.py", line 427, in XmlClient
    import xmlrpc.client as xmlrpclib
  File "/home/buildbot/slave/py-build/3.1.norwitz-amd64/build/Lib/importlib/_bootstrap.py", line 151, in decorated
    return fxn(self, module)
  File "/home/buildbot/slave/py-build/3.1.norwitz-amd64/build/Lib/importlib/_bootstrap.py", line 399, in load_module
    return self._load_module(module)
  File "/home/buildbot/slave/py-build/3.1.norwitz-amd64/build/Lib/importlib/_bootstrap.py", line 324, in _load_module
    code_object = self.get_code(module.__name__)
  File "/home/buildbot/slave/py-build/3.1.norwitz-amd64/build/Lib/importlib/_bootstrap.py", line 411, in get_code
    pyc_timestamp = marshal._r_long(data[4:8])
  File "/home/buildbot/slave/py-build/3.1.norwitz-amd64/build/Lib/importlib/__init__.py", line 65, in _r_long
    x = int_bytes[0]
IndexError: index out of range
test test_multiprocessing failed -- Traceback (most recent call last):
  File "/home/buildbot/slave/py-build/3.1.norwitz-amd64/build/Lib/test/test_multiprocessing.py", line 1223, in test_rapid_restart
    queue = manager.get_queue()
  File "/home/buildbot/slave/py-build/3.1.norwitz-amd64/build/Lib/multiprocessing/managers.py", line 644, in temp
    token, exp = self._create(typeid, *args, **kwds)
  File "/home/buildbot/slave/py-build/3.1.norwitz-amd64/build/Lib/multiprocessing/managers.py", line 542, in _create
    conn = self._Client(self._address, authkey=self._authkey)
  File "/home/buildbot/slave/py-build/3.1.norwitz-amd64/build/Lib/multiprocessing/connection.py", line 427, in XmlClient
    import xmlrpc.client as xmlrpclib
  File "/home/buildbot/slave/py-build/3.1.norwitz-amd64/build/Lib/importlib/_bootstrap.py", line 151, in decorated
    return fxn(self, module)
  File "/home/buildbot/slave/py-build/3.1.norwitz-amd64/build/Lib/importlib/_bootstrap.py", line 399, in load_module
    return self._load_module(module)
  File "/home/buildbot/slave/py-build/3.1.norwitz-amd64/build/Lib/importlib/_bootstrap.py", line 324, in _load_module
    code_object = self.get_code(module.__name__)
  File "/home/buildbot/slave/py-build/3.1.norwitz-amd64/build/Lib/importlib/_bootstrap.py", line 411, in get_code
    pyc_timestamp = marshal._r_long(data[4:8])
  File "/home/buildbot/slave/py-build/3.1.norwitz-amd64/build/Lib/importlib/__init__.py", line 65, in _r_long
    x = int_bytes[0]
IndexError: index out of range

----------
components: Library (Lib), Tests
messages: 99010
nosy: brett.cannon, jnoller, pitrou
priority: normal
severity: normal
status: open
title: test_multiprocessing / importlib failure
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Feb  7 21:46:39 2010
From: report at bugs.python.org (=?utf-8?q?Bernt_R=C3=B8skar_Brenna?=)
Date: Sun, 07 Feb 2010 20:46:39 +0000
Subject: [New-bugs-announce] [issue7876] unittest docs use deprecated method
	in code example
In-Reply-To: <1265575599.07.0.775312626866.issue7876@psf.upfronthosting.co.za>
Message-ID: <1265575599.07.0.775312626866.issue7876@psf.upfronthosting.co.za>


New submission from Bernt R?skar Brenna <bernt.brenna at gmail.com>:

Suggest change the code example to use assertRaises instead of failUnlessRaises.

The docs read:

assertRaises(exception[, callable, ...])?
failUnlessRaises(exception[, callable, ...])?
    ....

    with self.failUnlessRaises(some_error_class):
        do_something()

    ...

    Deprecated since version 3.1: failUnlessRaises()

----------
assignee: georg.brandl
components: Documentation
messages: 99017
nosy: Bernt.R?skar.Brenna, georg.brandl
severity: normal
status: open
title: unittest docs use deprecated method in code example
versions: Python 3.1

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

From report at bugs.python.org  Sun Feb  7 22:31:40 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 07 Feb 2010 21:31:40 +0000
Subject: [New-bugs-announce] [issue7877] Iterators over _winreg EnumKey and
	EnumValue results
In-Reply-To: <1265578300.82.0.0744515010877.issue7877@psf.upfronthosting.co.za>
Message-ID: <1265578300.82.0.0744515010877.issue7877@psf.upfronthosting.co.za>


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

While EnumKey and EnumValue directly implement the underlying Windows calls of the same name, they don't feel very Pythonic. The user has to create their own loop and increment a counter to get all of the keys or values, stopping the loop when WindowsError is raised.

I created IterKey and IterValue, iterators over RegEnumKeyEx and RegEnumValueEx respectively. This mainly began as playing around with writing Python iterators in C, but has proven to work pretty nicely so I figured I'd put it out there.

Patch includes docs and tests. Comments/suggestions welcome and appreciated.

----------
components: Library (Lib), Windows
files: keyvalue_iterators.diff
keywords: needs review, patch, patch
messages: 99020
nosy: brian.curtin
priority: normal
severity: normal
stage: patch review
status: open
title: Iterators over _winreg EnumKey and EnumValue results
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16170/keyvalue_iterators.diff

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

From report at bugs.python.org  Sun Feb  7 22:56:18 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 07 Feb 2010 21:56:18 +0000
Subject: [New-bugs-announce] [issue7878] regrtest should check for changes
	in import machinery
In-Reply-To: <1265579778.81.0.993838177381.issue7878@psf.upfronthosting.co.za>
Message-ID: <1265579778.81.0.993838177381.issue7878@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

The saved_test_environment context manager should check that sys.path_hooks, sys.path_importer_cache, and __import__ have not changed.

The thing that is tricky, though, is that sys.path_importer_cache is legitimately mutated by other tests simply because valid imports put in new values. The most conservative check, then, is to validate that pre-existing keys do not change their values. A more liberal check is to whitelist finders and validate that no key have a value that is not on the whitelist.

And for __import__, assigning against __builtins__.__import__ should be enough to also catch builtins.__import__.

----------
assignee: brett.cannon
components: Tests
keywords: easy
messages: 99024
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: regrtest should check for changes in import machinery
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Sun Feb  7 23:16:35 2010
From: report at bugs.python.org (Andrej Krpic)
Date: Sun, 07 Feb 2010 22:16:35 +0000
Subject: [New-bugs-announce] [issue7879] Too narrow platform check in
	test_datetime
In-Reply-To: <1265580995.55.0.406421096535.issue7879@psf.upfronthosting.co.za>
Message-ID: <1265580995.55.0.406421096535.issue7879@psf.upfronthosting.co.za>


New submission from Andrej Krpic <akrpic77 at gmail.com>:

Windows doesn't accept negative timestamps (stated in the comment), yet checks is made against os.name instead of sys.platform.

patch fixes that, and also enables windows ce to pass on this test.

I think this is better than having os.name in ("nt", "ce").

----------
components: Tests
files: test_datetime_win32_check.patch
keywords: patch
messages: 99026
nosy: akrpic77
severity: normal
status: open
title: Too narrow platform check in test_datetime
versions: Python 2.7
Added file: http://bugs.python.org/file16171/test_datetime_win32_check.patch

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

From report at bugs.python.org  Mon Feb  8 00:22:12 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 07 Feb 2010 23:22:12 +0000
Subject: [New-bugs-announce] [issue7880] sysconfig does not like symlinks
In-Reply-To: <1265584932.48.0.89611557521.issue7880@psf.upfronthosting.co.za>
Message-ID: <1265584932.48.0.89611557521.issue7880@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

~ $ cd /tmp
 ~ $ ln -s /usr/local/bin/python .
 ~ $ ./python -c "import sys; print sys.executable"
'import site' failed; use -v for traceback
/tmp/python

----------
assignee: tarek
components: Library (Lib)
messages: 99027
nosy: ezio.melotti, flox, tarek
priority: normal
severity: normal
status: open
title: sysconfig does not like symlinks
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Feb  8 01:06:30 2010
From: report at bugs.python.org (Neil Schemenauer)
Date: Mon, 08 Feb 2010 00:06:30 +0000
Subject: [New-bugs-announce] [issue7881] Hardcoded path,
	unsafe tempfile in test_logging
In-Reply-To: <1265587590.8.0.102752265888.issue7881@psf.upfronthosting.co.za>
Message-ID: <1265587590.8.0.102752265888.issue7881@psf.upfronthosting.co.za>


New submission from Neil Schemenauer <nas-python at arctrix.com>:

The commit for issue #7868 added the following line to test_logging:

print >> open('/tmp/tmp.txt', 'w'), type(logger)

I'm not sure if that was intentional but it should be fixed.  For one, that path does not necessarily exist.  Secondly, opening a file in a world writable directory like that is a potential security problem.  A simple fix would be to use tempfile.TemporaryFile().

----------
assignee: vinay.sajip
components: Tests
messages: 99032
nosy: nascheme, vinay.sajip
severity: normal
stage: needs patch
status: open
title: Hardcoded path, unsafe tempfile in test_logging
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb  8 10:02:59 2010
From: report at bugs.python.org (WK.)
Date: Mon, 08 Feb 2010 09:02:59 +0000
Subject: [New-bugs-announce] [issue7882] Compiling on MOX 10.6 "Snow
	Leopard" --#warning Building	for Intel with Mac OS X
	Deployment Target < 10.4 is invalid.
In-Reply-To: <1265619779.05.0.143100750232.issue7882@psf.upfronthosting.co.za>
Message-ID: <1265619779.05.0.143100750232.issue7882@psf.upfronthosting.co.za>


New submission from WK. <wolf.st.kappesser at gmx.de>:

get followed while compiling with

$ /configure --with-universal-archs="64-bit"
$ make


#warning Building for Intel with Mac OS X Deployment Target < 10.4 is invalid.

See attachment for complete build process.

----------
assignee: ronaldoussoren
components: Macintosh
files: build.txt
messages: 99040
nosy: global667, ronaldoussoren
severity: normal
status: open
title: Compiling on MOX 10.6 "Snow Leopard" --#warning Building for Intel with Mac OS X Deployment Target < 10.4 is invalid.
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file16177/build.txt

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

From report at bugs.python.org  Mon Feb  8 13:11:43 2010
From: report at bugs.python.org (=?utf-8?q?Bernt_R=C3=B8skar_Brenna?=)
Date: Mon, 08 Feb 2010 12:11:43 +0000
Subject: [New-bugs-announce] [issue7883] CallTips.py _find_constructor does
	not work
In-Reply-To: <1265631103.87.0.399117397925.issue7883@psf.upfronthosting.co.za>
Message-ID: <1265631103.87.0.399117397925.issue7883@psf.upfronthosting.co.za>


New submission from Bernt R?skar Brenna <bernt.brenna at gmail.com>:

Test case:

In IDLE python shell:
>>> from http.client import HTTPConnection
>>> c = HTTPConnection(

Notice that the call tip is an empty parenthesis.

This patch works for me:

[/tmp/py3k/Lib/idlelib]
$ svn diff
Index: CallTips.py
===================================================================
--- CallTips.py (revision 78103)
+++ CallTips.py (working copy)
@@ -116,7 +116,7 @@
 def _find_constructor(class_ob):
     "Find the nearest __init__() in the class tree."
     try:
-        return class_ob.__init__.__func__
+        return class_ob.__init__
     except AttributeError:
         for base in class_ob.__bases__:
             init = _find_constructor(base)

----------
components: IDLE
messages: 99043
nosy: Bernt.R?skar.Brenna
severity: normal
status: open
title: CallTips.py _find_constructor does not work
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Feb  8 13:31:58 2010
From: report at bugs.python.org (=?utf-8?q?Bernt_R=C3=B8skar_Brenna?=)
Date: Mon, 08 Feb 2010 12:31:58 +0000
Subject: [New-bugs-announce] [issue7884] IDLE 3.1.1 crashes with
	UnicodeDecodeError when I press	Ctrl-Space
In-Reply-To: <1265632318.52.0.922497995507.issue7884@psf.upfronthosting.co.za>
Message-ID: <1265632318.52.0.922497995507.issue7884@psf.upfronthosting.co.za>


New submission from Bernt R?skar Brenna <bernt.brenna at gmail.com>:

Platform: Linux
Python 3.1.1 built from source. Tk version 8.4, Tcl version 8.4.

Idle 2.6.4 (also built from source), works correctly (executes force-open-completions).

Test case:
- Start idle3
- press Ctrl-Space in the IDLE shell
- idle crashes, and a traceback is written to stdout:
Traceback (most recent call last):
  File "/usr/local/bin/idle3", line 6, in <module>
    main()
  File "/usr/local/lib/python3.1/idlelib/PyShell.py", line 1420, in main
    root.mainloop()
  File "/usr/local/lib/python3.1/tkinter/__init__.py", line 1009, in mainloop
    self.tk.mainloop(n)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1: illegal encoding

----------
components: IDLE, Tkinter
messages: 99044
nosy: Bernt.R?skar.Brenna
severity: normal
status: open
title: IDLE 3.1.1 crashes with UnicodeDecodeError when I press Ctrl-Space
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Mon Feb  8 17:52:33 2010
From: report at bugs.python.org (Neil Schemenauer)
Date: Mon, 08 Feb 2010 16:52:33 +0000
Subject: [New-bugs-announce] [issue7885] test_distutils fails if Python
	built in separate directory
In-Reply-To: <1265647953.87.0.513905112062.issue7885@psf.upfronthosting.co.za>
Message-ID: <1265647953.87.0.513905112062.issue7885@psf.upfronthosting.co.za>


New submission from Neil Schemenauer <nas-python at arctrix.com>:

Lib/test/test_distutils.py crashes if Python was built in a directory other than the source directory.  Using a separate build directory is handy if you are building Python with different sets of configure options since you only need one copy of the source. For example, in the source directory:

$ mkdir build-opt
$ cd build-opt
$ ../configure
$ make
$ cd ..
$ mkdir build-debug
$ cd build-debug
$ ../configure --with-pydebug
$ make 

I fixed a similar problem in rev 69304 but now it is broken again.  I get:

/tmp/tmpbxrmiB/xxmodule.c:17:20: error: Python.h: No such file or directory

Probably it is looking in the wrong directory for Python.h (assuming that the cwd is the top-level directory of the source).

----------
assignee: tarek
components: Tests
messages: 99054
nosy: nascheme, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_distutils fails if Python built in separate directory
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Feb  8 20:03:43 2010
From: report at bugs.python.org (tormen)
Date: Mon, 08 Feb 2010 19:03:43 +0000
Subject: [New-bugs-announce] [issue7886] reverse on an empty list returns
	None
In-Reply-To: <1265655823.9.0.9257468855.issue7886@psf.upfronthosting.co.za>
Message-ID: <1265655823.9.0.9257468855.issue7886@psf.upfronthosting.co.za>


New submission from tormen <tormen at gmx.net>:

# python 3.1.1:

myList = []
for item in myList:
    print( item ) # <<< works

for item in myList.reverse(): # <<< breaks with: TypeError: 'NoneType' object is not iterable
    print( item ) #

# But the reverse of an empty list should really be an empty list
# ... or do I miss something here?

----------
messages: 99059
nosy: tormen
severity: normal
status: open
title: reverse on an empty list returns None
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Tue Feb  9 00:46:57 2010
From: report at bugs.python.org (Jordan Apgar)
Date: Mon, 08 Feb 2010 23:46:57 +0000
Subject: [New-bugs-announce] [issue7887] errno 107 socket.recv issure
In-Reply-To: <1265672817.82.0.408353055509.issue7887@psf.upfronthosting.co.za>
Message-ID: <1265672817.82.0.408353055509.issue7887@psf.upfronthosting.co.za>


New submission from Jordan Apgar <twistedphrame at gmail.com>:

I have a simple tcp server and client where the server sits and waits for a message and then processes it, my client sends its first message to the server.  On the server I receive: 
socket.error: [Errno 107] Transport endpoint is not connected
when calling
msg = self.socket.recv(self.buffer)

My client receives the error:
socket.error: [Errno 104] Connection reset by peer
when calling    
msg = self.socket.recv(self.buffer)

I was working on the server and client over the weekend and sending and receiving worked fine, I wanted to debug a few things and I get this when I try to run it (no changes made from what I had on the weekend)

----------
components: None
messages: 99074
nosy: twistedphrame
severity: normal
status: open
title: errno 107 socket.recv issure
versions: Python 2.6

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

From report at bugs.python.org  Tue Feb  9 01:15:14 2010
From: report at bugs.python.org (Michael Newman)
Date: Tue, 09 Feb 2010 00:15:14 +0000
Subject: [New-bugs-announce] [issue7888] turtle "settiltangle" should be
	marked deprecated, not "tiltangle"
In-Reply-To: <1265674514.67.0.740398455539.issue7888@psf.upfronthosting.co.za>
Message-ID: <1265674514.67.0.740398455539.issue7888@psf.upfronthosting.co.za>


New submission from Michael Newman <michael.b.newman at gmail.com>:

In the turtle module documentation:
http://docs.python.org/3.1/library/turtle.html
http://docs.python.org/py3k/library/turtle.html

Currently it says "Deprecated since Python 3.1" under the "turtle.tiltangle" section. That should be under "turtle.settiltangle" instead.

For reference, the comments at the end of the documentation page correctly explains:
"Turtle.tiltangle() has been enhanced in functionality: it now can be used to get or set the tiltangle. Turtle.settiltangle() has been deprecated."

----------
assignee: georg.brandl
components: Documentation
messages: 99077
nosy: georg.brandl, mnewman
severity: normal
status: open
title: turtle "settiltangle" should be marked deprecated, not "tiltangle"
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Feb  9 01:15:53 2010
From: report at bugs.python.org (Terrence Cole)
Date: Tue, 09 Feb 2010 00:15:53 +0000
Subject: [New-bugs-announce] [issue7889] random produces different output on
	different	architectures
In-Reply-To: <1265674553.33.0.380899973746.issue7889@psf.upfronthosting.co.za>
Message-ID: <1265674553.33.0.380899973746.issue7889@psf.upfronthosting.co.za>


New submission from Terrence Cole <terrence at zettabytestorage.com>:

This code:
>>> random.seed(b'foo')
>>> random.getrandbits(8)
...repeated 7 more times...

Yields the sequence of values:
amd64: 227, 199,  34, 218,  83, 115, 236, 254
x86:   245, 198, 204,  66, 219,   4, 168,  93

Comments in the source seem to indicate random should produce the same results on all platforms.

I first thought that the seed was not resetting the state correctly, however, if I do a 'random.setstate( (3,(0,)*625,None) )' before seeding the generator, the results do not change from what is given above.  Also, calls to getrandbits after the setstate, but before another seed, correctly return 0.  It seems from this that seed is resetting the state properly, but some of the internals are not 32bit/64bit consistent.

----------
components: Library (Lib)
messages: 99078
nosy: terrence
severity: normal
status: open
title: random produces different output on different architectures
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Tue Feb  9 04:06:22 2010
From: report at bugs.python.org (lplatypus)
Date: Tue, 09 Feb 2010 03:06:22 +0000
Subject: [New-bugs-announce] [issue7890] equal unicode/str objects can have
	unequal hash
In-Reply-To: <1265684782.83.0.641089509966.issue7890@psf.upfronthosting.co.za>
Message-ID: <1265684782.83.0.641089509966.issue7890@psf.upfronthosting.co.za>


New submission from lplatypus <luke at deller.id.au>:

The documentation for the hash() function says:
"Numeric values that compare equal have the same hash value (even if they are of different types, as is the case for 1 and 1.0)"

This can be violated when comparing a unicode object with its str equivalent.  Here is an example:

C:\>c:\Python27\python -S
Python 2.7a3 (r27a3:78021, Feb  7 2010, 00:00:09) [MSC v.1500 32 bit (Intel)] on win32
>>> import sys; sys.setdefaultencoding('utf-8')
>>> unicodeobj = u'No\xebl'
>>> strobj = str(unicodeobj)
>>> unicodeobj == strobj
True
>>> hash(unicodeobj) == hash(strobj)
False

The last response should be True not False.

I tested this on Python 2.7a3/windows, 2.6.4/linux, 2.5.2/linux.  The problem is not relevant to Python 3.0+.

Looking at unicodeobject.c:unicode_hash() and stringobject.c:string_hash(), I think that this problem would arise for "equal" objects strobj and unicodeobj when the unicode code points are not aligned with the encoded bytes, ie when:
    map(ord, unicodeobj) != map(ord, strobj)
This means that the problem never arises when sys.getdefaultencoding() is 'ascii' or 'iso8859-1'/'latin1'.

----------
components: Interpreter Core
messages: 99084
nosy: ldeller
severity: normal
status: open
title: equal unicode/str objects can have unequal hash
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Feb  9 10:14:05 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 09 Feb 2010 09:14:05 +0000
Subject: [New-bugs-announce] [issue7891] add links to SVN for documentation
	developers
In-Reply-To: <1265706845.29.0.564813905696.issue7891@psf.upfronthosting.co.za>
Message-ID: <1265706845.29.0.564813905696.issue7891@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

http://www.python.org/dev/doc/ - this wordy page miss one important code snippet:

{{{
svn co http://svn.python.org/projects/python/trunk/Doc
}}}

the result of reduce(meditate("http://www.python.org/dev/doc/", "how to make a patch?", "where is the code?", "or no, one more web page")) =)

----------
assignee: georg.brandl
components: Documentation
messages: 99098
nosy: georg.brandl, techtonik
severity: normal
status: open
title: add links to SVN for documentation developers

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

From report at bugs.python.org  Tue Feb  9 17:51:25 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 16:51:25 +0000
Subject: [New-bugs-announce] [issue7892] [patch] refactor "test_dict.py"
	using new assertRaises	context manager.
In-Reply-To: <1265734285.51.0.850285768728.issue7892@psf.upfronthosting.co.za>
Message-ID: <1265734285.51.0.850285768728.issue7892@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

Patch to refactor "test_dict" using new unittest methods.

----------
components: Tests
files: patch_dict_assertRaises.diff
keywords: patch
messages: 99124
nosy: flox
priority: normal
severity: normal
stage: patch review
status: open
title: [patch] refactor "test_dict.py" using new assertRaises context manager.
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16187/patch_dict_assertRaises.diff

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

From report at bugs.python.org  Tue Feb  9 18:11:44 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 09 Feb 2010 17:11:44 +0000
Subject: [New-bugs-announce] [issue7893] unittest: have to subclass
	TextTestRunner to use	alternative TestResult
In-Reply-To: <1265735504.12.0.0790484553518.issue7893@psf.upfronthosting.co.za>
Message-ID: <1265735504.12.0.0790484553518.issue7893@psf.upfronthosting.co.za>


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

A common way to extend unittest is to implement a custom TestResult. Currently you have to subclass TextTestRunner, overriding _makeResult, to get it to use an alternative result class.

I suggest adding an additional, optional, argument to TextTestRunner to specify an alternative result class (or callable) that will be used by _makeResult. This will permit the use of custom test result objects without having to subclass.

----------
assignee: michael.foord
components: Extension Modules
keywords: easy
messages: 99129
nosy: michael.foord
severity: normal
stage: needs patch
status: open
title: unittest: have to subclass TextTestRunner to use alternative TestResult
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Feb  9 19:55:24 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 09 Feb 2010 18:55:24 +0000
Subject: [New-bugs-announce] [issue7894] too aggressive dependency tracking
	in distutils
In-Reply-To: <1265741724.72.0.383807580582.issue7894@psf.upfronthosting.co.za>
Message-ID: <1265741724.72.0.383807580582.issue7894@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

build_ext calculates which files for an Extension need to be recompiled. This calculation is way to aggrasive: if any source file for an Extension has changed all source files get recompiled.

It would be nice if distutils would only recompile the sources that actually changed (taking into account the 'depends' attribute of the Extension). 

If I read the code correctly this would be a new version, it seems that the current behavior is intentional.

----------
assignee: tarek
components: Distutils
messages: 99135
nosy: ronaldoussoren, tarek
severity: normal
stage: needs patch
status: open
title: too aggressive dependency tracking in distutils
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Feb  9 19:56:37 2010
From: report at bugs.python.org (Aahz)
Date: Tue, 09 Feb 2010 18:56:37 +0000
Subject: [New-bugs-announce] [issue7895] Mac 10.6 mac_ver() crashes
	with	USING_FORK_WITHOUT_EXEC_IS_NOT_SUPPORTED_BY_FILE_MANAGER
In-Reply-To: <1265741797.91.0.267775294764.issue7895@psf.upfronthosting.co.za>
Message-ID: <1265741797.91.0.267775294764.issue7895@psf.upfronthosting.co.za>


New submission from Aahz <aahz at pythoncraft.com>:

On OSX 10.6/Snow Leopard, using platform.mac_ver() in a subprocess
created with fork() but not calling exec() will cause a crash with
USING_FORK_WITHOUT_EXEC_IS_NOT_SUPPORTED_BY_FILE_MANAGER

You may need to be also running in GUI mode.

Ronald Oussouren says that you can get the same info from
/System/Library/CoreServices/SystemVersion.plist

----------
assignee: ronaldoussoren
components: Macintosh
messages: 99136
nosy: aahz, ronaldoussoren
severity: normal
stage: test needed
status: open
title: Mac 10.6 mac_ver() crashes with USING_FORK_WITHOUT_EXEC_IS_NOT_SUPPORTED_BY_FILE_MANAGER
type: crash

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

From report at bugs.python.org  Wed Feb 10 00:52:31 2010
From: report at bugs.python.org (John-Michael Glenn)
Date: Tue, 09 Feb 2010 23:52:31 +0000
Subject: [New-bugs-announce] [issue7896] IDLE.app crashes when attempting to
	open a .py file
In-Reply-To: <1265759551.07.0.248141897885.issue7896@psf.upfronthosting.co.za>
Message-ID: <1265759551.07.0.248141897885.issue7896@psf.upfronthosting.co.za>


New submission from John-Michael Glenn <j-m15 at hotmail.com>:

This happens every time I try to open any .py file from anywhere in my computer. I start IDLE.app and go to the menu and open a file then it pauses and crashes. I get a similar event when I try to use the Run Module option from the menu, except it doesn't crash it will hang and eventually show a shell window, but it does nothing and I am unable to do anything in either of the two windows. Here is the crash report for when I try to open a file (edited out bluetooth and airport information):

Process:         Python [48392]
Path:            /Applications/Python 2.6/IDLE.app/Contents/MacOS/Python
Identifier:      org.python.IDLE
Version:         2.6.4 (2.6.4)
Code Type:       X86-64 (Native)
Parent Process:  launchd [459]

Date/Time:       2010-02-09 15:25:43.842 -0800
OS Version:      Mac OS X 10.6.2 (10C540)
Report Version:  6

Interval Since Last Report:          895070 sec
Crashes Since Last Report:           28
Per-App Interval Since Last Report:  101706 sec
Per-App Crashes Since Last Report:   13
Anonymous UUID:                      FF835E84-3062-4BF0-8A30-7089C4C5C31B

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: 0x000000000000000d, 0x0000000000000000
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Application Specific Information:
objc_msgSend() selector name: release


Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib               	0x00007fff81c15120 objc_msgSend + 44
1   com.apple.CoreFoundation      	0x00007fff80037246 _CFAutoreleasePoolPop + 230
2   com.apple.Foundation          	0x00007fff851512f8 -[NSAutoreleasePool drain] + 158
3   com.tcltk.tklibrary           	0x00000001010bba4f XQueryPointer + 2425
4   com.tcltk.tklibrary           	0x00000001010bbd3f Tk_MacOSXSetupTkNotifier + 614
5   com.tcltk.tcllibrary          	0x000000010076c2ae Tcl_DoOneEvent + 297
6   _tkinter.so                   	0x00000001004e3311 Tkapp_MainLoop + 401
7   org.python.python             	0x00000001000b8018 PyEval_EvalFrameEx + 28696
8   org.python.python             	0x00000001000b8d70 PyEval_EvalCodeEx + 2112
9   org.python.python             	0x00000001000b6d5d PyEval_EvalFrameEx + 23901
10  org.python.python             	0x00000001000b71ba PyEval_EvalFrameEx + 25018
11  org.python.python             	0x00000001000b8d70 PyEval_EvalCodeEx + 2112
12  org.python.python             	0x00000001000b8e56 PyEval_EvalCode + 54
13  org.python.python             	0x00000001000dda8e PyRun_FileExFlags + 174
14  org.python.python             	0x00000001000ddd49 PyRun_SimpleFileExFlags + 489
15  org.python.python             	0x00000001000ed45c Py_Main + 3020
16  Python                        	0x0000000100000ed4 0x100000000 + 3796

Thread 1:  Dispatch queue: com.apple.libdispatch-manager
0   libSystem.B.dylib             	0x00007fff8053ebba kevent + 10
1   libSystem.B.dylib             	0x00007fff80540a85 _dispatch_mgr_invoke + 154
2   libSystem.B.dylib             	0x00007fff8054075c _dispatch_queue_invoke + 185
3   libSystem.B.dylib             	0x00007fff80540286 _dispatch_worker_thread2 + 244
4   libSystem.B.dylib             	0x00007fff8053fbb8 _pthread_wqthread + 353
5   libSystem.B.dylib             	0x00007fff8053fa55 start_wqthread + 13

Thread 2:
0   libSystem.B.dylib             	0x00007fff8053f9da __workq_kernreturn + 10
1   libSystem.B.dylib             	0x00007fff8053fdec _pthread_wqthread + 917
2   libSystem.B.dylib             	0x00007fff8053fa55 start_wqthread + 13

Thread 3:
0   libSystem.B.dylib             	0x00007fff805699e2 select$DARWIN_EXTSN + 10
1   com.tcltk.tcllibrary          	0x000000010079dd86 Tcl_InitNotifier + 1520
2   libSystem.B.dylib             	0x00007fff8055ef8e _pthread_start + 331
3   libSystem.B.dylib             	0x00007fff8055ee41 thread_start + 13

Thread 4:
0   libSystem.B.dylib             	0x00007fff80525e3a mach_msg_trap + 10
1   libSystem.B.dylib             	0x00007fff805264ad mach_msg + 59
2   com.apple.CoreFoundation      	0x00007fff8004e7a2 __CFRunLoopRun + 1698
3   com.apple.CoreFoundation      	0x00007fff8004dc2f CFRunLoopRunSpecific + 575
4   com.apple.CoreFoundation      	0x00007fff8004d9b6 CFRunLoopRun + 70
5   com.apple.DesktopServices     	0x00007fff87543d86 TSystemNotificationTask::SystemNotificationTaskProc(void*) + 514
6   ...ple.CoreServices.CarbonCore	0x00007fff82a5cb4d PrivateMPEntryPoint + 63
7   libSystem.B.dylib             	0x00007fff8055ef8e _pthread_start + 331
8   libSystem.B.dylib             	0x00007fff8055ee41 thread_start + 13

Thread 5:
0   libSystem.B.dylib             	0x00007fff8053f9da __workq_kernreturn + 10
1   libSystem.B.dylib             	0x00007fff8053fdec _pthread_wqthread + 917
2   libSystem.B.dylib             	0x00007fff8053fa55 start_wqthread + 13

Thread 6:
0   libSystem.B.dylib             	0x00007fff8053f9da __workq_kernreturn + 10
1   libSystem.B.dylib             	0x00007fff8053fdec _pthread_wqthread + 917
2   libSystem.B.dylib             	0x00007fff8053fa55 start_wqthread + 13

Thread 7:
0   libSystem.B.dylib             	0x00007fff8053f9da __workq_kernreturn + 10
1   libSystem.B.dylib             	0x00007fff8053fdec _pthread_wqthread + 917
2   libSystem.B.dylib             	0x00007fff8053fa55 start_wqthread + 13

Thread 8:
0   libSystem.B.dylib             	0x00007fff8053f9da __workq_kernreturn + 10
1   libSystem.B.dylib             	0x00007fff8053fdec _pthread_wqthread + 917
2   libSystem.B.dylib             	0x00007fff8053fa55 start_wqthread + 13

Thread 9:
0   libSystem.B.dylib             	0x00007fff805699e2 select$DARWIN_EXTSN + 10
1   com.apple.CoreFoundation      	0x00007fff80070242 __CFSocketManager + 818
2   libSystem.B.dylib             	0x00007fff8055ef8e _pthread_start + 331
3   libSystem.B.dylib             	0x00007fff8055ee41 thread_start + 13

Thread 10:
0   libSystem.B.dylib             	0x00007fff80525e3a mach_msg_trap + 10
1   libSystem.B.dylib             	0x00007fff805264ad mach_msg + 59
2   com.apple.opengl              	0x00007fff879fbad9 glcDebugListener + 313
3   libSystem.B.dylib             	0x00007fff8055ef8e _pthread_start + 331
4   libSystem.B.dylib             	0x00007fff8055ee41 thread_start + 13

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x00000001008c1c00  rbx: 0x00000001139cb700  rcx: 0x0000000116502ef6  rdx: 0x0000000000000000
  rdi: 0x00000001139cb700  rsi: 0x00007fff86ba2558  rbp: 0x00007fff5fbfeb50  rsp: 0x00007fff5fbfeb18
   r8: 0x7000000000000000   r9: 0x0000000116117740  r10: 0x000000011612d590  r11: 0x0000000116502ef6
  r12: 0x0000000100c81a00  r13: 0x0000000100c81a00  r14: 0x00007fff700363a0  r15: 0x0000000000000000
  rip: 0x00007fff81c15120  rfl: 0x0000000000010206  cr2: 0x0000000055d07000

Binary Images:
       0x100000000 -        0x100000fff +Python ??? (???) <93AE5D90-3A0D-DBF3-CC07-71F7D8ED12E9> /Applications/Python 2.6/IDLE.app/Contents/MacOS/Python
       0x100003000 -        0x100155fe7 +org.python.python 2.6.4, (c) 2004-2008 Python Software Foundation. (2.6.4) <CAD556F4-9264-1D6C-C08C-3E42FF2B9014> /Library/Frameworks/Python.framework/Versions/2.6/Python
       0x1002f6000 -        0x1002f9ff7 +strop.so ??? (???) <F4BB8FA4-9A11-F90F-AA22-102656C4F44C> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/strop.so
       0x10049a000 -        0x1004a2ff7 +_socket.so ??? (???) <262AE2EE-0F8D-5B90-BABB-4A582EC8EBCE> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_socket.so
       0x1004ac000 -        0x1004b0ff7 +_ssl.so ??? (???) <2EBDD47B-F57E-F550-2DFF-57A6AEFBE1C1> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_ssl.so
       0x1004b6000 -        0x1004b8fff +cStringIO.so ??? (???) <F5BA92A5-BA62-B238-B7E8-7D4570CD574C> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/cStringIO.so
       0x1004be000 -        0x1004c0fff +time.so ??? (???) <BEBB8BED-3DFD-2808-A538-C5DE75E8EC4C> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/time.so
       0x1004c5000 -        0x1004c6ff7 +_functools.so ??? (???) <D69C7AD7-6E45-31D6-BF32-B74F593D0D70> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_functools.so
       0x1004c9000 -        0x1004cdff7 +_collections.so ??? (???) <82EF05C3-28C5-AF63-9C15-DDA7AF1277DA> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_collections.so
       0x1004d3000 -        0x1004d7fff +operator.so ??? (???) <08CAD3FE-1E5E-2D58-3C9E-53794DE23BB4> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/operator.so
       0x1004df000 -        0x1004e7ff7 +_tkinter.so ??? (???) <DDB62008-C0E0-CB49-345C-9BD8B32DE11D> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_tkinter.so
       0x1006f7000 -        0x1007d5fff  com.tcltk.tcllibrary 8.5.7 (8.5.7) <58C89B97-8F2D-F83D-FBAD-70C9E8759DD0> /System/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl
       0x101000000 -        0x101108fef  com.tcltk.tklibrary 8.5.7 (8.5.7) <7904B095-6503-0263-5CA8-CE5F6C427FE6> /System/Library/Frameworks/Tk.framework/Versions/8.5/Tk
       0x1011cc000 -        0x1011d2ff7 +itertools.so ??? (???) <BAB24956-4407-14FD-97DB-692219EA34AE> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/itertools.so
       0x1011dc000 -        0x1011dffff +select.so ??? (???) <A8D51D88-38BB-86B7-F931-2047D8E6BB8D> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/select.so
       0x1011e5000 -        0x1011e6ff7 +fcntl.so ??? (???) <9C470F5E-50B6-7ECB-9B1C-3A4B04503C6B> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/fcntl.so
       0x1011e9000 -        0x1011eefff +_struct.so ??? (???) <2C59DE6C-CBE0-E277-9073-6F59A9B76BE2> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_struct.so
       0x1011f6000 -        0x1011f9ff7 +binascii.so ??? (???) <C20C040C-558A-FD06-BB65-1D1E25F09A1B> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/binascii.so
       0x1011fd000 -        0x1011fdfff +_bisect.so ??? (???) <E12C901C-C4DE-2FFF-4DAD-320FA0BF342E> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_bisect.so
       0x1015c3000 -        0x1015c4ff7 +icglue.so ??? (???) <87C3EE0D-19E8-3E31-D8DD-DD02E57BBC69> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/icglue.so
       0x1015c8000 -        0x1015ccff7 +_Res.so ??? (???) <5D45A6EF-E113-91F4-592A-6CA52D0B3EC8> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_Res.so
       0x1015d2000 -        0x1015d7fff +_File.so ??? (???) <10D16380-0726-910E-CECE-EA8D03291287> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_File.so
       0x1015e0000 -        0x1015e1ff7 +MacOS.so ??? (???) <7F7E362E-FD66-4281-6B15-79A2DBF9A14C> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/MacOS.so
       0x1016a5000 -        0x1016a8fff +math.so ??? (???) <A6937C5E-8DAF-FA03-0E32-8337631B0E2E> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/math.so
       0x1016ae000 -        0x1016affff +_random.so ??? (???) <3C3EF68B-C248-0957-7251-980C9FE3BD29> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_random.so
       0x1016b3000 -        0x1016b5ff7 +_locale.so ??? (???) <08BD827C-EB27-52EE-F932-3402959473A4> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_locale.so
       0x1016f9000 -        0x101709ff7 +cPickle.so ??? (???) <FAE0109D-401F-2DBC-A8F0-853BD4B1FC1E> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/cPickle.so
       0x101712000 -        0x101713ff7 +_heapq.so ??? (???) <96BBE9D8-AD16-AD7E-1B04-5AB9DD770C11> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_heapq.so
       0x113749000 -        0x11374efff  com.apple.qldisplay.Text 2.1 (327.3) <2683743E-BB44-3F07-48CB-535DC0EFAE92> /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/QuickLookUI.framework/Versions/A/Resources/DisplayBundles/Text.qldisplay/Contents/MacOS/Text
       0x113755000 -        0x11375afff  com.apple.qldisplay.Generic 2.1 (327.3) <A231C62A-B935-9F74-DE16-6C6FD2C2F295> /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/QuickLookUI.framework/Versions/A/Resources/DisplayBundles/Generic.qldisplay/Contents/MacOS/Generic
       0x118bba000 -        0x118d45ff7  GLEngine ??? (???) <87000128-AB5F-9631-CB53-5A792E58E655> /System/Library/Frameworks/OpenGL.framework/Resources/GLEngine.bundle/GLEngine
       0x118d75000 -        0x119233fe7  com.apple.driver.AppleIntelGMAX3100GLDriver 1.6.6 (6.0.6) <BC0CEAB3-467F-D9A7-98A4-FB7DC9FD149C> /System/Library/Extensions/AppleIntelGMAX3100GLDriver.bundle/Contents/MacOS/AppleIntelGMAX3100GLDriver
       0x11945e000 -        0x11947dfff  GLRendererFloat ??? (???) <5868E7F1-BAC2-F896-9DAA-D5ABDFA9A7C2> /System/Library/Frameworks/OpenGL.framework/Resources/GLRendererFloat.bundle/GLRendererFloat
    0x7fff5fc00000 -     0x7fff5fc3bdef  dyld 132.1 (???) <B633F790-4DDB-53CD-7ACF-2A3682BCEA9F> /usr/lib/dyld
    0x7fff80003000 -     0x7fff80176ff7  com.apple.CoreFoundation 6.6.1 (550.13) <1E952BD9-37C6-16BE-B2F0-CD92A6283D37> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fff80180000 -     0x7fff801b5ff7  libcups.2.dylib ??? (???) <B7854E3A-784F-5033-1A47-CF2AE40C5855> /usr/lib/libcups.2.dylib
    0x7fff801b6000 -     0x7fff801d1ff7  com.apple.openscripting 1.3.1 (???) <FD46A0FE-AC79-3EF7-AB4F-396D376DDE71> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
    0x7fff801d2000 -     0x7fff801ebfff  com.apple.CFOpenDirectory 10.6 (10.6) <0F46E102-8B8E-0995-BA85-3D9608F0A30C> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
    0x7fff801ec000 -     0x7fff8023bff7  com.apple.DirectoryService.PasswordServerFramework 6.0 (6.0) <14FD0978-4BE0-336B-A19E-F388694583EB> /System/Library/PrivateFrameworks/PasswordServer.framework/Versions/A/PasswordServer
    0x7fff80272000 -     0x7fff802f6fe7  com.apple.print.framework.PrintCore 6.1 (312.3) <33C0EADA-243E-1897-335D-17C5DC6A14A9> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
    0x7fff802f7000 -     0x7fff80322ff7  libxslt.1.dylib ??? (???) <87A0B228-B24A-C426-C3FB-B40D7258DD49> /usr/lib/libxslt.1.dylib
    0x7fff803b6000 -     0x7fff80438fe7  com.apple.QuickLookUIFramework 2.1 (327.3) <A35335F3-BC7B-1341-D934-45ACC19FFEC3> /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/QuickLookUI.framework/Versions/A/QuickLookUI
    0x7fff80439000 -     0x7fff80495fff  libGLU.dylib ??? (???) <6A6612BC-1AF9-08EC-80B2-B697238EED47> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
    0x7fff80496000 -     0x7fff80496ff7  com.apple.vecLib 3.5 (vecLib 3.5) <5B072584-9579-F54F-180E-5D425B37E85C> /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib
    0x7fff804a3000 -     0x7fff804e6fff  libtidy.A.dylib ??? (???) <8AF4DB3A-7BDB-7AF7-0E9C-413BBBD0E380> /usr/lib/libtidy.A.dylib
    0x7fff804e7000 -     0x7fff804e7ff7  com.apple.CoreServices 44 (44) <210A4C56-BECB-E3E4-B6EE-7EC53E02265D> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
    0x7fff804e8000 -     0x7fff80517ff7  com.apple.quartzfilters 1.6.0 (1.6.0) <9CECB4FC-1CCF-B8A2-B935-5888B21CBEEF> /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/QuartzFilters.framework/Versions/A/QuartzFilters
    0x7fff80525000 -     0x7fff806e3ff7  libSystem.B.dylib ??? (???) <526DD3E5-2A8B-4512-ED97-01B832369959> /usr/lib/libSystem.B.dylib
    0x7fff806e6000 -     0x7fff8072dff7  com.apple.coreui 2 (113) <60D2FE5C-8470-A0F4-379B-1E90FBD4FE7D> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
    0x7fff8072e000 -     0x7fff807befff  com.apple.SearchKit 1.3.0 (1.3.0) <4175DC31-1506-228A-08FD-C704AC9DF642> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
    0x7fff807bf000 -     0x7fff807d0fff  com.apple.DSObjCWrappers.Framework 10.6 (134) <3C08225D-517E-2822-6152-F6EB13A4ADF9> /System/Library/PrivateFrameworks/DSObjCWrappers.framework/Versions/A/DSObjCWrappers
    0x7fff8080c000 -     0x7fff8083dfef  libTrueTypeScaler.dylib ??? (???) <8291D9BB-97B2-AD06-D565-58A14A20D617> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libTrueTypeScaler.dylib
    0x7fff8083e000 -     0x7fff80bd6fff  com.apple.QuartzCore 1.6.1 (227.8) <E296B174-F7CB-F021-D103-091CCB33BBEB> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
    0x7fff80bd7000 -     0x7fff80c07fef  com.apple.shortcut 1.1 (1.1) <A99C9D8E-290B-B1E4-FEA5-CC5F2FB9C18D> /System/Library/PrivateFrameworks/Shortcut.framework/Versions/A/Shortcut
    0x7fff80c08000 -     0x7fff80c1eff7  com.apple.MultitouchSupport.framework 204.9 (204.9) <2BBD800A-0456-D90D-3205-8CE61F3A8F05> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport
    0x7fff80c5e000 -     0x7fff80e98ff7  com.apple.imageKit 2.0.1 (1.0) <5E32976B-5CEB-6316-2B5C-2ABFEF588E4F> /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/ImageKit.framework/Versions/A/ImageKit
    0x7fff80e99000 -     0x7fff8158d537  com.apple.CoreGraphics 1.536.12 (???) <0DCA088B-0C6B-146F-0341-9E0212B5CA50> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
    0x7fff816ee000 -     0x7fff8174bfef  com.apple.framework.IOKit 2.0 (???) <EBBEED67-D5BE-5F7F-96F4-9023BBA1B913> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
    0x7fff8174c000 -     0x7fff8176dfff  libresolv.9.dylib ??? (???) <01C7C750-7F6A-89B3-C586-5C50A839019E> /usr/lib/libresolv.9.dylib
    0x7fff8176e000 -     0x7fff8188ffe7  libcrypto.0.9.8.dylib ??? (???) <32F2A87F-B146-BBF2-3AD1-494C686F1EE3> /usr/lib/libcrypto.0.9.8.dylib
    0x7fff81890000 -     0x7fff8189bff7  com.apple.speech.recognition.framework 3.11.1 (3.11.1) <F0DDF27E-DB55-07CE-E548-C62095BE8167> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
    0x7fff8189c000 -     0x7fff81b05fff  com.apple.QuartzComposer 4.1 (156.10) <F5569DC9-15E9-0815-3032-7E1257F36A3E> /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/QuartzComposer.framework/Versions/A/QuartzComposer
    0x7fff81b06000 -     0x7fff81c0ffff  com.apple.MediaToolbox 0.420.18 (420.18) <0A2444E8-DA72-7DC8-084F-D78D28E5C74F> /System/Library/PrivateFrameworks/MediaToolbox.framework/Versions/A/MediaToolbox
    0x7fff81c10000 -     0x7fff81cc6fff  libobjc.A.dylib ??? (???) <F206BE6D-8777-AE6C-B367-7BEA76C14241> /usr/lib/libobjc.A.dylib
    0x7fff81cca000 -     0x7fff81cd9fff  com.apple.NetFS 3.2.1 (3.2.1) <FF21DB1E-F425-1005-FB70-BC19CAF4006E> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
    0x7fff81f51000 -     0x7fff820bdff7  com.apple.QTKit 7.6.3 (1591.3) <2AD2AC43-F6A8-F2CE-CCFE-9E8E38E47BB0> /System/Library/Frameworks/QTKit.framework/Versions/A/QTKit
    0x7fff820be000 -     0x7fff82101ff7  libRIP.A.dylib ??? (???) <9CA0768E-C2DF-61FD-F475-DB48F4219B49> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib
    0x7fff82102000 -     0x7fff82102ff7  com.apple.Accelerate 1.5 (Accelerate 1.5) <E517A811-E0E6-89D0-F397-66122C7A25A4> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
    0x7fff82103000 -     0x7fff823f3ff3  com.apple.RawCamera.bundle 2.3.0 (505) <E65CF964-5AFF-805A-E24C-4A9E2E3D4759> /System/Library/CoreServices/RawCamera.bundle/Contents/MacOS/RawCamera
    0x7fff823f4000 -     0x7fff82449fef  com.apple.framework.familycontrols 2.0 (2.0) <8DD78DC7-4C73-EDE6-86A4-BC35B335ED5F> /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls
    0x7fff82505000 -     0x7fff825c1ff7  libFontParser.dylib ??? (???) <99DEA723-9D02-2361-E3C7-034E25C5B829> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib
    0x7fff825c2000 -     0x7fff828c0fe7  com.apple.HIToolbox 1.6.2 (???) <D463A388-244E-047A-E49A-4DA6C15BD1BA> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
    0x7fff828c1000 -     0x7fff82970fff  edu.mit.Kerberos 6.5.9 (6.5.9) <42364D54-C647-14DE-2B1C-D94DAA03F092> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
    0x7fff82987000 -     0x7fff82998fef  libz.1.dylib ??? (???) <3A7A4C48-A4C8-A78A-8B87-C0DDF6601AC8> /usr/lib/libz.1.dylib
    0x7fff82999000 -     0x7fff829dffe7  libvDSP.dylib ??? (???) <2DAA1591-8AE8-B411-7D01-68DE99C63CEE> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
    0x7fff829e0000 -     0x7fff82a2aff7  com.apple.Metadata 10.6.2 (507.4) <A28A5E0C-DCDC-A5CE-4EB7-39752E63956A> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
    0x7fff82a2b000 -     0x7fff82a41fff  com.apple.ImageCapture 6.0 (6.0) <5B5AF8FB-C12A-B51F-94FC-3EC4698E818E> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture
    0x7fff82a42000 -     0x7fff82a55fff  libGL.dylib ??? (???) <5F9DAF5F-C25C-B6C2-C9BC-3D91D723FD85> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
    0x7fff82a56000 -     0x7fff82d88fef  com.apple.CoreServices.CarbonCore 861.2 (861.2) <39F3B259-AC2A-792B-ECFE-4F3E72F2D1A5> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
    0x7fff82fb1000 -     0x7fff82fbefe7  libCSync.A.dylib ??? (???) <F4066C8C-2A3E-4F2F-9F4D-03DB56F7C5CB> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib
    0x7fff82fbf000 -     0x7fff8304efff  com.apple.PDFKit 2.5 (2.5) <7849E675-4289-6FEA-E314-063E91A4B07F> /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/PDFKit.framework/Versions/A/PDFKit
    0x7fff831b8000 -     0x7fff83235fef  libstdc++.6.dylib ??? (???) <35ECA411-2C08-FD7D-11B1-1B7A04921A5C> /usr/lib/libstdc++.6.dylib
    0x7fff83376000 -     0x7fff833e2ff7  com.apple.CorePDF 1.1 (1.1) <3D51A551-50C5-DDD5-9A79-9679DA2806B0> /System/Library/PrivateFrameworks/CorePDF.framework/Versions/A/CorePDF
    0x7fff835d3000 -     0x7fff835d3ff7  com.apple.ApplicationServices 38 (38) <10A0B9E9-4988-03D4-FC56-DDE231A02C63> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
    0x7fff835d4000 -     0x7fff835f6ff7  com.apple.opencl 12 (12) <533D6753-D6E4-EC34-E93B-8F6498B50FBA> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
    0x7fff83627000 -     0x7fff83b1fff7  com.apple.VideoToolbox 0.420.18 (420.18) <428CE263-C02B-421D-7772-FC73EFF180A3> /System/Library/PrivateFrameworks/VideoToolbox.framework/Versions/A/VideoToolbox
    0x7fff83b81000 -     0x7fff83be3fe7  com.apple.datadetectorscore 2.0 (80.7) <F9D2332D-0890-2ED2-1AC8-F85CB89D8BD4> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore
    0x7fff83be4000 -     0x7fff83c4efe7  libvMisc.dylib ??? (???) <524DC30F-6A54-CCED-56D9-F57033B06E99> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
    0x7fff83c4f000 -     0x7fff83c51fff  libRadiance.dylib ??? (???) <376EAE92-8F25-9202-CC35-8EED5BD471FC> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
    0x7fff83c52000 -     0x7fff83c58ff7  IOSurface ??? (???) <8E0EE904-59D1-9AA0-CE55-B1777F4BAEC1> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface
    0x7fff83cb2000 -     0x7fff83cd6ff7  com.apple.CoreVideo 1.6.0 (43.1) <FF310442-03F4-648D-4CD2-D7AC459901D5> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
    0x7fff83cd7000 -     0x7fff83cdffff  com.apple.DisplayServicesFW 2.2 (2.2) <2C497E53-F471-5930-D15D-C033C438F39C> /System/Library/PrivateFrameworks/DisplayServices.framework/Versions/A/DisplayServices
    0x7fff83ce0000 -     0x7fff83ce1fff  liblangid.dylib ??? (???) <EA4D1607-2BD5-2EE2-2A3B-632EEE5A444D> /usr/lib/liblangid.dylib
    0x7fff84720000 -     0x7fff84725ff7  com.apple.CommonPanels 1.2.4 (91) <4D84803B-BD06-D80E-15AE-EFBE43F93605> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels
    0x7fff8474d000 -     0x7fff84775fff  com.apple.DictionaryServices 1.1.1 (1.1.1) <9FD709FC-23F0-F270-EAC1-C590CD516A36> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
    0x7fff84776000 -     0x7fff847b1ff7  com.apple.CoreMediaIOServices 124.0 (850) <B71C361C-105E-EDD2-5AEE-10E640445561> /System/Library/PrivateFrameworks/CoreMediaIOServices.framework/Versions/A/CoreMediaIOServices
    0x7fff849d4000 -     0x7fff849d7ff7  com.apple.securityhi 4.0 (36638) <77F40B57-2D97-7AE5-1331-8945C71DFB57> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
    0x7fff849fd000 -     0x7fff84a00ff7  libCoreVMClient.dylib ??? (???) <1C6D04BA-5F78-CC4D-26CB-7904919042B9> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib
    0x7fff84a4c000 -     0x7fff84a85ff7  com.apple.MeshKit 1.0 (49.0) <7587A7F2-DF5D-B8B2-A6A8-1389CF28BC51> /System/Library/PrivateFrameworks/MeshKit.framework/Versions/A/MeshKit
    0x7fff84a86000 -     0x7fff84ec9fef  libLAPACK.dylib ??? (???) <0CC61C98-FF51-67B3-F3D8-C5E430C201A9> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
    0x7fff84eca000 -     0x7fff84ed8ff7  libkxld.dylib ??? (???) <568C35E7-B101-3F1E-0361-3E1E9F15C90B> /usr/lib/system/libkxld.dylib
    0x7fff84f22000 -     0x7fff85060fff  com.apple.CoreData 102.1 (250) <8DDA49A1-F78C-DE30-8B58-EBC49E4E7ABF> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
    0x7fff85061000 -     0x7fff85075ff7  com.apple.speech.synthesis.framework 3.10.35 (3.10.35) <621B7415-A0B9-07A7-F313-36BEEDD7B132> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
    0x7fff8512b000 -     0x7fff853acfe7  com.apple.Foundation 6.6.1 (751.14) <767349DB-C486-70E8-7970-F13DB4CDAF37> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
    0x7fff853ad000 -     0x7fff853adff7  com.apple.quartzframework 1.5 (1.5) <B182B579-BCCE-81BF-8DA2-9E0B7BDF8516> /System/Library/Frameworks/Quartz.framework/Versions/A/Quartz
    0x7fff853ae000 -     0x7fff85467fff  libsqlite3.dylib ??? (???) <5A15E12A-AE8F-1A36-BBC7-564E7D7AD0FB> /usr/lib/libsqlite3.dylib
    0x7fff8560a000 -     0x7fff8560bff7  com.apple.audio.units.AudioUnit 1.6.2 (1.6.2) <98969AA3-2394-34B5-2DC3-7F4187E96D26> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
    0x7fff8560c000 -     0x7fff8560efff  com.apple.print.framework.Print 6.0 (237) <70DA9755-5DC1-716B-77E2-E42C5DAB85A2> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
    0x7fff8560f000 -     0x7fff856dbfff  com.apple.CFNetwork 454.5 (454.5) <319C7138-2839-DA5E-413A-618248BD4A32> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
    0x7fff856dc000 -     0x7fff85768fef  SecurityFoundation ??? (???) <B69E2FF9-A698-4923-BC8B-180224B6EF75> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
    0x7fff85769000 -     0x7fff8576aff7  com.apple.TrustEvaluationAgent 1.1 (1) <51867586-1C71-AE37-EAAD-535A58DD3550> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent
    0x7fff8576b000 -     0x7fff857ebff7  com.apple.iLifeMediaBrowser 2.1.3 (346.0.3) <04677A98-142E-9C0E-18A7-4C74275856B7> /System/Library/PrivateFrameworks/iLifeMediaBrowser.framework/Versions/A/iLifeMediaBrowser
    0x7fff857ec000 -     0x7fff857f1fff  libGIF.dylib ??? (???) <9DB87A71-27B7-A909-461B-F886DB2BD622> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
    0x7fff857fa000 -     0x7fff857feff7  libCGXType.A.dylib ??? (???) <E11B4D25-2251-4646-118C-87BD4C57A194> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib
    0x7fff85900000 -     0x7fff85947fef  com.apple.QuickLookFramework 2.1 (327.3) <6B3D79C5-E19B-97E1-673F-74731A0B188B> /System/Library/Frameworks/QuickLook.framework/Versions/A/QuickLook
    0x7fff85948000 -     0x7fff859e2fff  com.apple.ApplicationServices.ATS 4.1 (???) <E2A107C5-0230-265A-E40D-CFE0219C99E1> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
    0x7fff859e3000 -     0x7fff859e3ff7  com.apple.Cocoa 6.6 (???) <68B0BE46-6E24-C96F-B341-054CF9E8F3B6> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
    0x7fff85a0e000 -     0x7fff85a12ff7  libmathCommon.A.dylib ??? (???) <95718673-FEEE-B6ED-B127-BCDBDB60D4E5> /usr/lib/system/libmathCommon.A.dylib
    0x7fff85a13000 -     0x7fff85b1dff7  com.apple.MeshKitIO 1.0 (49.0) <66600E25-66F9-D31A-EA47-E81518FF6DDA> /System/Library/PrivateFrameworks/MeshKit.framework/Versions/A/Frameworks/MeshKitIO.framework/Versions/A/MeshKitIO
    0x7fff85b1e000 -     0x7fff85c42fe7  com.apple.audio.toolbox.AudioToolbox 1.6.2 (1.6.2) <466C5725-8311-41F1-1653-EB5C80644ED7> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
    0x7fff85c43000 -     0x7fff85c48fff  libGFXShared.dylib ??? (???) <05345B3E-5705-3C2A-464E-052B1DDA45B7> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib
    0x7fff85c49000 -     0x7fff85cfefe7  com.apple.ink.framework 1.3.1 (105) <5AA00FE5-B251-44AF-5108-44AA927C053C> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
    0x7fff85cff000 -     0x7fff85d05fff  libCGXCoreImage.A.dylib ??? (???) <B6A66067-68D9-7644-B4AF-EEA3B2AACA8D> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXCoreImage.A.dylib
    0x7fff85d0e000 -     0x7fff85d52fef  com.apple.ImageCaptureCore 1.0 (1.0) <29A6CF83-B5C2-9730-D71D-825AEC8657F5> /System/Library/Frameworks/ImageCaptureCore.framework/Versions/A/ImageCaptureCore
    0x7fff85d5f000 -     0x7fff85fe4fe7  com.apple.security 6.1.1 (37594) <E5DA8BFD-4A48-EFD4-E938-3BDFB356A8AF> /System/Library/Frameworks/Security.framework/Versions/A/Security
    0x7fff85fe5000 -     0x7fff861a3fff  libicucore.A.dylib ??? (???) <5BD16988-545F-6A8C-9A6F-FB18ACDCAEC2> /usr/lib/libicucore.A.dylib
    0x7fff861a4000 -     0x7fff86260ff7  com.apple.CoreServices.OSServices 352 (352) <CD933BBD-B260-552F-E64E-291D6ED3091A> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
    0x7fff86261000 -     0x7fff86261ff7  com.apple.Accelerate.vecLib 3.5 (vecLib 3.5) <BA861575-B0DE-50F5-A799-BDF188A3D4EF> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
    0x7fff862e1000 -     0x7fff863bbff7  com.apple.vImage 4.0 (4.0) <354F34BF-B221-A3C9-2CA7-9BE5E14AD5AD> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
    0x7fff863bc000 -     0x7fff863dafff  libPng.dylib ??? (???) <7635B74B-5415-9767-A881-E0B017F62376> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
    0x7fff863db000 -     0x7fff863edfe7  libsasl2.2.dylib ??? (???) <76B83C8D-8EFE-4467-0F75-275648AFED97> /usr/lib/libsasl2.2.dylib
    0x7fff863ee000 -     0x7fff8646dfff  com.apple.audio.CoreAudio 3.2.2 (3.2.2) <2633DFAC-F6A6-489D-8DF0-F12639CCD8C4> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
    0x7fff8646e000 -     0x7fff86e62fff  com.apple.AppKit 6.6.3 (1038.25) <2F7A5AC8-29E7-9B5F-D3F1-4C7F5821BB80> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
    0x7fff86fbd000 -     0x7fff86fd2ff7  com.apple.LangAnalysis 1.6.6 (1.6.6) <E83DAF4F-F284-BE0B-3D9D-D573023098B4> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis
    0x7fff86fd3000 -     0x7fff87022fef  libTIFF.dylib ??? (???) <796A1E6E-09B0-64F4-35F7-2ACEE9C2B429> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
    0x7fff8743c000 -     0x7fff87541fe7  libGLProgrammability.dylib ??? (???) <50498DA4-A2D6-260E-5C6E-994AF9BBDB98> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib
    0x7fff87542000 -     0x7fff87626fff  com.apple.DesktopServices 1.5.3 (1.5.3) <F443ED58-3761-116F-A8B2-C6DC29B7D119> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
    0x7fff87643000 -     0x7fff87684ff7  com.apple.SystemConfiguration 1.10.1 (1.10.1) <FFCA91A7-ADDB-E3D0-234A-47609BC37556> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
    0x7fff87685000 -     0x7fff876c2fef  libFontRegistry.dylib ??? (???) <8712832A-A980-3AAF-0D88-50164898F38E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib
    0x7fff876c3000 -     0x7fff87848fef  com.apple.JavaScriptCore 6531.21 (6531.21.9) <FB6CF9E3-A3B1-8C45-1D91-756679DE36FB> /System/Library/Frameworks/JavaScriptCore.framework/Versions/A/JavaScriptCore
    0x7fff87921000 -     0x7fff8795bfff  libssl.0.9.8.dylib ??? (???) <0714FA32-C193-CD96-80D1-6FCF06A0ED2E> /usr/lib/libssl.0.9.8.dylib
    0x7fff8795c000 -     0x7fff87962ff7  com.apple.DiskArbitration 2.3 (2.3) <857F6E43-1EF4-7D53-351B-10DE0A8F992A> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
    0x7fff87963000 -     0x7fff879b4fe7  com.apple.HIServices 1.8.0 (???) <113EEB8A-8EC6-9F86-EF46-4BA5C2CBF77C> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
    0x7fff879b5000 -     0x7fff879f6fef  com.apple.QD 3.33 (???) <3F528878-21F5-B2B5-8A9B-DF067BF91922> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
    0x7fff879f7000 -     0x7fff87a06fef  com.apple.opengl 1.6.5 (1.6.5) <30D6B03B-4B4C-1F78-1FDB-0403E7FE8707> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
    0x7fff87a07000 -     0x7fff87a1dfef  libbsm.0.dylib ??? (???) <42D3023A-A1F7-4121-6417-FCC6B51B3E90> /usr/lib/libbsm.0.dylib
    0x7fff87a1e000 -     0x7fff87a3eff7  com.apple.DirectoryService.Framework 3.6 (621.1) <FC0C2E15-84E2-B4A8-18EE-3AE620111627> /System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryService
    0x7fff87a3f000 -     0x7fff87a74fff  libGLImage.dylib ??? (???) <8AB3A26A-4CC4-4E6D-95CC-530FD7204599> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
    0x7fff87a75000 -     0x7fff87a75ff7  com.apple.Carbon 150 (152) <8D8CF535-90BE-691C-EC1B-63FBE2162C9B> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
    0x7fff87aa1000 -     0x7fff87adcff7  com.apple.AE 496.1 (496.1) <27D2D2E9-B309-7E65-8C3F-7FF01148F0DE> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
    0x7fff87add000 -     0x7fff87ae0fff  com.apple.help 1.3.1 (41) <54B79BA2-B71B-268E-8752-5C8EE00E49E4> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
    0x7fff87ae1000 -     0x7fff87b48fef  com.apple.AppleVAFramework 4.7.5 (4.7.5) <68D4E82B-7D55-A963-FF0B-80F276C1F2DE> /System/Library/PrivateFrameworks/AppleVA.framework/Versions/A/AppleVA
    0x7fff87b49000 -     0x7fff87b54ff7  com.apple.HelpData 2.0.4 (34) <B44D2E2A-BC1E-CD63-F8A1-C9465491693A> /System/Library/PrivateFrameworks/HelpData.framework/Versions/A/HelpData
    0x7fff87b79000 -     0x7fff87bf6fe7  com.apple.CoreText 3.1.0 (???) <B4BFF82D-CA77-9A8E-2C7E-66367E807C7C> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText
    0x7fff87bf7000 -     0x7fff87c1dfe7  libJPEG.dylib ??? (???) <89DFAA03-2801-BB31-1F4D-1AE0804E08BF> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
    0x7fff87c1e000 -     0x7fff88428fe7  libBLAS.dylib ??? (???) <FC941ECB-71D0-FAE3-DCBF-C5A619E594B8> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
    0x7fff88444000 -     0x7fff885fefef  com.apple.ImageIO.framework 3.0.1 (3.0.1) <10202E28-34DD-71CA-BE5D-1BE5C8DE2198> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO
    0x7fff88656000 -     0x7fff886beff7  com.apple.MeshKitRuntime 1.0 (49.0) <580F1945-540B-1E68-0341-A6ADAD78397E> /System/Library/PrivateFrameworks/MeshKit.framework/Versions/A/Frameworks/MeshKitRuntime.framework/Versions/A/MeshKitRuntime
    0x7fff88844000 -     0x7fff888e4fff  com.apple.LaunchServices 362 (362) <CCBFC037-7162-E392-B11F-90098891AE20> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
    0x7fff888eb000 -     0x7fff888f2fff  com.apple.OpenDirectory 10.6 (10.6) <72A65D76-7831-D31E-F1B3-9E48BF26A98B> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
    0x7fff888f5000 -     0x7fff88a0cfef  libxml2.2.dylib ??? (???) <EE067D7E-15B3-F043-6FBD-10BA31FE76C7> /usr/lib/libxml2.2.dylib
    0x7fff88a0d000 -     0x7fff88a59fff  libauto.dylib ??? (???) <072804DF-36AD-2DBE-7EF8-639CFB79077F> /usr/lib/libauto.dylib
    0x7fff88a5a000 -     0x7fff88b0eff7  com.apple.ColorSync 4.6.2 (4.6.2) <78A86D96-7758-6BFE-7231-A0C70F185FDD> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync
    0x7fff88b4d000 -     0x7fff88b4efff  com.apple.MonitorPanelFramework 1.3.0 (1.3.0) <5062DACE-FCE7-8E41-F5F6-58821778629C> /System/Library/PrivateFrameworks/MonitorPanel.framework/Versions/A/MonitorPanel
    0x7fff88b4f000 -     0x7fff88b8afe7  com.apple.CoreMedia 0.420.18 (420.18) <30166EED-C905-A818-9C3C-32E4EEA20995> /System/Library/PrivateFrameworks/CoreMedia.framework/Versions/A/CoreMedia
    0x7fffffe00000 -     0x7fffffe01fff  libSystem.B.dylib ??? (???) <526DD3E5-2A8B-4512-ED97-01B832369959> /usr/lib/libSystem.B.dylib

Model: MacBook4,1, BootROM MB41.00C1.B00, 2 processors, Intel Core 2 Duo, 2.4 GHz, 4 GB, SMC 1.31f0
Graphics: Intel GMA X3100, GMA X3100, Built-In, 144 MB

----------
components: IDLE, Tkinter
messages: 99141
nosy: phyreman
severity: normal
status: open
title: IDLE.app crashes when attempting to open a .py file
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Wed Feb 10 03:21:22 2010
From: report at bugs.python.org (Fernando Perez)
Date: Wed, 10 Feb 2010 02:21:22 +0000
Subject: [New-bugs-announce] [issue7897] Support parametrized tests in
	unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>


New submission from Fernando Perez <fdo.perez at gmail.com>:

IPython has unittest-based parametric testing (something nose has but
which produces effectively undebuggable tests, while this approach
gives perfectly debuggable ones).  The code lives here for 2.x and
3.x:

http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/annotate/head%3A/IPython/testing/_paramtestpy2.py

http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/annotate/head%3A/IPython/testing/_paramtestpy3.py

we import them into our public decorators module for actual use:

http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/annotate/head%3A/IPython/testing/decorators.py

Simple tests showing them in action are here:

http://bazaar.launchpad.net/%7Eipython-dev/ipython/trunk/annotate/head%3A/IPython/testing/tests/test_decorators.py#L45

The code is all BSD and we'd be more than happy to see it used
upstream; the less we have to carry the better.

If there is interest in this code, I'm happy to sign a PSF contributor agreement, the code is mostly my authorship. I received help for the 3.x version on the Testing in Python mailing list, I would handle asking for permission on-list if there is interest in including this.

----------
messages: 99149
nosy: fperez
severity: normal
status: open
title: Support parametrized tests in unittest
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Feb 10 09:19:19 2010
From: report at bugs.python.org (zhou wei)
Date: Wed, 10 Feb 2010 08:19:19 +0000
Subject: [New-bugs-announce] [issue7898] rlcompleter add "real tab" when
	text is empty feature
In-Reply-To: <1265789959.13.0.400404108309.issue7898@psf.upfronthosting.co.za>
Message-ID: <1265789959.13.0.400404108309.issue7898@psf.upfronthosting.co.za>


New submission from zhou wei <lilaboc.cn at gmail.com>:

When I use rlcompleter in interactive Python mode, I think it will be more convenient if autocomplete produce a real tab when text-to-autocomplete is empty.
For example:
>>> def test():
...<TAB>
will give:
Display all 182 possibilities? (y or n)
instead of a real tab

So, when indentation is needed, 4 times of spacebar pressing are required. That's why I think it will make more sense to just return a tab character when there is nothing to autocomplete.

This behavior is similar to autocompletion in ipython

----------
components: Library (Lib)
files: rlcompleter.diff
keywords: patch
messages: 99159
nosy: dieresys, facundobatista, georg.brandl, gpolo, lilaboc, pitrou, rnd0110
severity: normal
status: open
title: rlcompleter add "real tab" when text is empty feature
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file16200/rlcompleter.diff

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

From report at bugs.python.org  Wed Feb 10 15:58:29 2010
From: report at bugs.python.org (Prashanth noble)
Date: Wed, 10 Feb 2010 14:58:29 +0000
Subject: [New-bugs-announce] [issue7899] MemoryError While Executing Python
	Code
In-Reply-To: <1265813909.95.0.996847795707.issue7899@psf.upfronthosting.co.za>
Message-ID: <1265813909.95.0.996847795707.issue7899@psf.upfronthosting.co.za>


New submission from Prashanth noble <prashanth.bose at gmail.com>:

we are executing two queries and storing the result sets  and matching the data.

the table has got around 8 million records and while executing the same i am getting the Memory Issue.

TRACE Arguments: [ <DatabaseLibrary.resultset.Resultset instance at 0x01750828> | <DatabaseLibrary.resultset.Resultset instance at 0x01750E68> ] 
FAIL MemoryError 

DEBUG Traceback (most recent call last):

 File "c:\python26\lib\site-packages\DatabaseLibrary\__init__.py", line 52, in resultsets_should_match
   resultset1.matches_with(resultset2)
 File "c:\python26\lib\site-packages\DatabaseLibrary\resultset.py", line 37, in matches_with
   for row_a, row_b in zip(self, other): 


Please let me know how to resolve this issue

----------
components: Windows
messages: 99164
nosy: p_noblebose
severity: normal
status: open
title: MemoryError While Executing Python Code
type: performance
versions: Python 2.6

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

From report at bugs.python.org  Wed Feb 10 16:04:58 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 10 Feb 2010 15:04:58 +0000
Subject: [New-bugs-announce] [issue7900] posix.getgroups() failure on Mac OS
	X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>


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

test_posix fails on trunk on Mac OS X (Snow Leopard)

test.test_support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_posix.py", line 42, in testNoArgFunctions
    posix_func()
OSError: [Errno 22] Invalid argument

Python 2.7a3+ (trunk:78129M, Feb 10 2010, 10:40:28) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
>>> import posix
>>> posix.getgroups()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument

----------
components: Library (Lib)
messages: 99165
nosy: loewis, michael.foord
severity: normal
status: open
title: posix.getgroups() failure on Mac OS X
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Feb 10 16:56:47 2010
From: report at bugs.python.org (Robert Paul Allen)
Date: Wed, 10 Feb 2010 15:56:47 +0000
Subject: [New-bugs-announce] [issue7901] Add Vista/7  symlink support
In-Reply-To: <1265817407.06.0.421431727357.issue7901@psf.upfronthosting.co.za>
Message-ID: <1265817407.06.0.421431727357.issue7901@psf.upfronthosting.co.za>


New submission from Robert Paul Allen <ipatrol6010 at yahoo.com>:

I would like to see support for NTFS symbolic links to be added to the os module. As simple Popen('mklink') implementation could be used. Any other ideas?

----------
components: Library (Lib), Windows
messages: 99170
nosy: ipatrol
severity: normal
status: open
title: Add Vista/7  symlink support
type: feature request

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

From report at bugs.python.org  Wed Feb 10 20:09:23 2010
From: report at bugs.python.org (ganges master)
Date: Wed, 10 Feb 2010 19:09:23 +0000
Subject: [New-bugs-announce] [issue7902] relative import broken
In-Reply-To: <1265828963.53.0.5315107426.issue7902@psf.upfronthosting.co.za>
Message-ID: <1265828963.53.0.5315107426.issue7902@psf.upfronthosting.co.za>


New submission from ganges master <gangesmaster at users.sourceforge.net>:

the relative-import mechanism is broken... at least on python2.6 but i'd guess on later versions as well.

consider this package layout:
    /tmp/foo/
    /tmp/foo/__init__.py
    /tmp/foo/bar.py

where bar.py is:
    # note this is a relative import and should fail!
    from .os import walk
    print walk
    # and this should also fail
    from . import os
    print os

running it yields a bug:

$ PYTHONPATH="/tmp" python
Python 2.6.4 (r264:75706, Dec  7 2009, 18:45:15) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import foo.bar
<function walk at 0xb7d2aa04>  # <<<< ?!?!
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/tmp/foo/bar.py", line 4, in <module>
    from . import os
ImportError: cannot import name os


"from . import os" fails as expected, but "from .os import walk" works -- although it should obviously fail too.


-tomer

----------
components: Interpreter Core
files: bar.py
messages: 99176
nosy: gangesmaster
severity: normal
status: open
title: relative import broken
versions: Python 2.6
Added file: http://bugs.python.org/file16201/bar.py

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

From report at bugs.python.org  Wed Feb 10 22:04:57 2010
From: report at bugs.python.org (johns)
Date: Wed, 10 Feb 2010 21:04:57 +0000
Subject: [New-bugs-announce] [issue7903] Configure script incorrect for
	reasonably recent OpenBSD
In-Reply-To: <1265835897.46.0.381453341475.issue7903@psf.upfronthosting.co.za>
Message-ID: <1265835897.46.0.381453341475.issue7903@psf.upfronthosting.co.za>


New submission from johns <j0 at cox.net>:

Current OpenBSD is at 4.7 with a new release every six months.
diff below:

--- configure  Mon Jun  8 17:22:57 2009
+++ configure.new Wed Feb 10 16:00:34 2010
@@ -2086,7 +2086,7 @@
   # On OpenBSD, select(2) is not available if _XOPEN_SOURCE is defined,
   # even though select is a POSIX function. Reported by J. Ribbens.
   # Reconfirmed for OpenBSD 3.3 by Zachary Hamm, for 3.4 by Jason Ish.
-  OpenBSD/2.* | OpenBSD/3.[0123456789] | OpenBSD/4.[0123])
+  OpenBSD/2.* | OpenBSD/3.* | OpenBSD/4.[01234567])
     define_xopen_source=no
     # OpenBSD undoes our definition of __BSD_VISIBLE if _XOPEN_SOURCE is
     # also defined. This can be overridden by defining _BSD_SOURCE

----------
components: Installation
messages: 99178
nosy: johns
severity: normal
status: open
title: Configure script incorrect for reasonably recent OpenBSD
type: compile error
versions: Python 3.1

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

From report at bugs.python.org  Thu Feb 11 00:24:50 2010
From: report at bugs.python.org (mARK)
Date: Wed, 10 Feb 2010 23:24:50 +0000
Subject: [New-bugs-announce] [issue7904] urllib.urlparse mishandles novel
	schemes
In-Reply-To: <1265844290.89.0.139975092944.issue7904@psf.upfronthosting.co.za>
Message-ID: <1265844290.89.0.139975092944.issue7904@psf.upfronthosting.co.za>


New submission from mARK <python.mbloore at xoxy.net>:

urlparse.urlsplit('s3://example/files/photos/161565.jpg')
returns
('s3', '', '//example/files/photos/161565.jpg', '', '')
instead of
('s3', 'example', '/files/photos/161565.jpg', '', '')

according to rfc 3986 's3' is a valid scheme name, so the '://' indicates a URL with netloc and path parts.

----------
components: Extension Modules
messages: 99181
nosy: mbloore
severity: normal
status: open
title: urllib.urlparse mishandles novel schemes
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Thu Feb 11 04:14:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 11 Feb 2010 03:14:05 +0000
Subject: [New-bugs-announce] [issue7905] Shelf 'keyencoding' keyword
	argument is undocumented and	does not work.
In-Reply-To: <1265858045.44.0.437187909795.issue7905@psf.upfronthosting.co.za>
Message-ID: <1265858045.44.0.437187909795.issue7905@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

While working on another shelve issue I noticed that the keyencoding keyword argument was added to shelf, but that the value is hardcoded to 'utf-8' in the __init__ body.  DbfilenameShelf does not have a keyencoding option, nor does open, but BsdDbShelf does.  It seems to me that keyencoding was intended to be exposed but the work was not completed.  However I could be wrong...in which case the module should probably just use sys.getdefaultencoding.

I've prepared a patch that fixes the hardcoding bug and adds docs for the places where the keyword argument is currently accepted.  If this argument is kept and is documented, it should presumably be added to DbfilenameShelf and open as well.

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
files: shelve_keyencoding.patch
keywords: needs review, patch, patch
messages: 99193
nosy: georg.brandl, r.david.murray
priority: low
severity: normal
stage: patch review
status: open
title: Shelf 'keyencoding' keyword argument is undocumented and does not work.
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16206/shelve_keyencoding.patch

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

From report at bugs.python.org  Thu Feb 11 14:40:32 2010
From: report at bugs.python.org (Zsolt Cserna)
Date: Thu, 11 Feb 2010 13:40:32 +0000
Subject: [New-bugs-announce] [issue7906] float("INFI") returns inf on
	certain platforms
In-Reply-To: <1265895632.82.0.0740289647812.issue7906@psf.upfronthosting.co.za>
Message-ID: <1265895632.82.0.0740289647812.issue7906@psf.upfronthosting.co.za>


New submission from Zsolt Cserna <zsolt.cserna at morganstanley.com>:

Python 2.6.4
On my system which is solaris 8/sparc, float("INFI") returns inf instead of raising ValueError, both 32 and 64-bit. (since it's case-insensitive it applies to any upper/lower combination of letters).

This issue breaks test_float regression test which has a test for that value and it expects ValueError.

Doing some research and debugging showed me that strtod(const char *str, char **endptr) function behaves differently on solaris 8 than linux.
On solaris it stores \0 in **endptr meaning that it processed the string completely - and that's the reason why python doesn't raise ValueError.
On linux, strtod() stores 'I' in **endptr, and it results the ValueError.

With python 2.6.1 there's no such issue.

----------
components: Interpreter Core
messages: 99206
nosy: csernazs
severity: normal
status: open
title: float("INFI") returns inf on certain platforms
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Feb 11 14:58:48 2010
From: report at bugs.python.org (patraulea)
Date: Thu, 11 Feb 2010 13:58:48 +0000
Subject: [New-bugs-announce] [issue7907] winreg docs: CreateKeyEx should be
	CreateKey (minor)
In-Reply-To: <1265896728.51.0.656346450025.issue7907@psf.upfronthosting.co.za>
Message-ID: <1265896728.51.0.656346450025.issue7907@psf.upfronthosting.co.za>


New submission from patraulea <patraule at gmail.com>:

http://docs.python.org/library/_winreg.html

This page references CreateKeyEx which doesn't exist (Python uses CreateKey).

----------
assignee: georg.brandl
components: Documentation
messages: 99208
nosy: georg.brandl, patraulea
severity: normal
status: open
title: winreg docs: CreateKeyEx should be CreateKey (minor)
versions: Python 2.5, Python 2.6, Python 2.7

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

From report at bugs.python.org  Thu Feb 11 15:35:07 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 11 Feb 2010 14:35:07 +0000
Subject: [New-bugs-announce] [issue7908] remove leftover macos9 support code
In-Reply-To: <1265898907.53.0.125133680219.issue7908@psf.upfronthosting.co.za>
Message-ID: <1265898907.53.0.125133680219.issue7908@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

The attached patch removes all traces to os.name == 'mac' from the source tree (setup.py and stdlib), that is the leftover traces for MacOS9 support.

A simular patch needs to be created of the 3.x tree.

----------
assignee: ronaldoussoren
components: Macintosh
files: remove-platform-mac.txt
keywords: patch
messages: 99209
nosy: ronaldoussoren
priority: normal
severity: normal
stage: patch review
status: open
title: remove leftover macos9 support code
type: behavior
Added file: http://bugs.python.org/file16211/remove-platform-mac.txt

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

From report at bugs.python.org  Thu Feb 11 16:09:44 2010
From: report at bugs.python.org (Arno Bakker)
Date: Thu, 11 Feb 2010 15:09:44 +0000
Subject: [New-bugs-announce] [issue7909] os.path.abspath(os.devnull) returns
	\\\\nul should be nul?
In-Reply-To: <1265900984.97.0.533817039299.issue7909@psf.upfronthosting.co.za>
Message-ID: <1265900984.97.0.533817039299.issue7909@psf.upfronthosting.co.za>


New submission from Arno Bakker <abakker at users.sourceforge.net>:

I encountered this when somebody used:

logging.basicConfig(level=logging.CRITICAL,
                    format='%(asctime)s %(levelname)-8s %(message)s',
                    datefmt='%a, %d %b %Y %H:%M:%S',
                    filename=os.devnull,
                    filemode='w')

the logging code apparently calls os.path.abspath(filename) somewhere,
causing an exception:
 File "c:\python264\lib\logging\__init__.py", line 838, in _open
   stream = open(self.baseFilename, self.mode)
   IOError: [Errno 2] No such file or directory: '\\\\nul'

----------
components: Windows
messages: 99212
nosy: abakker
severity: normal
status: open
title: os.path.abspath(os.devnull) returns \\\\nul should be nul?
versions: Python 2.6

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

From report at bugs.python.org  Thu Feb 11 16:26:28 2010
From: report at bugs.python.org (Matthew Russell)
Date: Thu, 11 Feb 2010 15:26:28 +0000
Subject: [New-bugs-announce] [issue7910] immutability w/r to tuple.__add__
In-Reply-To: <1265901988.91.0.740301104543.issue7910@psf.upfronthosting.co.za>
Message-ID: <1265901988.91.0.740301104543.issue7910@psf.upfronthosting.co.za>


New submission from Matthew Russell <matt.horizon5 at gmail.com>:

Tuples, as we know are designed to immutable.

Hence I'm questioning if the following behavior is considered a defect:

>>> t = (1, 2)
>>> t += (1, 2, 3)
>>> t
(1, 2, 3)

?

----------
components: Interpreter Core
messages: 99219
nosy: mattrussell
severity: normal
status: open
title: immutability w/r to tuple.__add__
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Thu Feb 11 19:29:15 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 11 Feb 2010 18:29:15 +0000
Subject: [New-bugs-announce] [issue7911] unittest.TestCase.longMessage
	should default to True in	Python 3.2
Message-ID: <1265912955.61.0.102134792.issue7911@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
assignee: michael.foord
keywords: easy
nosy: michael.foord
severity: normal
stage: needs patch
status: open
title: unittest.TestCase.longMessage should default to True in Python 3.2
versions: Python 3.2

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

From report at bugs.python.org  Thu Feb 11 19:40:17 2010
From: report at bugs.python.org (James Sparenberg)
Date: Thu, 11 Feb 2010 18:40:17 +0000
Subject: [New-bugs-announce] [issue7912] Error in additon of decimal numbers
In-Reply-To: <1265913617.65.0.207561633263.issue7912@psf.upfronthosting.co.za>
Message-ID: <1265913617.65.0.207561633263.issue7912@psf.upfronthosting.co.za>


New submission from James Sparenberg <linuxrebel at gmail.com>:

Python produces rounding errors when adding decimals.

ython 2.6.4 (r264:75706, Dec  7 2009, 18:43:55)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 13.04 + 158.00
171.03999999999999
>>> 13 +158
171
>>> 13.04 + 158.00
171.03999999999999
>>> 13.04 + 158
171.03999999999999
>>> 13.04 + 0
13.039999999999999
>>> 13.05 + 0
13.050000000000001
>>>

----------
components: None
messages: 99230
nosy: James.Sparenberg
severity: normal
status: open
title: Error in additon of decimal numbers
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Feb 11 19:57:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 11 Feb 2010 18:57:22 +0000
Subject: [New-bugs-announce] [issue7913] Enhance Cmd support for docstrings
	and document it.
In-Reply-To: <1265914642.07.0.496715269242.issue7913@psf.upfronthosting.co.za>
Message-ID: <1265914642.07.0.496715269242.issue7913@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Cmd currently has undocumented support for using the docstrings of 'do_' methods as the documentation for those methods.  This is a very convenient facility, except that it leads to documentation being printed with a lot of leading whitespace.

I propose to enhance the docstring support to strip the leading whitespace from the docstring, and to document this facility.  The proposed stripping algorithm is to strip a number of characters equal to the whitespace on the first non-blank line of the docstring.  This means that existing docstrings, which will typically start right after the first """, will be displayed as they were previously, but that a docstring can be formatted by starting the documentation on a new line after the """, and whitespace will be properly stripped.

Patch attached with test and documentation update.

----------
components: Library (Lib)
files: cmd_doctest_enhancement.patch
keywords: patch
messages: 99233
nosy: r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Enhance Cmd support for docstrings and document it.
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file16213/cmd_doctest_enhancement.patch

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

From report at bugs.python.org  Thu Feb 11 22:20:20 2010
From: report at bugs.python.org (Nick)
Date: Thu, 11 Feb 2010 21:20:20 +0000
Subject: [New-bugs-announce] [issue7914] IntVar() - AttributeError:
	'NoneType' object has no	attribute 'tk'
In-Reply-To: <1265923220.98.0.512228541049.issue7914@psf.upfronthosting.co.za>
Message-ID: <1265923220.98.0.512228541049.issue7914@psf.upfronthosting.co.za>


New submission from Nick <nick.allgood at gmail.com>:

I tried to run the attached code and it seems IntVar() dies in the Tkinter module. After discussion with several other coworkers they seem to agree this may be a bug in Tkinter. If you need more info feel free to let me know and I can help with further testing.

OS: Windows XP 32-bit SP2
Python: Python 3.1.1

Error:

Traceback (most recent call last):
  File "H:/code/python/hfprog_sounds/intvar-POC.py", line 3, in <module>
    num_good = IntVar()
  File "C:\Python31\lib\tkinter\__init__.py", line 265, in __init__
    Variable.__init__(self, master, value, name)
  File "C:\Python31\lib\tkinter\__init__.py", line 174, in __init__
    self._tk = master.tk
AttributeError: 'NoneType' object has no attribute 'tk'

----------
components: Tkinter
files: intvar-POC.py
messages: 99238
nosy: Plazma
severity: normal
status: open
title: IntVar() - AttributeError: 'NoneType' object has no attribute 'tk'
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file16214/intvar-POC.py

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

From report at bugs.python.org  Fri Feb 12 03:14:01 2010
From: report at bugs.python.org (Alex Coventry)
Date: Fri, 12 Feb 2010 02:14:01 +0000
Subject: [New-bugs-announce] [issue7915] A lists which list.sort seems to
	leave out of order.
In-Reply-To: <1265940841.24.0.429301296675.issue7915@psf.upfronthosting.co.za>
Message-ID: <1265940841.24.0.429301296675.issue7915@psf.upfronthosting.co.za>


New submission from Alex Coventry <throwaway at mit.edu>:

I feel like I must be on crack, here.  I apologize if  so.  English version: sorting this long list leaves in place element 580395, which is less than element 0.  Restricting to a list of just those two elements, sorting does what I'd expect.

met% python2.6                                             # This problem also happens with 2.5
Python 2.6b1+ (trunk:64955, Jul 14 2008, 17:23:39) 
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, cPickle
>>> t = cPickle.load(os.popen('gunzip -c list.pickle.gz')) # Load the pickle in.  It's a list of pairs of numbers
>>> t.sort()                                               # Sort the pickle
>>> t[580395] < t[0]                                       # It's not in order!
True
>>> u = [t[0], t[580395]]                                  # Make a list of just the two compared elements and sort
>>> u.sort()
>>> u == [t[580395], t[0]]                                 # Now it's in order!
True
>>>

----------
files: list.pickle.gz
messages: 99249
nosy: throwaway
severity: normal
status: open
title: A lists which list.sort seems to leave out of order.
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file16216/list.pickle.gz

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

From report at bugs.python.org  Fri Feb 12 11:38:00 2010
From: report at bugs.python.org (Matt Joiner)
Date: Fri, 12 Feb 2010 10:38:00 +0000
Subject: [New-bugs-announce] [issue7916] zipfile.ZipExtFile passes long to
	fileobj.read()
In-Reply-To: <1265971080.38.0.966459739534.issue7916@psf.upfronthosting.co.za>
Message-ID: <1265971080.38.0.966459739534.issue7916@psf.upfronthosting.co.za>


New submission from Matt Joiner <anacrolix at gmail.com>:

When reading from the fileobj passed in it's constructor, zipfile.ZipExtFile passes a long into fileobj.read(). This is not normally an issue, except in io.BytesIO, for which the source is in C, and throws TypeError for type(bufsize) != int.

>From what I can ascertain from the source, io.BytesIO.read() only expects an int because this type is merged with long in Python3*. I also believe io.BytesIO may have been backported and so this difference in the treatment of int and long was not picked up.

I have attached a test demonstrating the type failure, with comments for it's testing under Python3, where this evidently doesn't occur. It also compares results with io.BytesIO's predecessors, StringIO and cStringIO.

I would attach a patch but I'm unsure of the general process, so here instead are relevant lines of interest from the 2.6.4 vanilla source:
zipfile.py:447 ZipExtFile.bytes_read is assigned a long
zipfile.py:594 a long is passed to a fileobj (such as io.BytesIO)
_bytesio.c:222 the type of the argument to io.BytesIO.read() is checked to be an int

----------
components: Library (Lib)
files: zipfile_testcase.py
messages: 99260
nosy: anacrolix
severity: normal
status: open
title: zipfile.ZipExtFile passes long to fileobj.read()
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file16217/zipfile_testcase.py

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

From report at bugs.python.org  Fri Feb 12 15:49:46 2010
From: report at bugs.python.org (Andrew Chong)
Date: Fri, 12 Feb 2010 14:49:46 +0000
Subject: [New-bugs-announce] [issue7917] list of list created by *
Message-ID: <1265986186.21.0.470269420598.issue7917@psf.upfronthosting.co.za>


Changes by Andrew Chong <sledge76 at hotmail.com>:


----------
nosy: sledge76
severity: normal
status: open
title: list of list created by *
versions: Python 2.6

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

From report at bugs.python.org  Fri Feb 12 18:29:07 2010
From: report at bugs.python.org (Oliver Jeeves)
Date: Fri, 12 Feb 2010 17:29:07 +0000
Subject: [New-bugs-announce] [issue7918] distutils always ignores compile
	errors
In-Reply-To: <1265995747.45.0.532654407664.issue7918@psf.upfronthosting.co.za>
Message-ID: <1265995747.45.0.532654407664.issue7918@psf.upfronthosting.co.za>


New submission from Oliver Jeeves <ojeeves at gmail.com>:

When trying to build a python package for distribution, compile errors are always ignored. The setup function will return successfully even if it was unable to compile some modules due to, for example, indentation errors.

The specific situation I'm trying to deal with, is a script that builds a large number of eggs, and trying to detect if something went wrong.

I see that this has been raised as a bug for setuptools:

http://bugs.python.org/setuptools/issue61

But it's not considered an issue because it's how distutils works.

distutils.util.byte_compile calls py_compile.compile, but does not pass a doraise argument to it.

The only suggestion for how to get tools that use distutils.util.byte_compile (like setuptools.setup and distutils.core.setup) to exit on an error is to monkey patch py_compile.compile to change its default doraise argument to True. That suggestion came from here:

http://stackoverflow.com/questions/2230843/how-can-i-detect-errors-programatically-when-building-an-egg-with-setuptools

supressing compile errors when making a distribution seems like a bug to me, but just having the option to easily change this behaviour would be great.

----------
assignee: tarek
components: Distutils
messages: 99273
nosy: Oliver.Jeeves, tarek
severity: normal
status: open
title: distutils always ignores compile errors
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Fri Feb 12 19:47:37 2010
From: report at bugs.python.org (ricitron)
Date: Fri, 12 Feb 2010 18:47:37 +0000
Subject: [New-bugs-announce] [issue7919] reading scientific notation using d
	instead of e on max	osx
In-Reply-To: <1266000457.34.0.289087845412.issue7919@psf.upfronthosting.co.za>
Message-ID: <1266000457.34.0.289087845412.issue7919@psf.upfronthosting.co.za>


New submission from ricitron <ricitron at mac.com>:

I would like to be able to read in data that uses scientific notation with a D instead of an E. This is possible on windows and other builds, but not on Mac OSX. 

example:
float('1.23D+04')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for float(): 1.23D+04

----------
assignee: ronaldoussoren
components: Macintosh
messages: 99281
nosy: ricitron, ronaldoussoren
severity: normal
status: open
title: reading scientific notation using d instead of e on max osx
type: feature request
versions: Python 2.5

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

From report at bugs.python.org  Fri Feb 12 22:44:44 2010
From: report at bugs.python.org (Andres Riancho)
Date: Fri, 12 Feb 2010 21:44:44 +0000
Subject: [New-bugs-announce] [issue7920] urllib2.HTTPRedirectHandler
	incorrect redirect
In-Reply-To: <1266011084.83.0.0326673543999.issue7920@psf.upfronthosting.co.za>
Message-ID: <1266011084.83.0.0326673543999.issue7920@psf.upfronthosting.co.za>


New submission from Andres Riancho <andresriancho at users.sourceforge.net>:

Buggy code:

"""
        if 'location' in headers:
            newurl = headers.getheaders('location')[0]
        elif 'uri' in headers:
            newurl = headers.getheaders('uri')[0]
        else:
            return
        newurl = urlparse.urljoin(req.get_full_url(), newurl)
"""        

You might end up being redirected to some "strange" location if for some reason the value of "location" is C:\boot.ini, and you urlparse.urljoin the current URL with that one, you end up with C:\boot.ini . When the urllib2 library opens that, it will open a local file. What I did to fix it, is to verify that the protocol of the newurl is http or https.

"""
        correct_protocol = newurl.startswith('http://')  or newurl.startswith('https://') 
        if not correct_protocol:
            return

"""

The fix should be applied just below the dangerous urlparse.urljoin.

----------
components: Library (Lib)
messages: 99292
nosy: andresriancho
severity: normal
status: open
title: urllib2.HTTPRedirectHandler incorrect redirect
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Fri Feb 12 23:19:25 2010
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Fri, 12 Feb 2010 22:19:25 +0000
Subject: [New-bugs-announce] [issue7921] executemany() link in
	Connection.executemany should point	to Cursor.executemany
In-Reply-To: <1266013165.58.0.187332799456.issue7921@psf.upfronthosting.co.za>
Message-ID: <1266013165.58.0.187332799456.issue7921@psf.upfronthosting.co.za>


New submission from Ville Skytt? <ville.skytta at iki.fi>:

http://docs.python.org/dev/library/sqlite3.html#sqlite3.Connection.executemany

The executemany() link in "... then calls the cursor?s executemany() method ..." points to Connection.executemany (itself), it should point to Cursor.executemany instead.

----------
assignee: georg.brandl
components: Documentation
messages: 99293
nosy: georg.brandl, scop
severity: normal
status: open
title: executemany() link in Connection.executemany should point to Cursor.executemany
versions: Python 3.2

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

From report at bugs.python.org  Sat Feb 13 02:56:56 2010
From: report at bugs.python.org (mike bayer)
Date: Sat, 13 Feb 2010 01:56:56 +0000
Subject: [New-bugs-announce] [issue7922] Python 3's 2to3 does not handle
	non-ascii source files
In-Reply-To: <1266026216.18.0.62051566691.issue7922@psf.upfronthosting.co.za>
Message-ID: <1266026216.18.0.62051566691.issue7922@psf.upfronthosting.co.za>


New submission from mike bayer <mike_mp at zzzcomputing.com>:

given the following Python 2 source file:

    # -*- encoding: utf-8

    print 'bien mang?'

It can be converted to Python 3 using 2's 2to3 tool:

    classic$ 2to3 test.py
     ... omitted ...
    --- test.py (original)
    +++ test.py (refactored)
    @@ -1,3 +1,3 @@
     # -*- encoding: utf-8
 
    -print 'bien mang?'
    +print('bien mang?')

However that of Python 3.1.1 fails:

    classic$ 2to3-3.1 test.py
       ... omitted ...
    --- test.py (original)
    +++ test.py (refactored)
    @@ -1,3 +1,3 @@
     # -*- encoding: utf-8
 
    Traceback (most recent call last):
      File "/usr/local/bin/2to3-3.1", line 6, in <module>
        sys.exit(main("lib2to3.fixes"))
      File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/lib2to3/main.py", line 159, in main
        options.processes)
      File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/lib2to3/refactor.py", line 616, in refactor
        items, write, doctests_only)
      File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/lib2to3/refactor.py", line 276, in refactor
        self.refactor_file(dir_or_file, write, doctests_only)
      File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/lib2to3/refactor.py", line 656, in refactor_file
        *args, **kwargs)
      File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/lib2to3/refactor.py", line 332, in refactor_file
        write=write, encoding=encoding)
      File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/lib2to3/refactor.py", line 432, in processed_file
        self.print_output(old_text, new_text, filename, equal)
      File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/lib2to3/main.py", line 64, in print_output
        print(line)
    UnicodeEncodeError: 'ascii' codec can't encode character '\xe9' in position 17: ordinal not in range(128)

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 99298
nosy: zzzeek
severity: normal
status: open
title: Python 3's 2to3 does not handle non-ascii source files
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Sat Feb 13 16:28:33 2010
From: report at bugs.python.org (Kirill)
Date: Sat, 13 Feb 2010 15:28:33 +0000
Subject: [New-bugs-announce] [issue7923] StreamHandler and FileHandler
	located in logging, not in logging.handlers
In-Reply-To: <1266074913.93.0.404685707573.issue7923@psf.upfronthosting.co.za>
Message-ID: <1266074913.93.0.404685707573.issue7923@psf.upfronthosting.co.za>


New submission from Kirill <tn at 0x746e.org.ua>:

Index: library/logging.rst
===================================================================
--- library/logging.rst (revision 78171)
+++ library/logging.rst (working copy)
@@ -1659,7 +1659,7 @@
 StreamHandler
 ^^^^^^^^^^^^^

-.. module:: logging.handlers
+.. currentmodule:: logging

 The :class:`StreamHandler` class, located in the core :mod:`logging` package,
 sends logging output to streams such as *sys.stdout*, *sys.stderr* or any
@@ -1731,6 +1731,8 @@

 .. versionadded:: 2.6

+.. currentmodule:: logging.handlers
+
 The :class:`WatchedFileHandler` class, located in the :mod:`logging.handlers`
 module, is a :class:`FileHandler` which watches the file it is logging to. If
 the file changes, it is closed and reopened using the file name.

----------
assignee: georg.brandl
components: Documentation
messages: 99319
nosy: georg.brandl, x746e
severity: normal
status: open
title: StreamHandler and FileHandler located in logging, not in logging.handlers
versions: Python 2.6

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

From report at bugs.python.org  Sat Feb 13 18:29:31 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 13 Feb 2010 17:29:31 +0000
Subject: [New-bugs-announce] [issue7924] test_capi crashes with misleading
	datetime ImportError	when _curses is not built
In-Reply-To: <1266082171.07.0.319986810998.issue7924@psf.upfronthosting.co.za>
Message-ID: <1266082171.07.0.319986810998.issue7924@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

This crash is sporadic on some buildbots where _curses is not built:

  test_capi
  XXX undetected error
  test test_capi crashed -- <class 'ImportError'>: No module named datetime

Note: the changeset r76810 did not fix the issue. It can be reverted.

The problem occurs during the test "test_capsule".
To reproduce: add a typo on "_curses" on line 1666.

Links:
 http://www.python.org/dev/buildbot/all/builders/sparc%20solaris10%20gcc%203.1/builds/237
 http://www.python.org/dev/buildbot/all/builders/sparc%20solaris10%20gcc%203.x/builds/353

----------
keywords: buildbot
messages: 99322
nosy: flox, mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: test_capi crashes with misleading datetime ImportError when _curses is not built
type: crash
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Feb 13 18:40:15 2010
From: report at bugs.python.org (Beau)
Date: Sat, 13 Feb 2010 17:40:15 +0000
Subject: [New-bugs-announce] [issue7925] minidom: "TypeError: writexml()
	takes at most 5	positional arguments (6 given)"
In-Reply-To: <1266082815.24.0.416556669247.issue7925@psf.upfronthosting.co.za>
Message-ID: <1266082815.24.0.416556669247.issue7925@psf.upfronthosting.co.za>


New submission from Beau <beaumartinez at gmail.com>:

When calling toprettyxml() from minidom.py, I get a TypeError stating that writexml() takes at most five positional arguments, but six are being passed.

----------
components: Library (Lib)
messages: 99323
nosy: beaumartinez
severity: normal
status: open
title: minidom: "TypeError: writexml() takes at most 5 positional arguments (6 given)"
type: compile error
versions: Python 3.1

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

From report at bugs.python.org  Sun Feb 14 07:53:14 2010
From: report at bugs.python.org (Edward Welbourne)
Date: Sun, 14 Feb 2010 06:53:14 +0000
Subject: [New-bugs-announce] [issue7926] Stray parentheses() in context
	manager "what's new" doc
In-Reply-To: <1266130394.53.0.910004543029.issue7926@psf.upfronthosting.co.za>
Message-ID: <1266130394.53.0.910004543029.issue7926@psf.upfronthosting.co.za>


New submission from Edward Welbourne <eddy at chaos.org.uk>:

http://docs.python.org/whatsnew/2.6.html#writing-context-managers
penultimate item in "A high-level explanation": <quote>
If BLOCK raises an exception, the __exit__(type, value, traceback)() is called 
</quote> has extra () after the argument list - this appears to say that __exit__ should return a callable, that shall be called with no parameters.  Fortunately, later example code reveals that __exit__ simply returns true or false.

http://docs.python.org/whatsnew/2.6.html#the-contextlib-module
after the first code block: <quote>
The contextlib module also has a nested(mgr1, mgr2, ...)() function 
</quote> again, stray () after parameter list.
After the next short code snippet: <quote>
Finally, the closing(object)() function returns ...
</quote>

----------
assignee: georg.brandl
components: Documentation
messages: 99336
nosy: eddy, georg.brandl
severity: normal
status: open
title: Stray parentheses() in context manager "what's new" doc
versions: Python 2.6

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

From report at bugs.python.org  Sun Feb 14 12:25:26 2010
From: report at bugs.python.org (=?utf-8?b?UMOpdGVyIFN6YWLDsw==?=)
Date: Sun, 14 Feb 2010 11:25:26 +0000
Subject: [New-bugs-announce] [issue7927] SSL socket is not closed properly
In-Reply-To: <1266146726.16.0.222413736354.issue7927@psf.upfronthosting.co.za>
Message-ID: <1266146726.16.0.222413736354.issue7927@psf.upfronthosting.co.za>


New submission from P?ter Szab? <ptspts at gmail.com>:

Here is how to reproduce:

import socket
import ssl
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sslsock = ssl.SSLSocket(sock)
assert sslsock._sslobj is None
sslsock.connect(('www.gmail.com', 443))
assert isinstance(sslsock._sslobj, socket._ssl.SSLType)
assert 0 == sslsock._makefile_refs
sslsock.makefile().close()
assert 1 == sslsock._makefile_refs  # Should be 0.
assert sslsock._sslobj is not None  # Should be None.

I think the problem is in SSLSocket.makefile, which initializes the _fileobject with close=False by default.

----------
components: Library (Lib)
messages: 99339
nosy: P?ter.Szab?
severity: normal
status: open
title: SSL socket is not closed properly
type: resource usage
versions: Python 2.6

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

From report at bugs.python.org  Sun Feb 14 12:29:06 2010
From: report at bugs.python.org (Edward Welbourne)
Date: Sun, 14 Feb 2010 11:29:06 +0000
Subject: [New-bugs-announce] [issue7928] String formatting: grammar wrongly
	limits [index] to	integer
In-Reply-To: <1266146946.63.0.7361643831.issue7928@psf.upfronthosting.co.za>
Message-ID: <1266146946.63.0.7361643831.issue7928@psf.upfronthosting.co.za>


New submission from Edward Welbourne <eddy at chaos.org.uk>:

http://docs.python.org/library/string.html#formatstrings
field_name        ::=  (identifier | integer) ("." attribute_name | "[" element_index "]")*
element_index     ::= integer

Subsequent text indicates __getitem__() is used but does not overtly say that a string can be used; but
http://docs.python.org/whatsnew/2.6.html#pep-3101-advanced-string-formatting
gives the example
>>> 'Content-type: {0[.mp4]}'.format(mimetypes.types_map)
and clearly '.mp4' is passed to __getitem__(); a string, not an integer.

Clearly one of these is wrong !
Given that the "what's new" doc goes into some detail about how the content of [...] gets parsed, I'm guessing it's right and the grammar is wrong.

----------
assignee: georg.brandl
components: Documentation
messages: 99340
nosy: eddy, georg.brandl
severity: normal
status: open
title: String formatting: grammar wrongly limits [index] to integer
versions: Python 2.6

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

From report at bugs.python.org  Mon Feb 15 00:02:49 2010
From: report at bugs.python.org (Michael Newman)
Date: Sun, 14 Feb 2010 23:02:49 +0000
Subject: [New-bugs-announce] [issue7930] pydoc.stripid doesn't strip ID in
	py25, py26, py31
In-Reply-To: <1266188569.95.0.344878906132.issue7930@psf.upfronthosting.co.za>
Message-ID: <1266188569.95.0.344878906132.issue7930@psf.upfronthosting.co.za>


New submission from Michael Newman <michael.b.newman at gmail.com>:

I found that pydoc.stripid doesn't strip the ID in Python 2.5, 2.6, and 3.1. I assume the problem is probably present in 2.7 and 3.2/dev.

For a little history, see this older issue back for Python 2.3:
http://bugs.python.org/issue934282

The following example show "pydoc.stripid" works for Python 2.3 and 2.4, but then fails for versions after that.

Python 2.3.5 (#62, Feb  8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import pydoc
>>> pydoc.stripid
<function stripid at 0x00AC0BB0>
>>> pydoc.stripid(repr(pydoc.stripid))
'<function stripid>'

Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import pydoc
>>> pydoc.stripid
<function stripid at 0x00BB7BF0>
>>> pydoc.stripid(repr(pydoc.stripid))
'<function stripid>'

Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import pydoc
>>> pydoc.stripid
<function stripid at 0x00BEFCF0>
>>> pydoc.stripid(repr(pydoc.stripid))
'<function stripid at 0x00BEFCF0>'

Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import pydoc
>>> pydoc.stripid
<function stripid at 0x00C655B0>
>>> pydoc.stripid(repr(pydoc.stripid))
'<function stripid at 0x00C655B0>'

Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import pydoc
>>> pydoc.stripid
<function stripid at 0x00CFB8A0>
>>> pydoc.stripid(repr(pydoc.stripid))
'<function stripid at 0x00CFB8A0>'

----------
components: Library (Lib)
messages: 99349
nosy: mnewman
severity: normal
status: open
title: pydoc.stripid doesn't strip ID in py25, py26, py31
type: behavior
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/issue7930>
_______________________________________

From report at bugs.python.org  Mon Feb 15 02:05:07 2010
From: report at bugs.python.org (tholzer)
Date: Mon, 15 Feb 2010 01:05:07 +0000
Subject: [New-bugs-announce] [issue7932] print statement delayed IOError
	when stdout has been	closed
In-Reply-To: <1266195907.59.0.6287236457.issue7932@psf.upfronthosting.co.za>
Message-ID: <1266195907.59.0.6287236457.issue7932@psf.upfronthosting.co.za>


New submission from tholzer <tholzer at wetafx.co.nz>:

When printing to a closed stdout file descriptor, the print statement only raises an IOError at character 8192. 

The expected behaviour is that IOError gets raised immediately (i.e. on the first character). Compare this behaviour to writing to a closed sys.stderr.

To reproduce (using bash):

<pre>
# python -V
Python 2.6.4

# python -c 'print "x" * 8191' 1>&- ; echo $?
close failed in file object destructor:
Error in sys.excepthook:

Original exception was:
0

# python -c 'print "x" * 8192' 1>&- ; echo $?
Traceback (most recent call last):
  File "<string>", line 1, in <module>
IOError: [Errno 9] Bad file descriptor
1
</pre>

----------
components: Interpreter Core
messages: 99351
nosy: tholzer
severity: normal
status: open
title: print statement delayed IOError when stdout has been closed
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Feb 15 14:38:19 2010
From: report at bugs.python.org (Kent Johnson)
Date: Mon, 15 Feb 2010 13:38:19 +0000
Subject: [New-bugs-announce] [issue7935] Cross-reference ast.literal_eval()
	from eval() docs
In-Reply-To: <1266241099.84.0.200250637967.issue7935@psf.upfronthosting.co.za>
Message-ID: <1266241099.84.0.200250637967.issue7935@psf.upfronthosting.co.za>


New submission from Kent Johnson <kent at kentsjohnson.com>:

eval() is a known security hole. Since Python 2.6 ast.literal_eval() provides a better alternative in many cases. literal_eval() is not as well known as eval() and not easy to find even if you know it exists (but don't remember the name).

eval() comes up over and over in the Python-tutor list and the attendant warnings are repeated ad nauseum; literal_eval() is rarely mentioned as an alternative.

Suggestion: in the docs for eval(), put a warning about security risks and a cross-reference to literal_eval(). For example:

Warning: eval() executes any expression and should be used only with trusted input. ast.literal_eval() is a safe alternative for evaluating expressions containing only Python literals.

Thanks!

----------
assignee: georg.brandl
components: Documentation
messages: 99363
nosy: georg.brandl, kjohnson
severity: normal
status: open
title: Cross-reference ast.literal_eval() from eval() docs
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Mon Feb 15 20:07:20 2010
From: report at bugs.python.org (JT Johnson)
Date: Mon, 15 Feb 2010 19:07:20 +0000
Subject: [New-bugs-announce] [issue7936] sys.argv contains only scriptname
In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>
Message-ID: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>


New submission from JT Johnson <svedgeburn at gmail.com>:

I am running Python 2.6.4 on Windows Vista and when I try to get any command line arguments via sys.argv, it only contains sys.argv[0], but nothing else. Even if I supply several parameters. The only third-parts modules I am using are Pygame, but even before Pygame imports, there is nothing in sys.argv. I've tried creating a shortcut with the args in it, but it still doesn't work.
Note that I also have a couple other Python versions installed (2.5, 2.7a, and 3.1) maybe somehow they are conflicting?

----------
components: IO
messages: 99367
nosy: JT.Johnson
severity: normal
status: open
title: sys.argv contains only scriptname
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Feb 16 01:44:32 2010
From: report at bugs.python.org (Willem de Bruijn)
Date: Tue, 16 Feb 2010 00:44:32 +0000
Subject: [New-bugs-announce] [issue7938] makesetup interprets macros -DA=B
	as a Make variable	definition
In-Reply-To: <1266281072.48.0.268109023834.issue7938@psf.upfronthosting.co.za>
Message-ID: <1266281072.48.0.268109023834.issue7938@psf.upfronthosting.co.za>


New submission from Willem de Bruijn <wdebruij at dds.nl>:

(this is very low priority: an issue in a nonstandard build)

I am porting Python 2.6.4 to a system with only partial Posix support that requires static linking for all modules. To enable sqlite, I added the line 

_sqlite3 _sqlite/cache.c _sqlite/connection.c _sqlite/cursor.c _sqlite/microprotocols.c _sqlite/module.c _sqlite/prepare_protocol.c _sqlite/row.c _sqlite/statement.c _sqlite/util.c -DMODULE_NAME='"sqlite3"' -IModules/_sqlite ...

to Modules/Setup, but found that it would not end up in the main binary. Instead of adding it to MODOBJS, makesetup put it in BASEMODLIBS

The problem occurs in Modules/makesetup, line 131, which matches all lines containing "=" and treats them as Make definitions. In this case, it matches the equal sign in the C macro MODULE_NAME. 

The problem goes away when I tighten the check at that line:

-		*=*)	DEFS="$line$NL$DEFS"; continue;;
+		[[:alpha:]]*=*) DEFS="$line$NL$DEFS"; continue;;

(see the attached file for the trivial patch in diff -Nur format)

This patch comes with a big warning: my sh-regex foo is very poor. I wanted to write a test that only accepted ^[:alpha:][^ ]*=*, but that
did not work. The above did, but I cannot oversee all consequences.

cheers,

  Willem

----------
components: Build
files: pydiff
messages: 99378
nosy: wdebruij
severity: normal
status: open
title: makesetup interprets macros -DA=B as a Make variable definition
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file16227/pydiff

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

From report at bugs.python.org  Tue Feb 16 13:44:49 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 16 Feb 2010 12:44:49 +0000
Subject: [New-bugs-announce] [issue7939] subprocess: call([arg, arg2],
	shell=True) vs call(arg+" "+arg2, shell=True)
In-Reply-To: <1266324289.38.0.202378770436.issue7939@psf.upfronthosting.co.za>
Message-ID: <1266324289.38.0.202378770436.issue7939@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

subprocess.call([arg, arg2], shell=True)  is different from subprocess.call(arg+" "+arg2, shell=True)

The last one executed correctly, the first one fails on Python 2.5.2 Debian Lenny. Why these should be different? Seems like a bug to me.

----------
components: Library (Lib)
messages: 99401
nosy: techtonik
severity: normal
status: open
title: subprocess: call([arg, arg2], shell=True) vs call(arg+" "+arg2, shell=True)
versions: Python 2.5

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

From report at bugs.python.org  Tue Feb 16 18:36:41 2010
From: report at bugs.python.org (Paul Boddie)
Date: Tue, 16 Feb 2010 17:36:41 +0000
Subject: [New-bugs-announce] [issue7942] Inconsistent error types/messages
	for __len__ between old	and new-style classes
In-Reply-To: <1266341801.65.0.120911514825.issue7942@psf.upfronthosting.co.za>
Message-ID: <1266341801.65.0.120911514825.issue7942@psf.upfronthosting.co.za>


New submission from Paul Boddie <paul at boddie.org.uk>:

As noted here:

http://www.selenic.com/pipermail/mercurial/2010-February/030068.html

This is probably documented somewhere, and there may even be a good reason for the difference, but old-style classes raise TypeError when __len__ returns a non-int, whereas new-style classes raise OverflowError. The latter is probably just as valid, but the message is a bit obscure for debugging purposes.

Maybe this went away after 2.5 - if so, sorry for the noise!

Here's an illustration of the problem:

Python 2.5.4 (r254:67916, Nov  4 2009, 17:59:46)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-46)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class C:
...     def __len__(self):
...             return 2**35
...
>>> c = C()
>>> len(c)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __len__() should return an int
>>> class C(object):
...     def __len__(self):
...             return 2**35
...
>>> c = C()
>>> len(c)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: long int too large to convert to int

----------
components: Interpreter Core
messages: 99421
nosy: pboddie
severity: normal
status: open
title: Inconsistent error types/messages for __len__ between old and new-style classes
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Tue Feb 16 18:38:32 2010
From: report at bugs.python.org (=?utf-8?b?UMOpdGVyIFN6YWLDsw==?=)
Date: Tue, 16 Feb 2010 17:38:32 +0000
Subject: [New-bugs-announce] [issue7943] Memory leak due to circular
	references in ssl.SSLSocket
In-Reply-To: <1266341912.31.0.218071173939.issue7943@psf.upfronthosting.co.za>
Message-ID: <1266341912.31.0.218071173939.issue7943@psf.upfronthosting.co.za>


New submission from P?ter Szab? <ptspts at gmail.com>:

Here is how to reproduce the leak in Python 2.6.4 and Python 2.7:

  import gc
  import socket
  import ssl
  sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
  gc.disable()
  gc.collect()
  count0 = gc.get_count()[0]
  for i in xrange(1000):
    ssl.SSLSocket(sock)
  count1 = gc.get_count()[0]
  # This should be less than 100 without the leak, but it is >1000.
  diff = count1 - count0
  assert diff < 1000, diff

The reason why the memory usage has increased is that the SSLSocket objects contain a circular reference (self -> __init__ ->  recv -> lambda -> self), and thus Python cannot free them without garbage collection.

A side effect is that if the SSLSocket doesn't have external references, the underlying socket._realsocket may remain unclosed for a long time (until the garbage collection kicks in), because the SSLSocket still refers to it. Another side effect is that when there is an exception in the wrapping in SSLSocket.accept() (e.g. keyfile not found), then the newly accepted socket won't get closed immediately, and the client will experience a hanging open socket.

With gc.enable(), the leak goes away (the garbage collector finds and frees the SSLSocket objects with circular reference). Python 3.1.1 is not affected since it has a very different SSLSocket implementation.

Here is an easy fix: replace the self.recv = lambda ... lines in the code of ssl.SSLSocket.__init__ with this:

  import socket as socket_module
  for attr in socket_module._delegate_methods:
    delattr(self, attr)  

See the attached patch. You can also download the patch from http://code.google.com/p/pts-mini-gpl/source/browse/trunk/patches/pts-python2.6.4-ssl-init-memory-leak-fix.patch

----------
components: IO, Library (Lib)
files: pts-python2.6.4-ssl-init-memory-leak-fix.patch
keywords: patch
messages: 99423
nosy: P?ter.Szab?
severity: normal
status: open
title: Memory leak due to circular references in ssl.SSLSocket
type: resource usage
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file16234/pts-python2.6.4-ssl-init-memory-leak-fix.patch

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

From report at bugs.python.org  Tue Feb 16 18:43:51 2010
From: report at bugs.python.org (Dave Fugate)
Date: Tue, 16 Feb 2010 17:43:51 +0000
Subject: [New-bugs-announce] [issue7944] Use the 'with' statement in
	conjunction with 'open'	throughout test modules
In-Reply-To: <1266342231.42.0.692171370087.issue7944@psf.upfronthosting.co.za>
Message-ID: <1266342231.42.0.692171370087.issue7944@psf.upfronthosting.co.za>


New submission from Dave Fugate <dfugate at microsoft.com>:

Sprinkled throughout CPython's test modules are snippets of code such as the following taken from 2.7A3's test_old_mailbox.py (line 141):
    box = mailbox.UnixMailbox(open(self._path, 'r'))

The key thing to observe here is the file being opened yet never has it's 'close' method explicitly called.  While this is fine for CPython's rather predictable garbage collections, it's quite possible that in alternate implementations of Python this file object won't be destroyed until well after line 141.  This can result in seemingly random failures of CPython's tests under alternate implementations of Python.

The solution to this problem would be to consistently use the 'with' statement (or alternatively close all open file objects) throughout all CPython test modules.

I've gone ahead and submitted an updated (2.7A3) version of test_old_mailbox.py which addresses this.  We can find other places where this is going on as well, but for the most part the tests already seem to be doing the right thing.

----------
components: Tests
files: test_old_mailbox.py
messages: 99425
nosy: midnightdf
severity: normal
status: open
title: Use the 'with' statement in conjunction with 'open' throughout test modules
type: feature request
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file16235/test_old_mailbox.py

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

From report at bugs.python.org  Tue Feb 16 19:20:20 2010
From: report at bugs.python.org (kenneth dombrowski)
Date: Tue, 16 Feb 2010 18:20:20 +0000
Subject: [New-bugs-announce] [issue7945] typo in operator.isCallable
	deprecation warning
In-Reply-To: <1266344420.98.0.249728155986.issue7945@psf.upfronthosting.co.za>
Message-ID: <1266344420.98.0.249728155986.issue7945@psf.upfronthosting.co.za>


New submission from kenneth dombrowski <kenneth-python at ylayali.net>:

The operator documentation @ http://docs.python.org/library/operator.html states for operator.isCallable(obj): "Deprecated since version 2.0: Use isinstance(x, collections.Callable) instead.", I believe this should read since version 2.6

kenneth at dev2 ~ $ python
Python 2.5.4 (r254:67916, Oct  3 2009, 21:36:21)
[GCC 3.4.6 [FreeBSD] 20060305] on freebsd6
Type "help", "copyright", "credits" or "license" for more information.

>>> import collections
>>> collections.Callable
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'Callable'

----------
assignee: georg.brandl
components: Documentation
messages: 99433
nosy: georg.brandl, kennethd
severity: normal
status: open
title: typo in operator.isCallable deprecation warning
versions: Python 2.6

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

From report at bugs.python.org  Tue Feb 16 21:48:45 2010
From: report at bugs.python.org (David Beazley)
Date: Tue, 16 Feb 2010 20:48:45 +0000
Subject: [New-bugs-announce] [issue7946] Convoy effect with I/O bound
	threads and New GIL
In-Reply-To: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>
Message-ID: <1266353325.38.0.278549753357.issue7946@psf.upfronthosting.co.za>


New submission from David Beazley <dave at dabeaz.com>:

Background
-----------
In order to multitask with threads, a critical part of the Python
interpreter implementation concerns the behavior of I/O operations
such as read, write, send, and receive.  Specifically, whenever an I/O
operation is carried out, the interpreter releases the GIL so that
other threads can run while the program waits for the I/O operation to
complete.

Observed Behavior of I/O Operations
------------------------------------
The release of the GIL for I/O is a critical aspect of making sure the
interpreter doesn't make all threads hang while waiting.  However, the
release of the GIL also assumes a worst-case scenario.  In practice,
a large number of I/O requests actually complete immediately with no
actual blocking.  For example, if a program is sending on a socket,
send() operations will typically complete immediately if buffer space
is available to accept the data.  Likewise, read() and recv()
operations may return immediately if data is already available in the
operating system.

For system calls that complete immediately, a thread quickly releases
and then almost immediately reacquires the GIL to continue running.
However, given that the I/O operation didn't block, the release of the
GIL was technically unnecessary in this case.

Behavior of the new GIL
-----------------------
A feature of the new Python GIL implementation is that the interpreter
no longer periodically signals waiting threads (e.g., the check
interval).  Instead, thread switching is based on a timed wait on a
condition variable. Should a timeout occur, a thread will indicate
that it wants the GIL and the currently running thread will be forced
to give it up.

Although this scheme solves the problem of CPU-bound threads
thrashing, it introduces a highly pronounced "convoy effect" when
CPU-bound threads and I/O bound threads get mixed together.  A major
part of the problem is caused by the bahvior of I/O as described
above.  Specifically, when an I/O bound thread executes an I/O call,
it always releases the GIL.  Since the GIL is released, a CPU bound
thread is now free to acquire the GIL and run.  However, if the I/O
call completes immediately (which is common), the I/O bound thread
immediately stalls upon return from the system call.  To get the GIL
back, it now has to go through the timeout process to force the
CPU-bound thread to release the GIL again.

It should be noted that the behavior described also occurs in Python
2, but due to the small check interval, an I/O bound thread that wants
the GIL back will tend to get it without having to wait very long.

Example
-------
Here is a very simple example that illustrates the problem.  In this
example, there is one CPU-bound thread that hammers the CPU and there
is an I/O bound thread that handles some network communication (an
echo server):

# iotest.py
import time
import threading
from socket import *

# CPU-bound thread (just hammers the CPU)
def spin():
    while True:
        pass

# I/O-bound thread (an echo TCP server)
def echo_server():
    s = socket(AF_INET, SOCK_STREAM)
    s.setsockopt(SOL_SOCKET, SO_REUSEADDR,1)
    s.bind(("",15000))
    s.listen(1)
    while True:
        c,a = s.accept()
        while True:
            data = c.recv(8192)
            if not data:
                break
            c.sendall(data)
        c.close()
    s.close()

# Launch the CPU-bound thread
t1 = threading.Thread(target=spin)
t1.daemon=True
t1.start()

# Run the I/O server
echo_server()

Here is a benchmark program that runs as a client for the echo_server()
thread defined above.  It sends a sequence of messages and reads the
response back.  It then reports some timings at the end.

# echoclient.py
from socket import *
import time

CHUNKSIZE = 16384
NUMMESSAGES = 640     # Total of 10MB

# Dummy message
msg = b"x"*CHUNKSIZE

# Connect and send messages
s = socket(AF_INET,SOCK_STREAM)
s.connect(("",15000))
start = time.time()
for n in range(NUMMESSAGES):
    s.sendall(msg)
    bytes_recv = len(msg)
    # Get the response back
    while bytes_recv > 0:
        data = s.recv(bytes_recv)
        bytes_recv -= len(data)
s.close()
end = time.time()
print("%0.3f seconds (%0.3f bytes/sec)" % (end-start, (CHUNKSIZE*NUMMESSAGES)/(end-start)))

Performance Results
-------------------
These results are from running the above programs on a dual-core
MacBook running OS-X Snow Leopard.  I also get similar behavior on a
quad-core desktop machine.

If you run the iotest.py program using Python 2.6.4 and execute
the client, you get this result:

   bash % python echoclient.py
   1.064 seconds (9854148.739 bytes/sec)

If you switch the iotest.py to Python 3.2 and rerun, you get this
result:

   bash % python echoclient.py
   12.340 seconds (849726.150 bytes/sec)

Notice that there is a factor 12 performance difference.

Modify the iotest.py program so that there are 2 CPU-bound
threads spinning.  Just add this extra code:

    t2 = threading.Thread(target=spin)
    t2.daemon
    t2.start()

Now, repeat the above tests.    For Python 2.6.4, you get this:

    bash-3.2$ python echoclient.py
    0.358 seconds (29319821.410 bytes/sec)

(Yes the performance actually improves!  That's left as an exercise
for the reader to figure out why)

Now, switch the iotest.py server to Python 3.2 and retry:

    base-3 $ python echoclient.py
    59.545 seconds (176098.609 bytes/sec)    

Notice how the addition of one CPU-bound thread made the time go up by
more than a factor 4!

Now, disable all but one of the CPU cores and try the test again in
Python 3.2:

    bash-3.2$ python echoclient.py
    0.120 seconds (87246036.201 bytes/sec)

Here, you see that it runs about 500 times faster than with two cores
(yikes!)

What's causing this behavior?
-----------------------------
In the iotest.py program, there is an inner loop that
looks like this:

        while True:
            data = c.recv(8192)
            if not data:
                break
            c.sendall(data)

The I/O operations recv() and sendall() always release the GIL when
they execute.  However, when this happens, CPU bound threads jump in
and start running again. The problem gets worse as the number of
CPU-bound threads increases--CPU bound threads might cycle round-robin
before the I/O bound thread runs again.  The problem is more
pronounced on multiple CPU cores because when the GIL is released, one
of the cores will typically go handle the system call while the other
core wakes up the waiting CPU-bound thread (which then almost
immediately steals the GIL).

Is it worth fixing?
-------------------
I claim yes.  There are many applications, such as those carried
out with the multiprocessing library, that will operate by trying
to overlap computation and I/O in some manner (for example, receiving
the next chunk of data to work on while carrying out calculations
on the currently received data).

In heavily loaded I/O bound applications such as servers with 
hundreds of simultaneously connected clients, the release of the GIL
on short I/O operations may cause a lot of unintended thrashing
as threads cycle amongst themselves.    This would most likely
manifest itself as an increased turnaround time for requests.

How to fix?
-----------
Modify all I/O operations in the interpreter to not release the
GIL if they won't block.  Either that or maybe there's some sort of
really sneaky easy solution (unknown).

The effect can be minimized by setting the switch interval to a really
small value using sys.setswitchinterval().   However, doing this
greatly increases the amount of thread context-switching--something
that's also undesirable.

----------
components: Interpreter Core
files: issuegil.txt
messages: 99438
nosy: dabeaz
severity: normal
status: open
title: Convoy effect with I/O bound threads and New GIL
versions: Python 3.2
Added file: http://bugs.python.org/file16238/issuegil.txt

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

From report at bugs.python.org  Wed Feb 17 02:42:20 2010
From: report at bugs.python.org (panzi)
Date: Wed, 17 Feb 2010 01:42:20 +0000
Subject: [New-bugs-announce] [issue7948] Complete your registration to
	Python tracker --	key	yAMyUeuHR9LS2Q86aUUs2GO4rujOhgWH
In-Reply-To: <20100217013518.345E9780CB@psf.upfronthosting.co.za>
Message-ID: <4B7B4978.6050804@gmx.net>


New submission from panzi <grosser.meister.morti at gmx.net>:

On 02/17/2010 02:35 AM, Python tracker wrote:
> To complete your registration of the user "panzi" with
> Python tracker, please do one of the following:
>
> - send a reply to report at bugs.python.org and maintain the subject line as is (the
> reply's additional "Re:" is ok),
>
> - or visit the following URL:
>
> http://bugs.python.org/?@action=confrego&otk=yAMyUeuHR9LS2Q86aUUs2GO4rujOhgWH
>

----------
messages: 99455
nosy: panzi
severity: normal
status: open
title: Complete your registration to Python tracker -- key	yAMyUeuHR9LS2Q86aUUs2GO4rujOhgWH

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

From report at bugs.python.org  Wed Feb 17 03:01:53 2010
From: report at bugs.python.org (=?utf-8?q?Mathias_Panzenb=C3=B6ck?=)
Date: Wed, 17 Feb 2010 02:01:53 +0000
Subject: [New-bugs-announce] [issue7949] idle does not handle dark gtk color
	schemes
In-Reply-To: <1266372113.11.0.0197701157976.issue7949@psf.upfronthosting.co.za>
Message-ID: <1266372113.11.0.0197701157976.issue7949@psf.upfronthosting.co.za>


New submission from Mathias Panzenb?ck <grosser.meister.morti at gmx.net>:

Idle sets *some* colors to hardcoded values and uses the system defaults for other colors. This is extremely bad when you use a dark gtk color scheme and now a almost white text (system text color) is displayed on a white background (idle tooltip background color).

There are two solutions to the problem: Also set the foreground color to a hardcoded value or better detect whether the foreground color is bright or dark and choose an appropriate background color. I've implemented the latter for the idle that comes with fedora 12 (2.6.2). I forgot to backup the original files so I can't make a diff/patch. However, I attached the changed files and here is a summary of my changes:

in idlelib/ToolTip.py:
added functions:
   parse_color(color)
   set_tooltip_bg(widget)

in ToolTipBase.showcontents():
   set_tooltip_bg(label)

in ListboxToolTip.showcontents():
   set_tooltip_bg(listbox)

in idlelib/AutoCompleteWindow.py:
added:
   from ToolTip import set_tooltip_bg

in AutoCompleteWindow.show_window():
   set_tooltip_bg(listbox)

in idlelib/CallTipWindow.py:
added:
   from ToolTip import set_tooltip_bg

in CallTip.showtip():
   set_tooltip_bg(self.label)

----------
components: IDLE
files: idlelib.zip
messages: 99457
nosy: panzi
severity: normal
status: open
title: idle does not handle dark gtk color schemes
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file16240/idlelib.zip

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

From report at bugs.python.org  Wed Feb 17 11:15:59 2010
From: report at bugs.python.org (Christoph Neuroth)
Date: Wed, 17 Feb 2010 10:15:59 +0000
Subject: [New-bugs-announce] [issue7950] subprocess.Popen documentation
	should contain a good	warning about the security implications
	when using shell=True
In-Reply-To: <1266401759.12.0.600282213979.issue7950@psf.upfronthosting.co.za>
Message-ID: <1266401759.12.0.600282213979.issue7950@psf.upfronthosting.co.za>


New submission from Christoph Neuroth <christoph.neuroth at googlemail.com>:

Currently, the documentation of subprocess only says "Calling the program through the shell is usually not required.". IMHO there should be a real warning (like, in its own box with a couple of big exclamation marks ;)) about the security implications of using this and detailed instructions of how to avoid it. People tend to use this functionality just because they "know how to use the shell" and its just so convenient - and by doing so they create huge security holes in their applications.

----------
assignee: georg.brandl
components: Documentation
messages: 99465
nosy: christoph.neuroth, georg.brandl
severity: normal
status: open
title: subprocess.Popen documentation should contain a good warning about the security implications when using shell=True
type: security
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Thu Feb 18 00:54:19 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 17 Feb 2010 23:54:19 +0000
Subject: [New-bugs-announce] [issue7951] Should str.format allow negative
	indexes when used for	__getitem__ access?
In-Reply-To: <1266450859.13.0.906832569526.issue7951@psf.upfronthosting.co.za>
Message-ID: <1266450859.13.0.906832569526.issue7951@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

It surprised me that this doesn't work:
>>> "{0[-1]}".format('fox')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: string indices must be integers

I was expecting it to be equivalent to:

>>> "{0[2]}".format('fox')
'x'

I don't think there's any particular reason this doesn't work. It would, however break the following code:

>>> "{0[-1]}".format({'-1':'foo'})
'foo'

But note that this doesn't work currently:

>>> "{0[1]}".format({'1':'foo'})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 1

----------
assignee: eric.smith
components: Interpreter Core
keywords: easy
messages: 99482
nosy: eric.smith
priority: normal
severity: normal
status: open
title: Should str.format allow negative indexes when used for __getitem__ access?
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Feb 18 01:21:55 2010
From: report at bugs.python.org (David-Sarah Hopwood)
Date: Thu, 18 Feb 2010 00:21:55 +0000
Subject: [New-bugs-announce] [issue7952] fileobject.c can switch between
	fread and fwrite without	an intervening flush or seek,
	invoking undefined behaviour
In-Reply-To: <1266452515.1.0.187008145606.issue7952@psf.upfronthosting.co.za>
Message-ID: <1266452515.1.0.187008145606.issue7952@psf.upfronthosting.co.za>


New submission from David-Sarah Hopwood <david-sarah at jacaranda.org>:

The C standard (any version, or POSIX), says in the description of fopen that:
{{{
When a file is opened with update mode ( '+' as the second or third character in the mode argument), both input and output may be performed on the associated stream. However, the application shall ensure that output is not directly followed by input without an intervening call to fflush() or to a file positioning function ( fseek(), fsetpos(), or rewind()), and input is not directly followed by output without an intervening call to a file positioning function, unless the input operation encounters end-of-file.
}}}

Objects/fileobject.c makes calls to fread and fwrite without taking this into account. So calls from Python to read or write methods of a file object opened in any "rw" mode, may invoke undefined behaviour. It isn't reasonable to rely on Python code to avoid this situation, even if were considered acceptable in C. (Arguably this is a bug in the C standard, but it is unlikely to be fixed there or in POSIX, because of differences in philosophy about language safety.)

To fix this, fileobject.c should keep track of whether the last I/O operation was an input or output, and perform a call to fflush whenever an input follows an output or vice versa. This should not significantly affect performance in any case where the behaviour was previously defined (in cases where it wasn't, correctness trumps performance). fflush does not affect the file position and should have no other negative effect, because the stdio implementation is free to flush buffered data at any time (and certainly on I/O operations).

Despite the undefined behaviour, I don't currently know of a platform where this would lead to an exploitable security bug. I'm marking this issue as security-relevant anyway, because it may prevent analysing whether Python applications behave securely only on the basis of documented behaviour.

----------
components: IO
messages: 99483
nosy: davidsarah
severity: normal
status: open
title: fileobject.c can switch between fread and fwrite without an intervening flush or seek, invoking undefined behaviour
type: security
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb 18 01:44:26 2010
From: report at bugs.python.org (Andrew McNabb)
Date: Thu, 18 Feb 2010 00:44:26 +0000
Subject: [New-bugs-announce] [issue7953] RawIOBase.read fails with an
	AttributeError
In-Reply-To: <1266453866.93.0.344169930807.issue7953@psf.upfronthosting.co.za>
Message-ID: <1266453866.93.0.344169930807.issue7953@psf.upfronthosting.co.za>


New submission from Andrew McNabb <amcnabb at mcnabbs.org>:

I was trying to open stdin in binary mode and ran the following:

>>> RawIOBase(sys.stdin.fileno()).read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'RawIOBase' object has no attribute 'readinto'
>>>

I would expect read() to read data instead of crashing.

----------
components: IO
messages: 99484
nosy: amcnabb
severity: normal
status: open
title: RawIOBase.read fails with an AttributeError
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Thu Feb 18 01:53:43 2010
From: report at bugs.python.org (Andrew McNabb)
Date: Thu, 18 Feb 2010 00:53:43 +0000
Subject: [New-bugs-announce] [issue7954] detach method has no docstring
In-Reply-To: <1266454423.14.0.91704717974.issue7954@psf.upfronthosting.co.za>
Message-ID: <1266454423.14.0.91704717974.issue7954@psf.upfronthosting.co.za>


New submission from Andrew McNabb <amcnabb at mcnabbs.org>:

The detach() method has no docstring, so it's impossible to find out about it with pydoc or help().  It would be great if the description were copied from the io library documentation.

For BufferedIOBase:

"""Separate the underlying raw stream from the buffer and return it.

After the raw stream has been detached, the buffer is in an unusable state."""

For TextIOBase:

"""Separate the underlying binary buffer from the TextIOBase and return it.

After the underlying buffer has been detached, the TextIOBase is in an unusable state."""

By the way, it's odd that detaching

----------
components: IO
messages: 99486
nosy: amcnabb
severity: normal
status: open
title: detach method has no docstring
versions: Python 3.1

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

From report at bugs.python.org  Thu Feb 18 07:41:17 2010
From: report at bugs.python.org (Andrew McNabb)
Date: Thu, 18 Feb 2010 06:41:17 +0000
Subject: [New-bugs-announce] [issue7955] TextIOWrapper Buffering
	Inconsistent Between _io and _pyio
In-Reply-To: <1266475277.48.0.657351294204.issue7955@psf.upfronthosting.co.za>
Message-ID: <1266475277.48.0.657351294204.issue7955@psf.upfronthosting.co.za>


New submission from Andrew McNabb <amcnabb at mcnabbs.org>:

The following snippet behaves differently in the C IO implementation than in the Python IO implementation:

  import sys
  sys.stdout.write('unicode ')
  sys.stdout.buffer.write(b'bytes ')

To test this, I have created two scripts, testpyio.py (using _pyio) and testio.py (using _io).  The output is as follows:

% python3 testpyio.py
unicode bytes
% python3 testio.py
bytes unicode
%

In my opinion, the behavior exhibited by _pyio is more correct.  It appears that to get the C implementation to print the lines in the correct order, there must be a flush in between the statements.  This extra flush would create a lot of overhead.

I am attaching the two test scripts.

The C implementation prints the output in the correct order if each write ends with a newline.

----------
components: IO
files: testpyio.py
messages: 99496
nosy: amcnabb
severity: normal
status: open
title: TextIOWrapper Buffering Inconsistent Between _io and _pyio
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file16248/testpyio.py

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

From report at bugs.python.org  Thu Feb 18 13:26:54 2010
From: report at bugs.python.org (Michael Newman)
Date: Thu, 18 Feb 2010 12:26:54 +0000
Subject: [New-bugs-announce] [issue7956] unittest.Testcase
	assertDictContainsSubset with integer	keys
In-Reply-To: <1266496014.66.0.425338547188.issue7956@psf.upfronthosting.co.za>
Message-ID: <1266496014.66.0.425338547188.issue7956@psf.upfronthosting.co.za>


New submission from Michael Newman <michael.b.newman at gmail.com>:

The attached example unit test file shows that assertDictContainsSubset cannot handle error messages that need to show integer keys. Below is the output of the test suite, where "test_mixed_keys_fail" has an error (code mistake), while "test_text_keys_fail" produces a failure (result mistake) as expected.

C:\notes>C:\Python31\python.exe test_one_and_one.py
.E.F
======================================================================
ERROR: test_mixed_keys_fail (__main__.Test_one_and_one)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_one_and_one.py", line 30, in test_mixed_keys_fail
    self.assertDictContainsSubset({3: "this does not exist"}, self.dict_with_mix
ed_keys)
  File "C:\python31\lib\unittest.py", line 908, in assertDictContainsSubset
    standardMsg = 'Missing: %r' % ','.join(missing)
TypeError: sequence item 0: expected str instance, int found

======================================================================
FAIL: test_text_keys_fail (__main__.Test_one_and_one)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_one_and_one.py", line 33, in test_text_keys_fail
    self.assertDictContainsSubset({"3": "this does not exist"}, self.dict_with_t
ext_keys)
AssertionError: Missing: '3'

----------------------------------------------------------------------
Ran 4 tests in 0.010s

FAILED (failures=1, errors=1)

----------
components: Library (Lib)
files: test_one_and_one.py
messages: 99500
nosy: mnewman
severity: normal
status: open
title: unittest.Testcase assertDictContainsSubset with integer keys
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16250/test_one_and_one.py

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

From report at bugs.python.org  Thu Feb 18 15:58:27 2010
From: report at bugs.python.org (Lucian Ursu)
Date: Thu, 18 Feb 2010 14:58:27 +0000
Subject: [New-bugs-announce] [issue7957] Tutorial issue regarding the sys
	module
In-Reply-To: <1266505107.41.0.314960086696.issue7957@psf.upfronthosting.co.za>
Message-ID: <1266505107.41.0.314960086696.issue7957@psf.upfronthosting.co.za>


New submission from Lucian Ursu <lucian_ursu at yahoo.com>:

Hello,

I've discovered an issue while reading the Python tutorial. In chapter 6.2. "Standard Modules", the tutorial mentions the "sys" module and two of its attributes, ps1='<<<' and ps2='...'. The problem is I can't find these attributes in my version of Python (2.6.4.) when I do "dir(sys)". Have these attributes been deprecated but not removed from the tutorial yet?
Thank you for your time.
Lucian

----------
assignee: georg.brandl
components: Documentation
messages: 99510
nosy: LucianU, georg.brandl
severity: normal
status: open
title: Tutorial issue regarding the sys module
versions: Python 2.6

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

From report at bugs.python.org  Thu Feb 18 16:29:57 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 18 Feb 2010 15:29:57 +0000
Subject: [New-bugs-announce] [issue7958] test_platform failure on OS X 10.6
In-Reply-To: <1266506997.43.0.181933833727.issue7958@psf.upfronthosting.co.za>
Message-ID: <1266506997.43.0.181933833727.issue7958@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

With a 64-bit debug non-framework builds of the trunk and py3k, on OS X 10.6, I'm consistently getting the following failure in test_platform:

trunk dickinsm$ ./python.exe Lib/test/regrtest.py -uall test_platform
test_platform
[18064 refs]
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/dickinsm/python/svn/trunk/Lib/platform.py", line 1017, in architecture
    import struct
  File "/Users/dickinsm/python/svn/trunk/Lib/struct.py", line 1, in <module>
    from _struct import *
ImportError: No module named _struct
[17485 refs]
test test_platform failed -- Traceback (most recent call last):
  File "/Users/dickinsm/python/svn/trunk/Lib/test/test_platform.py", line 24, in test_architecture_via_symlink
    self.assertEqual(get(real), get(link))
AssertionError: Tuples differ: ("('64bit', '')\n", None) != ('', None)

First differing element 0:
('64bit', '')



- ("('64bit', '')\n", None)
+ ('', None)

1 test failed:
    test_platform
[36722 refs]

----------
assignee: ronaldoussoren
components: Macintosh, Tests
messages: 99512
nosy: mark.dickinson, ronaldoussoren
severity: normal
status: open
title: test_platform failure on OS X 10.6
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Feb 18 22:13:39 2010
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 18 Feb 2010 21:13:39 +0000
Subject: [New-bugs-announce] [issue7959] ctypes memory leak
In-Reply-To: <1266527619.9.0.810714625756.issue7959@psf.upfronthosting.co.za>
Message-ID: <1266527619.9.0.810714625756.issue7959@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

This little script 'ctypes-leak.py' leaks memory:

"""
import gc
from ctypes import *

PROTO = WINFUNCTYPE(None)

class Test(object):
    def func(self):
        pass

    def __init__(self):
        self.v = PROTO(self.func)


while 1:
    try:
        Test()
        gc.collect()
    except KeyboardInterrupt:
        print len([x for x in gc.get_objects()
                   if isinstance(x, Test)])
"""

The cause is that patch related to issue #2682; it leaks since rev. 62481 (in trunk) and rev. 62484 (in py3k).

I have not yet been able to find the cause of the leak.

----------
assignee: theller
components: ctypes
files: ctypes-leak.py
messages: 99527
nosy: theller
severity: normal
status: open
title: ctypes memory leak
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16253/ctypes-leak.py

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

From report at bugs.python.org  Thu Feb 18 22:24:01 2010
From: report at bugs.python.org (Michael Newman)
Date: Thu, 18 Feb 2010 21:24:01 +0000
Subject: [New-bugs-announce] [issue7960] test.support.captured_output has
	invalid docstring example
In-Reply-To: <1266528241.14.0.253850913596.issue7960@psf.upfronthosting.co.za>
Message-ID: <1266528241.14.0.253850913596.issue7960@psf.upfronthosting.co.za>


New submission from Michael Newman <michael.b.newman at gmail.com>:

test.support.captured_output is not covered in the online documents:
http://docs.python.org/3.1/library/test.html
http://docs.python.org/dev/py3k/library/test.html

However, it does have a docstring in "C:\Python31\Lib\test\support.py" (see below). The current example for "captured_output" does not work. Looks like someone moved it from "captured_stdout" but did not fully update it. Note the old example still references "captured_stdout". 

# Here's the current code in "support.py":

@contextlib.contextmanager
def captured_output(stream_name):
    """Run the 'with' statement body using a StringIO object in place of a
    specific attribute on the sys module.
    Example use (with 'stream_name=stdout')::

       with captured_stdout() as s:
           print("hello")
       assert s.getvalue() == "hello"
    """
    import io
    orig_stdout = getattr(sys, stream_name)
    setattr(sys, stream_name, io.StringIO())
    try:
        yield getattr(sys, stream_name)
    finally:
        setattr(sys, stream_name, orig_stdout)

def captured_stdout():
    return captured_output("stdout")

# Example for captured_output should now be:

       with captured_output("stdout") as s:
           print("hello")
       assert s.getvalue() == "hello"

# It would be nice to reconcile the online doc versus the docstrings, since it confusing and makes me confused whether captured_stdout is deprecated.

----------
assignee: georg.brandl
components: Documentation
messages: 99529
nosy: georg.brandl, mnewman
severity: normal
status: open
title: test.support.captured_output has invalid docstring example
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Feb 19 00:14:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Feb 2010 23:14:25 +0000
Subject: [New-bugs-announce] [issue7963] Misleading error message from
	object(arg)
In-Reply-To: <1266534865.21.0.144393400814.issue7963@psf.upfronthosting.co.za>
Message-ID: <1266534865.21.0.144393400814.issue7963@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <alexander.belopolsky at gmail.com>:

>>> object(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: object.__new__() takes no parameters


This is misleading because object.__new__() takes one parameter:

>>> object.__new__(object)
<object object at 0x100413980>


I suggest changing "object.__new__() takes no parameters" to "object() takes no parameters".

Some other inconsistencies that I noticed:

>>> tuple.__new__(tuple, 1, 2, 3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: tuple() takes at most 1 argument (3 given)

but

>>> list.__new__(list, 1, 2, 3)
[]

----------
components: Interpreter Core
messages: 99547
nosy: Alexander.Belopolsky
severity: normal
status: open
title: Misleading error message from object(arg)
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb 19 13:52:17 2010
From: report at bugs.python.org (Michael Newman)
Date: Fri, 19 Feb 2010 12:52:17 +0000
Subject: [New-bugs-announce] [issue7964] "-m pdb" SyntaxError for "\r\n"
	formatted py files
In-Reply-To: <1266583937.16.0.516750395183.issue7964@psf.upfronthosting.co.za>
Message-ID: <1266583937.16.0.516750395183.issue7964@psf.upfronthosting.co.za>


New submission from Michael Newman <michael.b.newman at gmail.com>:

Attached is a version checking script. When you run it normally, it produces output such as:

E:\notes\Programming\python3>c:\Python26\python.exe version_check.py
2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]

E:\notes\Programming\python3>c:\Python31\python.exe version_check.py
3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)]

I wanted to test using "-m pdb" on this script. It works okay for Python 2.6:

E:\notes\Programming\python3>c:\Python26\python.exe -m pdb version_check.py
> e:\notes\programming\python3\version_check.py(4)<module>()
-> Last Updated: 2008-12-21"""
(Pdb) c
2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]
The program finished and will be restarted
> e:\notes\programming\python3\version_check.py(4)<module>()
-> Last Updated: 2008-12-21"""
(Pdb) q

However, if I try it on Python 3.1 I get a SyntaxError:

# --- Begin Python 3.1 Example with "\r\n" source code --- #

E:\notes\Programming\python3>c:\Python31\python.exe -m pdb version_check.py
SyntaxError: ('invalid syntax', ('e:\\notes\\programming\\python3\\version_check
.py', 4, 132, '"""Check what version of python is running.\r\n\r\nWritten by: Mi
chael Newman <michael.b.newman at gmail.com>\r\nLast Updated: 2008-12-21"""\r\n'))
> <string>(1)<module>()
(Pdb) c
Traceback (most recent call last):
  File "c:\Python31\lib\pdb.py", line 1297, in main
    pdb._runscript(mainpyfile)
  File "c:\Python31\lib\pdb.py", line 1216, in _runscript
    self.run(statement)
  File "c:\Python31\lib\bdb.py", line 378, in run
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "e:\notes\programming\python3\version_check.py", line 4
    """Check what version of python is running.

Written by: Michael Newman <michael.b.newman at gmail.com>
Last Updated: 2008-12-21"""



^
SyntaxError: invalid syntax
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> <string>(1)<module>()
(Pdb) q
Post mortem debugger finished. The version_check.py will be restarted
SyntaxError: ('invalid syntax', ('e:\\notes\\programming\\python3\\version_check
.py', 4, 132, '"""Check what version of python is running.\r\n\r\nWritten by: Mi
chael Newman <michael.b.newman at gmail.com>\r\nLast Updated: 2008-12-21"""\r\n'))
> <string>(1)<module>()
(Pdb) q

# --- End Python 3.1 Example with "\r\n" source code --- #

As a hunch, my program is has Windows style line endings "\r\n", so I saved the file to another file name and converted it to Unix style "\n" line endings... and this version does work:

# --- Begin Python 3.1 Example using "\n" source code --- #

E:\notes\Programming\python3>copy version_check.py version_check_unix.py
        1 file(s) copied.

E:\notes\Programming\python3>which d2u
C:\Program Files\GnuWin32\bin\d2u.EXE

E:\notes\Programming\python3>d2u version_check_unix.py
version_check_unix.py: done.

E:\notes\Programming\python3>py31 -m pdb version_check_unix.py
> e:\notes\programming\python3\version_check_unix.py(4)<module>()
-> Last Updated: 2008-12-21"""
(Pdb) c
3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)]
The program finished and will be restarted
> e:\notes\programming\python3\version_check_unix.py(4)<module>()
-> Last Updated: 2008-12-21"""
(Pdb) q

# --- End Python 3.1 Example using "\n" source code --- #

Is "\r\n" not officially supported by "-m pdb"? Or is this a bug?

----------
components: Library (Lib)
files: version_check.py
messages: 99570
nosy: mnewman
severity: normal
status: open
title: "-m pdb" SyntaxError for "\r\n" formatted py files
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16256/version_check.py

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

From report at bugs.python.org  Fri Feb 19 15:20:12 2010
From: report at bugs.python.org (Peter Landgren)
Date: Fri, 19 Feb 2010 14:20:12 +0000
Subject: [New-bugs-announce] [issue7965] Problem with urlparse in Windows XP
	after a drag and drop
In-Reply-To: <1266589212.06.0.504228462246.issue7965@psf.upfronthosting.co.za>
Message-ID: <1266589212.06.0.504228462246.issue7965@psf.upfronthosting.co.za>


New submission from Peter Landgren <peter.talken at telia.com>:

When I drag and drop a "file/url" from the file explorer in Windows to my application, I don't get a usable fil name:
In the application I get from Windows
file:///C:/Documents%20and%20Settings/Peter/Mina%20dokument/Mina%20bilder/BlueHole/IMG_1665.JPG

After call to urlparser.urlparser() with this string as parameter I get back:
/C:/Documents%20and%20Settings/Peter/Mina%20dokument/Mina%20bilder/BlueHole/IMG_1665.JPG
Which is not a valid path in Windows
However, It's easy to fix in my application.

So, is this behavior known and are there any plans to change this?

----------
components: Library (Lib)
messages: 99571
nosy: PeterL
severity: normal
status: open
title: Problem with urlparse in Windows XP after a drag and drop
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Feb 19 22:40:30 2010
From: report at bugs.python.org (Andrew Shuiu)
Date: Fri, 19 Feb 2010 21:40:30 +0000
Subject: [New-bugs-announce] [issue7968] __dict__ Exception using class
	attributes
In-Reply-To: <1266615630.29.0.231312214018.issue7968@psf.upfronthosting.co.za>
Message-ID: <1266615630.29.0.231312214018.issue7968@psf.upfronthosting.co.za>


New submission from Andrew Shuiu <asuiu at bitdefender.com>:

Interpreter do not fill in __dict__ attribute of a class which has atributes. dir() shows them, but not __dict__. It works only when attributes are created dynamically at runtime, such as class.attribute = value, not in class definition.
Behaviour is the same on py2.6.4 and py3.1.

Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class MyClass:
...     myattr = 0
...
>>> inst = MyClass()
>>> print(inst.__dict__["myattr"])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'myattr'
>>>

but in this code it works fine:

class MyClass:
     myattr = 0
inst = MyClass()
inst.myattr = 1
print(inst.__dict__["myattr"])

So __dict__ do not contain the attributes of an instantiated object, as it should be, according to documentation.

----------
components: Build, Windows
messages: 99595
nosy: asuiu
severity: normal
status: open
title: __dict__ Exception using class attributes
type: behavior
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Fri Feb 19 23:04:18 2010
From: report at bugs.python.org (Shawn)
Date: Fri, 19 Feb 2010 22:04:18 +0000
Subject: [New-bugs-announce] [issue7969] shutil.copytree error handling
	non-standard and partially	broken
In-Reply-To: <1266617058.24.0.24785922897.issue7969@psf.upfronthosting.co.za>
Message-ID: <1266617058.24.0.24785922897.issue7969@psf.upfronthosting.co.za>


New submission from Shawn <swalker at opensolaris.org>:

The error handling present in the implementation of shutil.copytree in python 2.6.4 (and perhaps other versions) is non-standard and partially broken.

In particular, I'm unable to find any pydoc documentation that indicates that when copytree raises shutil.Error, that the error instead of the standard 2-tuple or 3-tuple was initialised with a list of entries.

This means that callers catching EnvironmentError will be in for a surprise whenever they check e.args and find a tuple containing a list instead of just a tuple.

Callers will also be disappointed to find that the entries in the list may be tuples or strings due to what looks like a bug in copystat error handling (it's using extend instead of append).

I could possibly live with this behaviour somewhat if it was actually documented and consistent since shutil.Error can be caught specifically instead.

It's also really unfortunate that the tuples that are stored here aren't the actual exception objects of the errors encountered so callers cannot perform more granular error handling (permissions exceptions, etc.).

I'd like to request that this function:

* be fixed to append copystat errors correctly

* have shutil.Error documentation indicate the special args format and explain how it might be parsed

* consider having it record the exception objects instead of the exception message

* suggest that the default str() output for shutil.Error be improved

----------
components: Library (Lib)
messages: 99597
nosy: swalker
severity: normal
status: open
title: shutil.copytree error handling non-standard and partially broken
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Feb 20 01:25:12 2010
From: report at bugs.python.org (Charles Cazabon)
Date: Sat, 20 Feb 2010 00:25:12 +0000
Subject: [New-bugs-announce] [issue7970] email.Generator fails to flatten
	message parsed by	email.Parser
In-Reply-To: <1266625512.07.0.157339472909.issue7970@psf.upfronthosting.co.za>
Message-ID: <1266625512.07.0.157339472909.issue7970@psf.upfronthosting.co.za>


New submission from Charles Cazabon <charlesc-python at pyropus.ca>:

email.Generator fails to flatten a message parsed by email.Parser; it throws an exception with an odd (but apparently legal) message.  First, the exception:

  File "/usr/local/lib/python2.6/email/generator.py", line 84, in flatten
    self._write(msg)
  File "/usr/local/lib/python2.6/email/generator.py", line 109, in _write
    self._dispatch(msg)
  File "/usr/local/lib/python2.6/email/generator.py", line 135, in _dispatch
    meth(msg)
  File "/usr/local/lib/python2.6/email/generator.py", line 266, in _handle_message
    g.flatten(msg.get_payload(0), unixfrom=False)
  File "/usr/local/lib/python2.6/email/message.py", line 189, in get_payload
    raise TypeError('Expected list, got %s' % type(self._payload))
TypeError: Expected list, got <type 'str'>

The oddity of the message its handling is that it's a single-part MIME message, where the content-type is declared as message/rfc822.  Most MUAs, when forwarding message, create a multipart MIME message with a single attachment part, and have the attachment be message/rfc822.  But Groupwise, when configured to forward messages to another address (without specifying an additional text to insert with the forwarded message) creates these slightly odd messages.

I've not seen them before, but a couple of getmail users have run into this issue.  I've confirmed the problem is the same in Python 2.3, 2.4, 2.5, and 2.6, and I presume it's the same in 2.7 but haven't tested yet.

I'll attach a minimal test script and a datafile which is a minimal message showing the problem.

----------
components: Library (Lib)
files: testcase.py
messages: 99606
nosy: charlesc
severity: normal
status: open
title: email.Generator fails to flatten message parsed by email.Parser
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file16262/testcase.py

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

From report at bugs.python.org  Sat Feb 20 21:36:58 2010
From: report at bugs.python.org (Aaron Meurer)
Date: Sat, 20 Feb 2010 20:36:58 +0000
Subject: [New-bugs-announce] [issue7972] Have sequence multiplication call
	int() or return	NotImplemented so that it can be overridden
	with __rmul__
In-Reply-To: <1266698218.4.0.917431535716.issue7972@psf.upfronthosting.co.za>
Message-ID: <1266698218.4.0.917431535716.issue7972@psf.upfronthosting.co.za>


New submission from Aaron Meurer <asmeurer at gmail.com>:

This works in Python 2.5 but not in Python 2.6.

If you do [0]*5, it gives you [0, 0, 0, 0, 0].  I tried getting this to work with SymPy's Integer class, so that [0]*Integer(5) would return the same, but unfortunately, the sequence multiplication doesn't seem to return NotImplemented properly allowing it to be overridden in __rmul__.  Overridding in regular __mul__ of course works fine.  From sympy/core/basic.py (modified):

    # This works fine
    @_sympifyit('other', NotImplemented)
    def __mul__(self, other):
        if type(other) in (tuple, list) and self.is_Integer:
            return int(self)*other
        return Mul(self, other)
    # This has no affect.
    @_sympifyit('other', NotImplemented)
    def __rmul__(self, other):
        if type(other) in (tuple, list, str) and self.is_Integer:
            return other*int(self)
        return Mul(other, self)

In other words, with the above, Integer(5)*[0] works, but [0]*Integer(5) raises TypeError: can't multiply sequence by non-int of type 'Integer' just as it does without any changes.  See also my branch at github with these changes http://github.com/asmeurer/sympy/tree/list-int-mul.

Another option might be to just have the list.__mul__(self, other) try calling int(other).  

SymPy has not yet been ported to Python 3, so I am sorry that I cannot test if it works there.

----------
messages: 99629
nosy: Aaron.Meurer
severity: normal
status: open
title: Have sequence multiplication call int() or return NotImplemented so that it can be overridden with __rmul__
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Feb 21 15:04:22 2010
From: report at bugs.python.org (=?utf-8?q?Dominique_Pell=C3=A9?=)
Date: Sun, 21 Feb 2010 14:04:22 +0000
Subject: [New-bugs-announce] [issue7974] Valgrind error when running Python
	command within Vim
In-Reply-To: <1266761062.18.0.173748987708.issue7974@psf.upfronthosting.co.za>
Message-ID: <1266761062.18.0.173748987708.issue7974@psf.upfronthosting.co.za>


New submission from Dominique Pell? <dominique.pelle at gmail.com>:

I built Vim-7.2.368 editor with python interpreter using
Python-2.6.4 library on Linux x86.

When I run a python command (any command, it does not matter)
in the Vim editor with Valgrind memory checker, I see valgrind
errors within the Python library.  It looks to me like they
are errors within the Python library and not errors in Vim.

I attach the valgrind error log file.

Steps to reproduce the bug:

1/ Download & compile Vim with python interpreter

  $ hg clone https://vim.googlecode.com/hg/ vim
  $ cd vim
  $ ./configure --enable-pythoninterp --with-python-config-dir=/usr/local/lib/python2.6/config
  $ make

(you may also want to tweak vim/src/Makefile to compile with -O0 -g
to have more interesting stacks in valgrind logs)

2/ Run a Python command within Vim with Valgrind memory checker: 

  $ cd vim/src
  $ valgrind --log-file=valgrind.log ./vim -c ':python "foo=0"'

3/ Observe in valgrind.log the errors in Python lib  

The stack is quite deep in the errors and Valgrind memory checker has a limit to dump at most 50 functions in stack frame. I increased that limit to 100 to be able to see the full stack trace as in attached log file "valgrind.log".

In the fist error in attached valgrind.log, memory is used in a
buffer that has already been freed. Looking at the Python
code, this function does not make much sense to me:

1040 PyObject *
1041 PyMarshal_ReadLastObjectFromFile(FILE *fp)
1042 {
1043 /* 75% of 2.1's .pyc files can exploit SMALL_FILE_LIMIT.
1044  * REASONABLE_FILE_LIMIT is by defn something big enough for Tkinter.pyc.
1045  */
1046 #define SMALL_FILE_LIMIT (1L << 14)
1047 #define REASONABLE_FILE_LIMIT (1L << 18)
1048 #ifdef HAVE_FSTAT
1049         off_t filesize;
1050 #endif
1051 #ifdef HAVE_FSTAT
1052         filesize = getfilesize(fp);
1053         if (filesize > 0) {
1054                 char buf[SMALL_FILE_LIMIT];
1055                 char* pBuf = NULL;
1056                 if (filesize <= SMALL_FILE_LIMIT)
1057                         pBuf = buf;
1058                 else if (filesize <= REASONABLE_FILE_LIMIT)
1059                         pBuf = (char *)PyMem_MALLOC(filesize);
1060                 if (pBuf != NULL) {
1061                         PyObject* v;
1062                         size_t n;
1063                         /* filesize must fit into an int, because it
1064                            is smaller than REASONABLE_FILE_LIMIT */
1065                         n = fread(pBuf, 1, (int)filesize, fp);
1066                         v = PyMarshal_ReadObjectFromString(pBuf, n);
1067                         if (pBuf != buf)
1068                                 PyMem_FREE(pBuf);
1069                         return v;
1070                 }
1071 
1072         }
1073 #endif
1074         /* We don't have fstat, or we do but the file is larger than
1075          * REASONABLE_FILE_LIMIT or malloc failed -- read a byte at a time.
1076          */
1077         return PyMarshal_ReadObjectFromFile(fp);
1078 
1079 #undef SMALL_FILE_LIMIT
1080 #undef REASONABLE_FILE_LIMIT
1081 }

Memory is allocated for pBuf at line marshal.c:1059.
Then at line marshall.c:1066 v= PyMarshal_ReadObjectFromString(pBuf, n);
is called. 

The v structure contains pointer to the pBuf buffer (see line marshall.c:1103). Then pBuf is freed at marshall.c:1068 and v is returned.

So v which is returned contains a pointer "v.ptr" to buffer
that has just been freed. That looks wrong to me. What's the
point of v containing an address to something freed?

Looking at the latest version of Python/marshal.c in SVN,
this function has not been changed since 2.6.4:

http://svn.python.org/projects/python/trunk/Python/marshal.c

----------
components: Library (Lib)
files: valgrind.log.gz
messages: 99660
nosy: dominiko
severity: normal
status: open
title: Valgrind error when running Python command within Vim
versions: Python 2.6
Added file: http://bugs.python.org/file16277/valgrind.log.gz

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

From report at bugs.python.org  Sun Feb 21 16:44:17 2010
From: report at bugs.python.org (Adam Collard)
Date: Sun, 21 Feb 2010 15:44:17 +0000
Subject: [New-bugs-announce] [issue7975] dbshelve.py throws exception:
	AttributeError: 'DB' object	has no attribute '__iter__'
In-Reply-To: <1266767057.06.0.0487468056966.issue7975@psf.upfronthosting.co.za>
Message-ID: <1266767057.06.0.0487468056966.issue7975@psf.upfronthosting.co.za>


New submission from Adam Collard <adam.collard at gmail.com>:

Originally reported at:
  https://bugs.edge.launchpad.net/bugs/384602

In Python 2.6, the dbshelve.py module throws an AttributeError exception whenever a call is made to a method that depends upon an __iter__ method.  The exception is:

  File "/usr/lib/python2.6/bsddb/dbshelve.py", line 167, in __iter__
    return self.db.__iter__()
AttributeError: 'DB' object has no attribute '__iter__'

This means that, if mydb is an istance of a DB object, the following examples will fail:

    for key in mydb: print key
 
    print (k for k in mydb.iterkeys())

    for k, d in mydb.itervalues(): print k, d

and many other statements depending on iterable(mydb) being true

Note that, in Python 2.5, these examples work and no exception is thrown.  In fact, if you have both 2.5 and 2.6 installed on the same system, you can run the same program containing code as above with Python2.5 without issue while running it under Python 2.6 raises the exception seen above.

----------
messages: 99667
nosy: adam-collard
severity: normal
status: open
title: dbshelve.py throws exception: AttributeError: 'DB' object has no attribute '__iter__'

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

From report at bugs.python.org  Sun Feb 21 20:14:55 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Sun, 21 Feb 2010 19:14:55 +0000
Subject: [New-bugs-announce] [issue7978] SocketServer doesn't handle syscall
	interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>


New submission from Vetoshkin Nikita <nikita.vetoshkin at gmail.com>:

SocketServer's handle_request function uses "select" call to handle io, but sending POSIX signal will result in 'Interrupted system call' exception raised. After that Paste (http://pythonpaste.org/) http server will crash.
I suppose EINTR must be handled properly (i.e. syscall must be restarted silently) on SocketServer's side. That must be pretty easy task.

----------
components: Library (Lib)
messages: 99676
nosy: nvetoshkin
severity: normal
status: open
title: SocketServer doesn't handle syscall interruption
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/issue7978>
_______________________________________

From report at bugs.python.org  Mon Feb 22 11:46:38 2010
From: report at bugs.python.org (Willard)
Date: Mon, 22 Feb 2010 10:46:38 +0000
Subject: [New-bugs-announce] [issue7980] time.strptime not thread safe
In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za>
Message-ID: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za>


New submission from Willard <cptnwillard at gmail.com>:

The following script raises several "_strptime_time" AttributeErrors (on OS X 10.4 at least).

If time.strptime is used before starting the threads, then no exception is raised (the issue may thus come from strptime.py not being imported in a thread safe manner).


import time
import thread

def f():
    for m in xrange(1, 13):
        for d in xrange(1,29):
            time.strptime("2010%02d%02d"%(m,d),"%Y%m%d")

for _ in xrange(10):
    thread.start_new_thread(f, ())
time.sleep(3)


> Traceback (most recent call last):
>   File "[...]/test.py", line 75, in f
>     time.strptime("2010%02d%02d"%(m,d),"%Y%m%d")
> AttributeError: _strptime_time

----------
components: Library (Lib)
messages: 99718
nosy: cptnwillard
severity: normal
status: open
title: time.strptime not thread safe
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Mon Feb 22 15:55:06 2010
From: report at bugs.python.org (Mezhenin Artyom)
Date: Mon, 22 Feb 2010 14:55:06 +0000
Subject: [New-bugs-announce] [issue7984] missing dependencies using cProfile
In-Reply-To: <1266850506.92.0.292713556169.issue7984@psf.upfronthosting.co.za>
Message-ID: <1266850506.92.0.292713556169.issue7984@psf.upfronthosting.co.za>


New submission from Mezhenin Artyom <a.mezhenin at gmail.com>:

1) I have ubuntu 9.10 and python2.6 (and 2.5 too).
2) execution code like that:

  if __name__ == "__main__":
      import cProfile
      cProfile.run('main()')

gives me traceback:

Traceback (most recent call last):
  File "./scribo.py", line 60, in <module>
    cProfile.run('main()')
  File "/usr/lib/python2.6/cProfile.py", line 36, in run
    result = prof.print_stats(sort)
  File "/usr/lib/python2.6/cProfile.py", line 80, in print_stats
    import pstats
ImportError: No module named pstats

so I had to install python-profiler package manually

----------
components: None
messages: 99739
nosy: artech
severity: normal
status: open
title: missing dependencies using cProfile
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Mon Feb 22 16:02:51 2010
From: report at bugs.python.org (LukMak)
Date: Mon, 22 Feb 2010 15:02:51 +0000
Subject: [New-bugs-announce] [issue7985] access to infinitely recursive list
In-Reply-To: <1266850971.35.0.609104606794.issue7985@psf.upfronthosting.co.za>
Message-ID: <1266850971.35.0.609104606794.issue7985@psf.upfronthosting.co.za>


New submission from LukMak <lmakowsk at volt.iem.pw.edu.pl>:

Execution:
>>> l=[]
>>> l.append(l)
>>> l
[[...]]
>>> l[0]
[[...]]
>>> l[0][0][0]
[[...]]
>>> eval('l'+'[0]'*10)
[[...]]
>>> eval('l'+'[0]'*666)
[[...]]
>>> eval('l'+'[0]'*999999)
Segmentation fault

Environment:
2.6.24-27-generic #1 SMP, Ubuntu 8.04.4 LTS, Both Python 2.5.2 from distro repo and Python 3.1.1 compiled by me. But crash seems to be platform and version independent.

Comment:
Should throw RuntimeError: maximum recursion depth exceeded instead of SIGSEGV?

----------
components: Interpreter Core
messages: 99742
nosy: LukMak
severity: normal
status: open
title: access to infinitely recursive list
type: crash
versions: Python 2.5, Python 3.1

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

From report at bugs.python.org  Mon Feb 22 16:58:12 2010
From: report at bugs.python.org (Jelly Chen)
Date: Mon, 22 Feb 2010 15:58:12 +0000
Subject: [New-bugs-announce] [issue7986] Python 3 cannot recognize url
	like:	https://sinojellycn:123456@storage.msn.com
In-Reply-To: <1266854292.18.0.707274307312.issue7986@psf.upfronthosting.co.za>
Message-ID: <1266854292.18.0.707274307312.issue7986@psf.upfronthosting.co.za>


New submission from Jelly Chen <sinojelly at gmail.com>:

posturl='https://sinojellycn:123456 at storage.msn.com/storageservice/MetaWeblog.rpc'
username="sinojellycn"
password="123456"

blog = pyblog.WordPress(posturl, username, password)
content = {"description":'Test description6', "title":'Test article6'}
blog.new_post(content, blogid = "1") 

>>> 
Traceback (most recent call last):
  File "C:\Python31\Lib\http\client.py", line 664, in _set_hostport
    port = int(host[i+1:])
ValueError: invalid literal for int() with base 10: '123456 at storage.msn.com'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<string>", line 248, in run_nodebug
  File "D:\Users\Documents\My Knowledge\Plugins\{A0D025CD-970A-4C62-97E4-5CF6F2C9DD6A}\BlogPost.py", line 384, in <module>
    blog = pyblog.WordPress(posturl, username, password)
  File "D:\Users\Documents\My Knowledge\Plugins\{A0D025CD-970A-4C62-97E4-5CF6F2C9DD6A}\pyblog.py", line 266, in __init__
    MetaWeblog.__init__(self, serverapi, username, password, encoding)
  File "D:\Users\Documents\My Knowledge\Plugins\{A0D025CD-970A-4C62-97E4-5CF6F2C9DD6A}\pyblog.py", line 167, in __init__
    Blog.__init__(self, serverapi, username, password, encoding, appkey)
  File "D:\Users\Documents\My Knowledge\Plugins\{A0D025CD-970A-4C62-97E4-5CF6F2C9DD6A}\pyblog.py", line 57, in __init__
    if not checkURL(serverapi):
  File "D:\Users\Documents\My Knowledge\Plugins\{A0D025CD-970A-4C62-97E4-5CF6F2C9DD6A}\pyblog.py", line 19, in checkURL
    try: urllib.request.urlopen(url)
  File "C:\Python31\Lib\urllib\request.py", line 119, in urlopen
    return _opener.open(url, data, timeout)
  File "C:\Python31\Lib\urllib\request.py", line 347, in open
    response = self._open(req, data)
  File "C:\Python31\Lib\urllib\request.py", line 365, in _open
    '_open', req)
  File "C:\Python31\Lib\urllib\request.py", line 325, in _call_chain
    result = func(*args)
  File "C:\Python31\Lib\urllib\request.py", line 1080, in https_open
    return self.do_open(http.client.HTTPSConnection, req)
  File "C:\Python31\Lib\urllib\request.py", line 1034, in do_open
    h = http_class(host, timeout=req.timeout) # will parse host:port
  File "C:\Python31\Lib\http\client.py", line 1027, in __init__
    HTTPConnection.__init__(self, host, port, strict, timeout)
  File "C:\Python31\Lib\http\client.py", line 650, in __init__
    self._set_hostport(host, port)
  File "C:\Python31\Lib\http\client.py", line 666, in _set_hostport
    raise InvalidURL("nonnumeric port: '%s'" % host[i+1:])
http.client.InvalidURL: nonnumeric port: '123456 at storage.msn.com'
>>>

----------
components: Library (Lib)
messages: 99760
nosy: Jelly.Chen
severity: normal
status: open
title: Python 3 cannot recognize url like: https://sinojellycn:123456 at storage.msn.com
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Feb 22 17:03:36 2010
From: report at bugs.python.org (Jelly Chen)
Date: Mon, 22 Feb 2010 16:03:36 +0000
Subject: [New-bugs-announce] [issue7987] Python 3.1's http.client doesn't
	support HTTPS
In-Reply-To: <1266854616.59.0.987472401793.issue7987@psf.upfronthosting.co.za>
Message-ID: <1266854616.59.0.987472401793.issue7987@psf.upfronthosting.co.za>


New submission from Jelly Chen <sinojelly at gmail.com>:

posturl='https://storage.msn.com/storageservice/MetaWeblog.rpc'
username="sinojellycn"
password="123456"

blog = pyblog.WordPress(posturl, username, password)
content = {"description":'Test description6', "title":'Test article6'}
blog.new_post(content, blogid = "1") 

Traceback (most recent call last):
  File "<string>", line 248, in run_nodebug
  File "D:\Users\Documents\My Knowledge\Plugins\{A0D025CD-970A-4C62-97E4-5CF6F2C9DD6A}\BlogPost.py", line 385, in <module>
    blog = pyblog.WordPress(posturl, username, password)
  File "D:\Users\Documents\My Knowledge\Plugins\{A0D025CD-970A-4C62-97E4-5CF6F2C9DD6A}\pyblog.py", line 266, in __init__
    MetaWeblog.__init__(self, serverapi, username, password, encoding)
  File "D:\Users\Documents\My Knowledge\Plugins\{A0D025CD-970A-4C62-97E4-5CF6F2C9DD6A}\pyblog.py", line 167, in __init__
    Blog.__init__(self, serverapi, username, password, encoding, appkey)
  File "D:\Users\Documents\My Knowledge\Plugins\{A0D025CD-970A-4C62-97E4-5CF6F2C9DD6A}\pyblog.py", line 63, in __init__
    self.list_methods2()
  File "D:\Users\Documents\My Knowledge\Plugins\{A0D025CD-970A-4C62-97E4-5CF6F2C9DD6A}\pyblog.py", line 87, in list_methods2
    self.methods = self.server.system.listMethods()
  File "C:\Python31\Lib\xmlrpc\client.py", line 1039, in __call__
    return self.__send(self.__name, args)
  File "C:\Python31\Lib\xmlrpc\client.py", line 1281, in __request
    verbose=self.__verbose
  File "C:\Python31\Lib\xmlrpc\client.py", line 1068, in request
    http_conn = self.send_request(host, handler, request_body, verbose)
  File "C:\Python31\Lib\xmlrpc\client.py", line 1193, in send_request
    "your version of http.client doesn't support HTTPS")
NotImplementedError: your version of http.client doesn't support HTTPS
>>>

----------
components: Library (Lib)
messages: 99765
nosy: Jelly.Chen
severity: normal
status: open
title: Python 3.1's http.client doesn't support HTTPS
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Feb 22 17:19:03 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 22 Feb 2010 16:19:03 +0000
Subject: [New-bugs-announce] [issue7988] complex.__format__ has incorrect
	default alignment
In-Reply-To: <1266855543.18.0.92695356509.issue7988@psf.upfronthosting.co.za>
Message-ID: <1266855543.18.0.92695356509.issue7988@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

Complex uses left alignment by default, but should use right alignment like the other numeric types.

>>> format(1+1j, '20.0')
'(1+1j)              '

>>> format(1.0, '20.0')
'               1e+00'

>>> format(1, '20')
'                   1'

----------
assignee: eric.smith
components: Interpreter Core
messages: 99773
nosy: eric.smith
severity: normal
status: open
title: complex.__format__ has incorrect default alignment
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Feb 22 17:22:08 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 22 Feb 2010 16:22:08 +0000
Subject: [New-bugs-announce] [issue7989] Transition time/datetime C modules
	to Python
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>


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

After discussion on numerous issues, python-dev, and here at the PyCon sprints, it seems to be a good idea to move timemodule.c to _timemodule.c and convert as much as possible into pure Python. The same change seems good for datetime.c as well.

----------
components: Library (Lib)
messages: 99774
nosy: brian.curtin
priority: normal
severity: normal
stage: needs patch
status: open
title: Transition time/datetime C modules to Python
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Feb 22 22:58:59 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 22 Feb 2010 21:58:59 +0000
Subject: [New-bugs-announce] [issue7994] object.__format__ should reject
	format strings
In-Reply-To: <1266875939.21.0.792202593026.issue7994@psf.upfronthosting.co.za>
Message-ID: <1266875939.21.0.792202593026.issue7994@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

Background:

format(obj, fmt) eventually calls object.__format__(obj, fmt) if obj (or one of its bases) does not implement __format__. The behavior of object.__format__ is basically:

def __format__(self, fmt):
    return str(self).__format__(fmt)

So the caller of format() thought they were passing in a format string specific to obj, but it is interpreted as a format string for str.

This is not correct, or at least confusing. The format string is supposed to be type specific. However in this case the object is being changed (to type str), but the format string which was to be applied to its original type is now being passed to str.

This is an actual problem that occurred in the migration from 3.0 -> 3.1 and from 2.6 -> 2.7 with complex. In the earlier versions, complex did not have a __format__ method, but it does in the latter versions. So this code:
>>> format(1+1j, '10s')
'(1+1j)    '
worked in 2.6 and 3.0, but gives an error in 2.7 and 3.1:
>>> format(1+1j, '10s')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Unknown format code 's' for object of type 'complex'

Proposal:
object.__format__ should give an error if a non-empty format string is specified. In 2.7 and 3.2 make this a PendingDeprecationWarning, in 3.3 make it a DeprecationWarning, and in 3.4 make it an error.

Modify the documentation to make this behavior clear, and let the user know that if they want this behavior they should say:

format(str(obj), '10s')

or the equivalent:

"{0!s:10}".format(obj)

That is, the conversion to str should be explicit.

----------
assignee: eric.smith
components: Interpreter Core
messages: 99847
nosy: eric.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: object.__format__ should reject format strings
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Feb 22 23:09:43 2010
From: report at bugs.python.org (Justin Cappos)
Date: Mon, 22 Feb 2010 22:09:43 +0000
Subject: [New-bugs-announce] [issue7995] On Mac / BSD sockets returned by
	accept inherit the	parent's FD flags
In-Reply-To: <1266876583.45.0.97810567794.issue7995@psf.upfronthosting.co.za>
Message-ID: <1266876583.45.0.97810567794.issue7995@psf.upfronthosting.co.za>


New submission from Justin Cappos <justincappos at gmail.com>:

Suppose there is a program that has a listening socket that calls accept to obtain new sockets for client connections.   socketmodule.c assumes that these client sockets have timeouts / blocking in the default state for new sockets (which on most systems means the sockets will block).   However, socketmodule.c does not verify the state of the socket object that is returned by the system call accept.

>From http://linux.die.net/man/2/accept :
On Linux, the new socket returned by accept() does not inherit file status flags such as O_NONBLOCK and O_ASYNC from the listening socket. This behaviour differs from the canonical BSD sockets implementation. Portable programs should not rely on inheritance or non-inheritance of file status flags and always explicitly set all required flags on the socket returned from accept(). 


socketmodule.c does not explicitly set or check these flags for sockets returned by accept.   The attached program will print the following on Linux regardless of whether the settimeout line for s exists or not:

a has timeout: None
O_NONBLOCK is set: False
received: hi



On Mac / BSD, the program will produce the following output when the timeout is set on the listening socket:

a has timeout: None
O_NONBLOCK is set: True
Traceback (most recent call last):
  File "python-nonportable.py", line 39, in <module>
    message = a.recv(1024)
socket.error: (35, 'Resource temporarily unavailable')


When the timeout is removed, the behavior is the same as linux:

a has timeout: None
O_NONBLOCK is set: False
received: hi


Note that the file descriptor problem crops up in odd ways on Mac systems.   It's possible that issue 5154 may be due to this bug.   I am aware of other problems with the socketmodule on Mac and will report them in other tickets.


I believe that this problem can be easily mitigated by always calling fcntl to unset the O_NONBLOCK flag after accept (O_ASYNC should be unset too, for correctness).   I would recommend adding the below code snippet at line 1653 in socketmodule.c (r78335).   The resulting code would look something like this (with '+' in front of the added lines):


'''
#ifdef MS_WINDOWS
        if (newfd == INVALID_SOCKET)
#else
        if (newfd < 0)
#endif
                return s->errorhandler();

+#if defined(__APPLE__) || defined(__OpenBSD__) || defined(__FreeBSD__)
+        int starting_flag;
+        // Unset O_NONBLOCK an O_ASYNC if they are inherited.
+        starting_flag = fcntl(newfd, F_GETFL, 0);
+        starting_flag &= ~(O_NONBLOCK | O_ASYNC);
+        fcntl(newfd, F_SETFL, starting_flag);
+#endif

        /* Create the new object with unspecified family,
           to avoid calls to bind() etc. on it. */
        sock = (PyObject *) new_sockobject(newfd,
                                           s->sock_family,
                                           s->sock_type,
                                           s->sock_proto);
'''

I've tested this patch on my Mac and Linux systems and it seems to work fine.   I haven't had a chance to test on BSD.   Also, I did not test for this problem in Python 3, but I assume it exists there as well and the same fix should be applied.

----------
assignee: ronaldoussoren
components: Library (Lib), Macintosh
files: python-nonportable.py
messages: 99852
nosy: Justin.Cappos, bbangert, giampaolo.rodola, loewis, nicdumz, ronaldoussoren
severity: normal
status: open
title: On Mac / BSD sockets returned by accept inherit the parent's FD flags
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file16325/python-nonportable.py

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

From report at bugs.python.org  Tue Feb 23 00:50:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 22 Feb 2010 23:50:02 +0000
Subject: [New-bugs-announce] [issue7996] concurrency problem in regrtest -jX
In-Reply-To: <1266882602.92.0.94768857178.issue7996@psf.upfronthosting.co.za>
Message-ID: <1266882602.92.0.94768857178.issue7996@psf.upfronthosting.co.za>


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

While testing GIL changes I ran against an interesting bug in regrtest when run with -j<big number>. It turns out that we can't consume a generator from two threads simultaneously.


Exception in thread Thread-8:
Traceback (most recent call last):
  File "/home/antoine/py3k/gilprio/Lib/threading.py", line 521, in _bootstrap_inner
    self.run()
  File "/home/antoine/py3k/gilprio/Lib/threading.py", line 474, in run
    self._target(*self._args, **self._kwargs)
  File "/home/antoine/py3k/gilprio/Lib/test/regrtest.py", line 523, in work
    test, args_tuple = next(pending)
ValueError: generator already executing

----------
components: Tests
messages: 99879
nosy: pitrou, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: concurrency problem in regrtest -jX
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Feb 23 00:54:01 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 22 Feb 2010 23:54:01 +0000
Subject: [New-bugs-announce] [issue7997] http://www.python.org/dev/faq/
	doesn't seem to explain	how to regenerate "configure"
In-Reply-To: <1266882841.0.0.727782074241.issue7997@psf.upfronthosting.co.za>
Message-ID: <1266882841.0.0.727782074241.issue7997@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

http://www.python.org/dev/faq/ doesn't seem to explain how to regenerate "configure"
Here's an attempt at answering that question; I hope the following is appropriate and factually correct:

How to regenerate the "configure" script (e.g. to add a new configuration parameter)

Python's "configure" script is generated from "configure.in" from autoconf.  Do not edit "configure"; instead, edit "configure.in" and run "autoreconf".  You should run "./configure --help" to verify that your changes are documented as expected.

Python's "configure.in" script typically requires a specific version of autoconf.  At the moment, this reads:
    version_required(2.61)

If the system copy of autoconf does not match this version, you will need to install your own copy of autoconf and use this.
1. Go to http://ftp.gnu.org/gnu/autoconf/ and download the version of autoconf matching the one in configure.in
   For example:
       $ wget http://ftp.gnu.org/gnu/autoconf/autoconf-2.61.tar.bz2
2. Unpack the tarball:
       $ tar -jxf autoconf-2.61.tar.bz2 
3. Build the specified version of autoconf and install it to a writable location (e.g. within your home directory):
$ pushd autoconf-2.61.tar.bz2
$ ./configure --prefix=$HOME/autoconf-2.6.1
$ make ; make install

This drops a copy of the appropriate version of autoconf into ~/autoconf-2.6.1

4. Go back to the python source and rerun autoconf, pointing PATH at the specific copy of autoconf:
   $ popd
   $ PATH=~/autoconf-2.6.1/bin:$PATH autoreconf

5. "autoconf" should now have updated your local copy of "configure" to reflect your changes.

6. Run "./configure --help" to verify that your changes have been applied

----------
assignee: georg.brandl
components: Documentation
messages: 99882
nosy: dmalcolm, georg.brandl
severity: normal
status: open
title: http://www.python.org/dev/faq/ doesn't seem to explain how to regenerate "configure"

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

From report at bugs.python.org  Tue Feb 23 08:29:49 2010
From: report at bugs.python.org (Tom Loredo)
Date: Tue, 23 Feb 2010 07:29:49 +0000
Subject: [New-bugs-announce] [issue7998] MacPython 2.7a3 posix_spawn error
	for build using	--with-framework-name
In-Reply-To: <1266910189.84.0.492306912925.issue7998@psf.upfronthosting.co.za>
Message-ID: <1266910189.84.0.492306912925.issue7998@psf.upfronthosting.co.za>


New submission from Tom Loredo <loredo at astro.cornell.edu>:

Build Py-2.7a3 on Snow Leopard OS 10.6.2 with a non-default framework name:

./configure --prefix=/usr/local/tmp --enable-framework --with-framework-name=PythonAlpha  --enable-universalsdk=/ --with-universal-archs=intel

"make" succeeds, "make test" isn't perfect but is okay:

$ make test
...
347 tests OK.
1 test failed:
    test_macostools
33 tests skipped:
    test_al test_bsddb test_bsddb3 test_cd test_cl test_codecmaps_cn
    test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr
    test_codecmaps_tw test_curses test_dl test_epoll test_gl
    test_imageop test_imgfile test_largefile test_linuxaudiodev
    test_ossaudiodev test_pep277 test_py3kwarn test_smtpnet
    test_socketserver test_startfile test_sunaudiodev test_timeout
    test_tk test_ttk_guionly test_urllib2net test_urllibnet
    test_winreg test_winsound test_zipfile64
1 skip unexpected on darwin:
    test_dl
make: *** [test] Error 1

But after "make install" the installed python fails:

$ which python
/Library/Frameworks/PythonAlpha.framework/Versions/2.7/bin/python
$ python
python: posix_spawn: python: Unknown error: 0

The same failure occurs if I directly execute python, python2.7, python-32, and the "w" versions in the framework with a full path, or with the /usr/local/tmp/bin paths.

On the other hand, if I build with the same config but omitting the framework name change:

./configure --prefix=/usr/local/tmp --enable-framework --enable-universalsdk=/ --with-universal-archs=intel

the command line interpreter is now fine:

$ which python
/Library/Frameworks/Python.framework/Versions/Current/bin/python
$ python
Python 2.7a3 (r27a3:78020, Feb 23 2010, 02:07:19) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
...

By the way, in either case, python-32 (and its variants) are in the
framework but are *not* linked under the prefix (e.g., here they are
not in /usr/local/tmp/bin).  I don't know if this is intentional or not; it seems undesirable to me.

----------
assignee: ronaldoussoren
components: Installation, Macintosh
messages: 99902
nosy: ronaldoussoren, tloredo
severity: normal
status: open
title: MacPython 2.7a3 posix_spawn error for build using --with-framework-name
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Feb 23 16:19:48 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 23 Feb 2010 15:19:48 +0000
Subject: [New-bugs-announce] [issue8001] os.stat on osx 10.5 or later
	doesn't expose all fields in	struct stat
In-Reply-To: <1266938388.51.0.563048474529.issue8001@psf.upfronthosting.co.za>
Message-ID: <1266938388.51.0.563048474529.issue8001@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

The stat implementation on osx 10.5 or later can provide additional fields beyond the tradional unix ones (such as "st_birthtimespec"). Those are by default only available when using 'stat64' instead of the regular stat, but that can be changed using a preprocessor define.

The additional fields are not yet present in the python wrapper (posix.stat) and are apparently useful (according to a mail exchange on the python-nl mailinglist).

It should be possible to add the additional fields in the struct-view of the statresults object without affecting existing code and other platforms. Care should be taken to still enabling building a binary on 10.5 that works on 10.4 (where the stat64 function is not present).

----------
assignee: ronaldoussoren
components: Extension Modules, Macintosh
messages: 99924
nosy: ronaldoussoren
severity: normal
stage: needs patch
status: open
title: os.stat on osx 10.5 or later doesn't expose all fields in struct stat
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Feb 23 19:07:44 2010
From: report at bugs.python.org (Mads Kiilerich)
Date: Tue, 23 Feb 2010 18:07:44 +0000
Subject: [New-bugs-announce] [issue8003] Fragile and unexpected
	error-handling in asyncore
In-Reply-To: <1266948464.33.0.330812797821.issue8003@psf.upfronthosting.co.za>
Message-ID: <1266948464.33.0.330812797821.issue8003@psf.upfronthosting.co.za>


New submission from Mads Kiilerich <mads at kiilerich.com>:

I had an issue which seems to be very similar to issue4690 - but different.

I created a subclass of asyncore.dispatcher, .create_socket added it to the channel map, but then .bind failed (because the port was in use - my bad), .listen wasn't called, and .accepting thus not set. The problem is that .accepting is the safeguard against .handle_read and .handle_write ever being called. Without that safeguard it then started spinning in .handle_read and .handle_write, calling handlers that wasn't implemented. 

I guess the right way to handle this is to handle exceptions thrown by .bind and then call .close. But even if I do that there will be a race-condition between the error occurs and I can call .close.

My main issue/request is that asyncore should be less fragile and handle such errors better. I don't know exactly how that should be implemented, but I think it is a reasonable expectation that no handlers (except for an error handler) is called on a dispatcher until a .connect or .listen has completed. It seems odd to have to implement .handle_write just to call .send just to trigger .handle_close which then must be implemented to call .close. Perhaps a flag could keep track of the "under construction" state (instead of assuming that it is either accepting, ready to connect, or connected).

I also notice that if .handle_read_event ever gets called on a closed (listen) socket then it will end up in .handle_connect_event which is very wrong.

Using python-2.6.2-4.fc12.i686, but it seems to be the same on release2.6-maint.

----------
components: Library (Lib)
messages: 99942
nosy: kiilerix
severity: normal
status: open
title: Fragile and unexpected error-handling in asyncore
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Feb 23 22:22:06 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Tue, 23 Feb 2010 21:22:06 +0000
Subject: [New-bugs-announce] [issue8004] add small server to serve docs
In-Reply-To: <1266960126.19.0.905943018148.issue8004@psf.upfronthosting.co.za>
Message-ID: <1266960126.19.0.905943018148.issue8004@psf.upfronthosting.co.za>


New submission from Dirkjan Ochtman <dirkjan at ochtman.nl>:

I'd like to put something like this in Doc, to make it easier to actually review the built documentation. (I guess we could put it in Tools, I'd just like it better if it was right there with the other stuff.)

Good idea? Thomas Wouters kind of liked it but said I should ask you.

from wsgiref.simple_server import make_server
import mimetypes, sys, os

CWD = os.path.dirname(os.path.abspath(__file__))
ROOT = os.path.join(CWD, 'build', 'html')

def app(environ, respond):

    fn = os.path.join(ROOT, environ['PATH_INFO'][1:])
    if '.' not in fn.split(os.path.sep)[-1]:
        fn = os.path.join(fn, 'index.html')
    type = mimetypes.guess_type(fn)[0]

    if os.path.exists(fn):
        respond('200 OK', [('Content-Type', type)])
        return [open(fn).read()]
    else:
        respond('404 Not Found', [('Content-Type', 'text/plain')])
        return ['not found']

if __name__ == '__main__':
    port = int(sys.argv[1]) if len(sys.argv) > 1 else 8000
    httpd = make_server('', port, app)
    httpd.serve_forever()

----------
assignee: djc
components: Demos and Tools, Documentation
keywords: patch
messages: 99953
nosy: benjamin.peterson, djc
priority: low
severity: normal
stage: patch review
status: open
title: add small server to serve docs
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Wed Feb 24 02:23:17 2010
From: report at bugs.python.org (Leo Shklovskii)
Date: Wed, 24 Feb 2010 01:23:17 +0000
Subject: [New-bugs-announce] [issue8007] conhost.exe crashes when pasting
	230 characters into	python
In-Reply-To: <1266974597.6.0.639203486875.issue8007@psf.upfronthosting.co.za>
Message-ID: <1266974597.6.0.639203486875.issue8007@psf.upfronthosting.co.za>


New submission from Leo Shklovskii <leos at thermopylae.net>:

I just upgraded to Windows 7, reinstalled all of my environment and am running into a completely crazy issue.

The repro is: cmd.exe -> python.exe -> Paste in a string more than 230 chars.

conhost.exe crashes and I get an error that ends up in the error log:
Log Name:      Application
Source:        Application Error
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
Description:
Faulting application name: conhost.exe, version: 6.1.7600.16385, time
stamp: 0x4a5bc271
Faulting module name: conhost.exe, version: 6.1.7600.16385, time
stamp: 0x4a5bc271
Exception code: 0xc0000005
Fault offset: 0x000048ca
Faulting process id: 0x1aa8
Faulting application start time: 0x01cab4e450b97766
Faulting application path: C:\Windows\system32\conhost.exe
Faulting module path: C:\Windows\system32\conhost.exe
Report Id: 9c6afd6c-20d7-11df-bbd8-e390d387a902 

I'd think its not python, however, I'm able to paste into the cmd.exe shell without any problem and into other apps running from the command line.

This is python 2.6.4, from the installer at python.org. Windows 7 32-bit.

Please let me know what other info I can provide and I'm happy to try out a debug build if needed.

----------
components: Windows
messages: 99985
nosy: brian.curtin, leos
severity: normal
status: open
title: conhost.exe crashes when pasting 230 characters into python
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Wed Feb 24 10:44:04 2010
From: report at bugs.python.org (=?utf-8?q?M=C3=A1rcio_Faustino?=)
Date: Wed, 24 Feb 2010 09:44:04 +0000
Subject: [New-bugs-announce] [issue8009] email.parser.Parser is inefficient
	with large strings
In-Reply-To: <1267004644.66.0.205268505464.issue8009@psf.upfronthosting.co.za>
Message-ID: <1267004644.66.0.205268505464.issue8009@psf.upfronthosting.co.za>


New submission from M?rcio Faustino <m.faustino at gmail.com>:

The email parser class is slow and memory intensive when dealing with sufficiently large strings.

For example, on a Windows 7 64-bit running at 1.60 GHz the attached test file gives the following results (number of seconds it took to parse a 10 MiB string):
Original: 76.6973627829
Modified: 0.231140741387

----------
components: Library (Lib)
files: test.py
messages: 100019
nosy: marcio
severity: normal
status: open
title: email.parser.Parser is inefficient with large strings
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file16355/test.py

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

From report at bugs.python.org  Wed Feb 24 10:52:05 2010
From: report at bugs.python.org (Patrick Holz)
Date: Wed, 24 Feb 2010 09:52:05 +0000
Subject: [New-bugs-announce] [issue8010] tkFileDialog.askopenfiles crashes
	on Windows 7
In-Reply-To: <1267005125.4.0.826921627128.issue8010@psf.upfronthosting.co.za>
Message-ID: <1267005125.4.0.826921627128.issue8010@psf.upfronthosting.co.za>


New submission from Patrick Holz <patrick.holz at googlemail.com>:

When using the function "tkFileDialog.askopenfiles()" on Windows 7 (32-bit) the following error occurs after choosing one or more arbitrary files:

Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import tkFileDialog
>>> tkFileDialog.askopenfiles()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python26\lib\lib-tk\tkFileDialog.py", line 163, in askopenfiles
    ofiles.append(open(filename, mode))
IOError: [Errno 2] No such file or directory: u'C'

So it seems that the colon after "C" (the drive letter) is wrongly used as a delimiter. The functions "askopenfile" (for a single file to choose) and "askopenfilenames" (to choose only the filenames instead of open the files immediately) don't seem to be affected, furthermore the error doesn't occur on Linux or WinXP.

----------
components: Tkinter
messages: 100020
nosy: Patrick.Holz
severity: normal
status: open
title: tkFileDialog.askopenfiles crashes on Windows 7
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Wed Feb 24 15:12:38 2010
From: report at bugs.python.org (Michael Newman)
Date: Wed, 24 Feb 2010 14:12:38 +0000
Subject: [New-bugs-announce] [issue8011] traceback tb_lineno example needs
	correction for Python3
In-Reply-To: <1267020758.71.0.873581563668.issue8011@psf.upfronthosting.co.za>
Message-ID: <1267020758.71.0.873581563668.issue8011@psf.upfronthosting.co.za>


New submission from Michael Newman <michael.b.newman at gmail.com>:

In the second example given in "27.8.1. Traceback Examples" at:
http://docs.python.org/3.1/library/traceback.html
http://docs.python.org/py3k/library/traceback.html
which has the lumberjack:

The last line won't work in Python 3.1 and 3.2:
 print("*** tb_lineno:", traceback.tb_lineno(exceptionTraceback))
because "tb_lineno" is no longer an attribute in the "traceback" module.

# Python 2.6 works fine (because Python2 retains the "tb_lineno" attribute in the "traceback" module):
# Python 2.6.4 (r264:75706, Dec  7 2009, 18:45:15) [GCC 4.4.1] on linux2
*** print_tb:
  File "print_traceback_and_exception.py", line 18, in <module>
    lumberjack()
...
*** format_tb:
['  File "print_traceback_and_exception.py", line 18, in <module>\n    lumberjack()\n', '  File "print_traceback_and_exception.py", line 12, in lumberjack\n    bright_side_of_death()\n', '  File "print_traceback_and_exception.py", line 15, in bright_side_of_death\n    return tuple()[0]\n']
('*** tb_lineno:', 18)

# Broken example using Python 3.1:
# Python 3.1.1 (r311:74480, Feb  7 2010, 16:32:28) [GCC 4.4.1] on linux2
mike at ebx2009:/media/Cruzer/notes/Programming/python3/lib/traceback$ python3.1 print_traceback_and_exception.py
*** print_tb:
  File "print_traceback_and_exception.py", line 18, in <module>
    lumberjack()
...
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "print_traceback_and_exception.py", line 38, in <module>
    print("*** tb_lineno:", traceback.tb_lineno(exceptionTraceback))
AttributeError: 'module' object has no attribute 'tb_lineno'

# Broken example using Python 3.2:
# Python 3.2a0 (py3k:78294, Feb 21 2010, 16:37:29) [GCC 4.4.1] on linux2
mike at ebx2009:/media/Cruzer/notes/Programming/python3/lib/traceback$ python3.2 print_traceback_and_exception.py 
*** print_tb:
  File "print_traceback_and_exception.py", line 18, in <module>
    lumberjack()
...
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "print_traceback_and_exception.py", line 38, in <module>
    print("*** tb_lineno:", traceback.tb_lineno(exceptionTraceback))
AttributeError: 'module' object has no attribute 'tb_lineno'

This can be corrected by changing the last line of the example from:
print("*** tb_lineno:", traceback.tb_lineno(exceptionTraceback))
to:
print("*** tb_lineno:", exceptionTraceback.tb_lineno)

# Using my "rev1" example:

# Python 3.1 now sees the brighter side of life:
mike at ebx2009:/media/Cruzer/notes/Programming/python3/lib/traceback$ python3.1 print_traceback_and_exception_rev1.py 
*** print_tb:
  File "print_traceback_and_exception_rev1.py", line 19, in <module>
    lumberjack()
...
*** format_tb:
['  File "print_traceback_and_exception_rev1.py", line 19, in <module>\n    lumberjack()\n', '  File "print_traceback_and_exception_rev1.py", line 13, in lumberjack\n    bright_side_of_death()\n', '  File "print_traceback_and_exception_rev1.py", line 16, in bright_side_of_death\n    return tuple()[0]\n']
*** tb_lineno: 19

For reference:
"print_traceback_and_exception_rev1.py" = example corrected with Python3. The original line has been commented out in case you want to turn it back on and see the error yourself.

----------
assignee: georg.brandl
components: Documentation
files: print_traceback_and_exception_rev1.py
messages: 100033
nosy: georg.brandl, mnewman
severity: normal
status: open
title: traceback tb_lineno example needs correction for Python3
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16357/print_traceback_and_exception_rev1.py

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

From report at bugs.python.org  Wed Feb 24 18:18:21 2010
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Wed, 24 Feb 2010 17:18:21 +0000
Subject: [New-bugs-announce] [issue8014] Setting a T_INT attribute raises
	internal error
In-Reply-To: <1267031901.2.0.324094054626.issue8014@psf.upfronthosting.co.za>
Message-ID: <1267031901.2.0.324094054626.issue8014@psf.upfronthosting.co.za>


New submission from Walter D?rwald <walter at livinglogic.de>:

In the current py3k branch setting an attribute of an object with PyMemberDefs raises an internal error:

$ ./python.exe
Python 3.2a0 (py3k:78419M, Feb 24 2010, 17:56:06) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> x = UnicodeEncodeError('ascii', 'gurk', 0, 4, 'broken')
[37539 refs]
>>> x.start = None
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Objects/longobject.c:439: bad argument to internal function

In Python 2.6.4 (and in the current trunk version) this raises a proper TypeError:

$ python 
Python 2.6.4 (r264:75706, Oct 27 2009, 15:18:04) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> x = UnicodeEncodeError('ascii', u'gurk', 0, 4, 'broken')
>>> x.start = None
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: an integer is required

----------
messages: 100051
nosy: doerwalter
severity: normal
status: open
title: Setting a T_INT attribute raises internal error
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Feb 24 18:53:24 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Wed, 24 Feb 2010 17:53:24 +0000
Subject: [New-bugs-announce] [issue8015] pdb "commands" command throws you
	into postmortem if you	enter an empty command
In-Reply-To: <1267034004.05.0.0859913514816.issue8015@psf.upfronthosting.co.za>
Message-ID: <1267034004.05.0.0859913514816.issue8015@psf.upfronthosting.co.za>


New submission from Ilya Sandler <ilya.sandler at gmail.com>:

Here is a sample session:

 cheetah:~/comp/python/trunk>  ./python ./Lib/pdb.py hello
 > /home/ilya/comp/python/trunk/hello(1)<module>()
 -> print i
 (Pdb) b 1
 Breakpoint 1 at /home/ilya/comp/python/trunk/hello:1
 (Pdb) commands 1
 (com) 
 Traceback (most recent call last):
    self.cmdloop()
  File "/home/ilya/comp/python/trunk/Lib/cmd.py", line 142, in cmdloop
    stop = self.onecmd(line)
  File "/home/ilya/comp/python/trunk/Lib/pdb.py", line 273, in onecmd
    return cmd.Cmd.onecmd(self, line)
  File "/home/ilya/comp/python/trunk/Lib/cmd.py", line 219, in onecmd
    return func(arg)
  File "/home/ilya/comp/python/trunk/Lib/pdb.py", line 330, in    do_commands
    self.cmdloop()
  File "/home/ilya/comp/python/trunk/Lib/cmd.py", line 142, in cmdloop
    stop = self.onecm  File "/home/ilya/comp/python/trunk/Lib/bdb.py", line 66, in  dispatch_line
    self.user_line(frame)
  File "/home/ilya/comp/python/trunk/Lib/pdb.py", line 158, in user_line
    self.interaction(frame, None)
  File "/home/ilya/comp/python/trunk/Lib/pdb.py", line 206, in interaction
d(line)
  File "/home/ilya/comp/python/trunk/Lib/pdb.py", line 275, in onecmd
    return self.handle_command_def(line)
  File "/home/ilya/comp/python/trunk/Lib/pdb.py", line 293, in handle_command_def
    func = getattr(self, 'do_' + cmd)
 TypeError: cannot concatenate 'str' and 'NoneType' objects
 Uncaught exception. Entering post mortem debugging
 Running 'cont' or 'step' will restart the program
 > /home/ilya/comp/python/trunk/Lib/pdb.py(293)handle_command_def()
 -> func = getattr(self, 'do_' + cmd)

----------
messages: 100057
nosy: isandler
severity: normal
status: open
title: pdb "commands" command throws you into postmortem if you enter an empty command
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb 25 06:11:41 2010
From: report at bugs.python.org (DavidCzech)
Date: Thu, 25 Feb 2010 05:11:41 +0000
Subject: [New-bugs-announce] [issue8017] c_char_p.value does not return a
	bytes object in Windows.
In-Reply-To: <1267074701.8.0.562765238894.issue8017@psf.upfronthosting.co.za>
Message-ID: <1267074701.8.0.562765238894.issue8017@psf.upfronthosting.co.za>


New submission from DavidCzech <davidczech510 at gmail.com>:

c_char_p.value doesn't return a bytes object on Windows.
http://docs.python.org/3.1/library/ctypes.html#fundamental-data-types states that c_char_p is either a "bytes object or None" in Python, not str.
----------
test_c_bug.py
----------
import ctypes

test_string = ctypes.c_char_p("This Is a test string, that should be of type bytes")

print (test_string.value)
print ("Typeof test_string {}",type(test_string))
print ("Typeof test_string {}",type(test_string.value))

assert(type(test_string.value) == bytes)

-----------------
Windows Xp 5.1 SP3
Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)] on win32
-----------------
C:\>python test_c_bug.py
This Is a test string, that should be of type bytes
Typeof test_string {} <class 'ctypes.c_char_p'>
Typeof test_string {} <class 'str'>
Traceback (most recent call last):
  File "test_c_bug.py", line 9, in <module>
    assert(type(test_string.value) == bytes)
AssertionError

-----------------
Ubuntu 9.10 Karmic 
Python 3.1.1+ (r311:74480, Nov  2 2009, 14:49:22) 
[GCC 4.4.1] on linux2
-----------------
david at Waldorf:~/dev/gtype/gtypes$ python3 test_c_bug.py
b'This Is a test string, that should be of type bytes'
Typeof test_string {} <class 'ctypes.c_char_p'>
Typeof test_string {} <class 'bytes'>

----------
assignee: theller
components: ctypes
files: test_c_bug.py
messages: 100084
nosy: DavidCzech, theller
severity: normal
status: open
title: c_char_p.value does not return a bytes object in Windows.
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file16368/test_c_bug.py

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

From report at bugs.python.org  Thu Feb 25 19:22:30 2010
From: report at bugs.python.org (Nick)
Date: Thu, 25 Feb 2010 18:22:30 +0000
Subject: [New-bugs-announce] [issue8019] struct.unpack() expects wrong
	number of bytes
In-Reply-To: <1267122150.44.0.78777888297.issue8019@psf.upfronthosting.co.za>
Message-ID: <1267122150.44.0.78777888297.issue8019@psf.upfronthosting.co.za>


New submission from Nick <niki at codingrobot.com>:

the code I'm trying to execute (block is long enough):
unpack("2IB2I", block)

executing this raises an exception:
struct.error: unpack requires a bytes argument of length 20

Setting native byte-order with '@' causes the same error.
Specifying the correct byte-order either with '>' or '<', or
native with '=' helps and unpack expects the correct number (17) of bytes.

----------
components: Library (Lib)
messages: 100096
nosy: codingrobot
severity: normal
status: open
title: struct.unpack() expects wrong number of bytes
type: behavior
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Thu Feb 25 22:34:22 2010
From: report at bugs.python.org (Matt Bandy)
Date: Thu, 25 Feb 2010 21:34:22 +0000
Subject: [New-bugs-announce] [issue8020] Crash in Py_ADDRESS_IN_RANGE macro
In-Reply-To: <1267133662.17.0.467128574772.issue8020@psf.upfronthosting.co.za>
Message-ID: <1267133662.17.0.467128574772.issue8020@psf.upfronthosting.co.za>


New submission from Matt Bandy <matt.bandy at thq.com>:

Using the Py_ADDRESS_IN_RANGE macro can result in a crash under certain threading conditions.  Since it is intentionally possible for (POOL)->arenaindex to reference memory which is not under Python's control, another thread may modify that memory.  In particular, the following sequence of operations is possible and leads to a crash:

1. A thread running Python code enters the Py_ADDRESS_IN_RANGE macro to test a pointer value which was allocated by the system allocator, not the pool-based allocator.
2. That thread intentionally reads a value (POOL)->arenaindex from memory which was not allocated by the Python interpreter.
3. The value (POOL)->arenaindex is tested and is less than maxarenas.
4. An unrelated thread which actually allocated the memory Py_ADDRESS_IN_RANGE is in the middle of looking at modifies the value referenced by (POOL)->arenaindex, changing it to a different value which is larger than maxarenas.
5. The original thread running Python code subscripts arenas with the new value and reads memory past the end of the arenas array, leading to unpredictable behavior or an access violation.

It's possible to fix this problem by changing Py_ADDRESS_IN_RANGE to a function so that it reads (POOL)->arenaindex only once, but the adjacent comment suggests that it's important for performance that it be a macro.

I observed this crash on Windows Vista x64 using an embedded Python 2.6.4 interpreter, although the same code appears to exist in later versions of Python as well.

----------
components: Interpreter Core
messages: 100106
nosy: mbandy
severity: normal
status: open
title: Crash in Py_ADDRESS_IN_RANGE macro
versions: Python 2.6

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

From report at bugs.python.org  Thu Feb 25 23:47:39 2010
From: report at bugs.python.org (David Schere)
Date: Thu, 25 Feb 2010 22:47:39 +0000
Subject: [New-bugs-announce] [issue8021] sys.exit() doesn't execute inside a
	signal handler while	blocked inside an try/except
In-Reply-To: <1267138059.01.0.423520771533.issue8021@psf.upfronthosting.co.za>
Message-ID: <1267138059.01.0.423520771533.issue8021@psf.upfronthosting.co.za>


New submission from David Schere <dschere at arinc.com>:

When doing an exit() within a signal handler for an alarm I am seeing something strange:


This code works, it exits within signal handler as expected. You never see the print statement executed.
import signal
import time
import sys
import traceback

def handler( *args ):
   sys.exit(-1) #<-- terminate program


signal.signal( signal.SIGALRM, handler ) 
# set alarm to go off in one second that calls handler()
signal.alarm( 1 )


time.sleep( 3 )


print 'You should never see this message'


This code results in sys.exit() begin ignored and the code inside the ?except:? block being executed!

import signal
import time
import sys
import traceback

def handler( *args ):
   sys.exit(-1) #<-- terminate program


signal.signal( signal.SIGALRM, handler ) 
# set alarm to go off in one second that calls handler()
signal.alarm( 1 )

try:
   time.sleep( 3 )
except:
   print 'This message should not be seen'
   sys.exit()
   
print 'You should never see this message'


The work around is to raise an exception inside the 
handler() function.

----------
messages: 100120
nosy: david_schere
severity: normal
status: open
title: sys.exit() doesn't execute inside a signal handler while blocked inside an try/except
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Fri Feb 26 03:17:54 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 26 Feb 2010 02:17:54 +0000
Subject: [New-bugs-announce] [issue8022] Leak when creating certain classes
	that subclass ABCs
In-Reply-To: <1267150674.85.0.640094833766.issue8022@psf.upfronthosting.co.za>
Message-ID: <1267150674.85.0.640094833766.issue8022@psf.upfronthosting.co.za>


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

Attached is a minimal example.  It has a function called leak().  The end of the script calls that function, runs the garbage collector, and prints out the number of objects in the system.  In Python 2.6, the number of objects increases after each iteration of the loop.  In Python 3.1, the number of objects remains fixed after the second iteration.  I don't have a Python 2.7 branch handy to test.

The problem could lie in the C code or perhaps ABCMeta is keeping a reference?  I'm not sure.

Cashew:~$ python2.6 leak.py
4842
4850
4858
4866
4874
4882
4890
4898
4906
4914

Cashew:~$ python3.1 leak.py
4286
4273
4273
4273
4273
4273
4273
4273
4273
4273

----------
components: Interpreter Core, Library (Lib)
files: leak.py
messages: 100132
nosy: stutzbach
severity: normal
status: open
title: Leak when creating certain classes that subclass ABCs
type: resource usage
versions: Python 2.6
Added file: http://bugs.python.org/file16374/leak.py

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

From report at bugs.python.org  Fri Feb 26 09:55:32 2010
From: report at bugs.python.org (ughacks)
Date: Fri, 26 Feb 2010 08:55:32 +0000
Subject: [New-bugs-announce] [issue8023] bug in s.append(x)
In-Reply-To: <1267174532.93.0.564850423841.issue8023@psf.upfronthosting.co.za>
Message-ID: <1267174532.93.0.564850423841.issue8023@psf.upfronthosting.co.za>


New submission from ughacks <ughacks at yahoo.com>:

Dear,

I am using
$ python -V
Python 2.6.4
on Ubuntu 9.10

I met a serious bug in s.append(x) operation. If I append a list into another list, there is a change of content. In the following code, [2,-2,0,0] is replaced with [-2,-2,0,0] after s.append(x) operaton.

------- begin of code ------

total=[]
for i in range(4):
    for j in range(i):
        root=[0,0,0,0]
        for k in [2,-2]:
         for l in [2,-2]:
          root[i]=k
          root[j]=l
          total.append(root)
          print root
print total

--------------- end of code -----

Result: each element is correctly generated
[2, 2, 0, 0]
[-2, 2, 0, 0]
[2, -2, 0, 0]
[-2, -2, 0, 0]
[2, 0, 2, 0]
[-2, 0, 2, 0]
[2, 0, -2, 0]
[-2, 0, -2, 0]
[0, 2, 2, 0]
[0, -2, 2, 0]
[0, 2, -2, 0]
[0, -2, -2, 0]
[2, 0, 0, 2]
[-2, 0, 0, 2]
[2, 0, 0, -2]
[-2, 0, 0, -2]
[0, 2, 0, 2]
[0, -2, 0, 2]
[0, 2, 0, -2]
[0, -2, 0, -2]
[0, 0, 2, 2]
[0, 0, -2, 2]
[0, 0, 2, -2]
[0, 0, -2, -2]

But the total list is wrong
[[-2, -2, 0, 0], [-2, -2, 0, 0], [-2, -2, 0, 0], [-2, -2, 0, 0], [-2, 0, -2, 0], [-2, 0, -2, 0], [-2, 0, -2, 0], [-2, 0, -2, 0], [0, -2, -2, 0], [0, -2, -2, 0], [0, -2, -2, 0], [0, -2, -2, 0], [-2, 0, 0, -2], [-2, 0, 0, -2], [-2, 0, 0, -2], [-2, 0, 0, -2], [0, -2, 0, -2], [0, -2, 0, -2], [0, -2, 0, -2], [0, -2, 0, -2], [0, 0, -2, -2], [0, 0, -2, -2], [0, 0, -2, -2], [0, 0, -2, -2]]

----------
messages: 100141
nosy: ughacks
severity: normal
status: open
title: bug in s.append(x)
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Fri Feb 26 17:11:56 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 26 Feb 2010 16:11:56 +0000
Subject: [New-bugs-announce] [issue8025] TypeError: string argument expected,
	got 'str'
In-Reply-To: <1267200716.31.0.22497398995.issue8025@psf.upfronthosting.co.za>
Message-ID: <1267200716.31.0.22497398995.issue8025@psf.upfronthosting.co.za>


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

>>> import io; fake = io.StringIO(); fake.write('boo')

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: string argument expected, got 'str'

----------
components: Library (Lib)
messages: 100156
nosy: flox, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: TypeError: string argument expected, got 'str'
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Feb 27 16:24:03 2010
From: report at bugs.python.org (Alexander Sulfrian)
Date: Sat, 27 Feb 2010 15:24:03 +0000
Subject: [New-bugs-announce] [issue8027] distutils fail to determine c++
	linker with unixcompiler	if using ccache
In-Reply-To: <1267284243.46.0.756608052144.issue8027@psf.upfronthosting.co.za>
Message-ID: <1267284243.46.0.756608052144.issue8027@psf.upfronthosting.co.za>


New submission from Alexander Sulfrian <alexander at sulfrian.net>:

Hi,
if using ccache (CC="ccache gcc --flags", CXX="g++") distutils will try to execute something like "g++ gcc --flags" as linker for c++ libraries.

Patch attached.


Alex

----------
assignee: tarek
components: Distutils
files: fix-distutils-with-ccache.patch
keywords: patch
messages: 100186
nosy: Alexander.Sulfrian, tarek
severity: normal
status: open
title: distutils fail to determine c++ linker with unixcompiler if using ccache
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file16388/fix-distutils-with-ccache.patch

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

From report at bugs.python.org  Sat Feb 27 20:58:33 2010
From: report at bugs.python.org (5houston)
Date: Sat, 27 Feb 2010 19:58:33 +0000
Subject: [New-bugs-announce] [issue8028] self.terminate() from a
	multiprocessing.Process raises	AttributeError exception
In-Reply-To: <1267300713.42.0.457825051385.issue8028@psf.upfronthosting.co.za>
Message-ID: <1267300713.42.0.457825051385.issue8028@psf.upfronthosting.co.za>


New submission from 5houston <cadabras at gmail.com>:

Try to execute "python -OO crashingMain.py" using python 3.1 or 3.1.1.

It creates and starts 5 SendingProcess(es).
SendingProcess inherits from multiprocessing.Process and multiprocessing.queue.Queue.

Each process starts a loop.

In the meanwhile the main, calling close() method of each SendingProcess, puts 1 into each SendingProcess and each SendingProcess, when it self.get(s) it, calls self.terminate.

This causes a AttributeError exception for each SendingProcess.

workingMain.py instead does not call close() method.
It calls directly the terminate method of each SendingProcess.

----------
files: pythonProcBug.tar.bz2
messages: 100191
nosy: 5houston
severity: normal
status: open
title: self.terminate() from a multiprocessing.Process raises AttributeError exception
versions: Python 3.1
Added file: http://bugs.python.org/file16390/pythonProcBug.tar.bz2

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

From report at bugs.python.org  Sun Feb 28 00:08:43 2010
From: report at bugs.python.org (Trent Mick)
Date: Sat, 27 Feb 2010 23:08:43 +0000
Subject: [New-bugs-announce] [issue8029] bug in 2to3 dealing with "print FOO,
	" followed by "sys.stdout.write('')"
In-Reply-To: <1267312123.13.0.138693680363.issue8029@psf.upfronthosting.co.za>
Message-ID: <1267312123.13.0.138693680363.issue8029@psf.upfronthosting.co.za>


New submission from Trent Mick <trentm at gmail.com>:

According to http://docs.python.org/reference/simple_stmts.html#the-print-statement the following with result in the print statement NOT printing a trailing space:

    import sys
    print u"ASD",; sys.stdout.write(u"")

However, 2to3 currently translates this to:

    import sys
    print("ASD", end=' '); sys.stdout.write("")

It *should* translate to:

    import sys
    print("ASD", end='')

You can also see the discussion of this on this lib3to2 bug report:
  http://bitbucket.org/amentajo/lib3to2/issue/13/print-3-end-isnt-translated-properly
and translation of this between 2to3 and 3to2 here:
  http://pythontranslationparty.appspot.com/6004/

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 100194
nosy: trentm
severity: normal
status: open
title: bug in 2to3 dealing with "print FOO," followed by "sys.stdout.write('')"

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

From report at bugs.python.org  Sun Feb 28 18:59:30 2010
From: report at bugs.python.org (Christopher the Magnificent)
Date: Sun, 28 Feb 2010 17:59:30 +0000
Subject: [New-bugs-announce] [issue8030] documentation bugs and improvements
In-Reply-To: <1267379970.2.0.344347508517.issue8030@psf.upfronthosting.co.za>
Message-ID: <1267379970.2.0.344347508517.issue8030@psf.upfronthosting.co.za>


New submission from Christopher the Magnificent <ultimate.mac.fanatic at gmail.com>:

Help for list looks like this:

    >>> help(list)
    class list(object)
     |  list() -> new list
     |  list(sequence) -> new list initialized from sequence's items
     |  
     ....

Help for dict looks like this:

    >>> help(dict)
    class dict(object)
     |  dict() -> new empty dictionary.
     |  dict(mapping) -> new dictionary initialized from a mapping object's
     |      (key, value) pairs.
     |  dict(seq) -> new dictionary initialized as if via:
     |      d = {}
     |      for k, v in seq:
     |          d[k] = v
     |  dict(**kwargs) -> new dictionary initialized with the name=value pairs
     |      in the keyword argument list.  For example:  dict(one=1, two=2)
     |  
     ....

As suggested by the documentation above -- and proven by verification:

    >>> a = [1, 2, 3]        # a new list
    >>> b = list(a)
    >>> a is a
    True
    >>> a == b
    True
    >>> a is b
    False
    >>> a is list(a)
    False
    
    >>> a = {'do': 1, 'rey': 2, 'mi': 3}    # a new dict
    >>> b = dict(a)
    >>> a is a
    True
    >>> a == b
    True
    >>> a is b
    False
    >>> a is dict(a)
    False

-- we can clearly see that list(x) and dict(x) ALWAYS return a new, unique object.


What about set?  
    
    >>> help(set)
    class set(object)
     |  set(iterable) --> set object
     |  
     |  Build an unordered collection of unique elements.
     |  
     ....


help(set) simply reports that set(x) returns a set object.  For all we know, this could mean creating a new object only if coercion is necessary; that sounds plausible enough, and people could easily write code dependent on that assumption that would introduce VERY subtle bugs!

Experimentation shows however that, like list and dict, set always returns a new, unique object:

    >>> a = {1, 2, 3}
    >>> b = set(a)
    >>> a is a
    True
    >>> a == b
    True
    >>> a is b
    False
    >>> a is set(a)
    False

Yipes!  CONFUSION!!!  


How about we fix the documentation for set so that it matches that of list and dict, including disclosure of its always-create-new-object behavior?  We can also make the "returns" arrow have one hyphen instead of two for consistency with most other Python documentation.

Let's replace this line:
X   set(iterable) --> set object

with this line:
?   set(iterable) -> new set object
   
so that our help(set) documentation ends up looking like this:

    class set(object)
     |  set(iterable) -> new set object
     |  
     |  Build an unordered collection of unique elements.
     |  
     ....


While we're at it, I'd recommend changing the help for list and dict so that instead of saying "list(sequence)", "dict(seq)", and "for k, v in seq:" -- which, besides being inconsistent in use of abbreviation, also use the older paradigm of sequences instead of iterables -- we instead say "list(iterable)", "dict(iterable)", and "for k, v in iterable:", giving us (X's by altered lines):

    >>> help(list)
    class list(object)
     |  list() -> new list
X    |  list(iterable) -> new list initialized from sequence's items
     |  
     ....

    >>> help(dict)
    class dict(object)
     |  dict() -> new empty dictionary.
     |  dict(mapping) -> new dictionary initialized from a mapping object's
     |      (key, value) pairs.
X    |  dict(iterable) -> new dictionary initialized as if via:
     |      d = {}
X    |      for k, v in iterable:
     |          d[k] = v
     |  dict(**kwargs) -> new dictionary initialized with the name=value pairs
     |      in the keyword argument list.  For example:  dict(one=1, two=2)
     |  
     ....

Making these changes from "seq"/"sequence" to "iterable" will serve to eliminate confusion as to whether set objects are usable in list and dict constructors -- for example, like this:

    >>> x = {('spam', 'icky'), 
    ...      ('balony', 'stomachable'), 
    ...      ('beef', 'palatable'),
    ...      ('turkey', 'yummy')}
    >>> dict(x)
    {'turkey': 'yummy', 'balony': 'stomachable', 'beef': 'palatable', 'spam': 'icky'}

Python's clear and helpful online documentation is one of my most favorite features of the language, and I'm  not alone in feeling this way, so we should make it the very best resource that we can!  Python rules!!

----------
assignee: georg.brandl
components: Documentation
messages: 100212
nosy: christopherthemagnificent, georg.brandl
severity: normal
status: open
title: documentation bugs and improvements
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/issue8030>
_______________________________________

From report at bugs.python.org  Sun Feb 28 23:45:29 2010
From: report at bugs.python.org (Peter Jones)
Date: Sun, 28 Feb 2010 22:45:29 +0000
Subject: [New-bugs-announce] [issue8031] Can't get f2py to work at all
In-Reply-To: <6337AF39BB9A472E8B2BF0D67D46AFE2@XPS630>
Message-ID: <6337AF39BB9A472E8B2BF0D67D46AFE2@XPS630>


New submission from Peter Jones <pjones0 at hughes.net>:

I am user 11943. OS is Windows Vista Ultimate. I have followed the instructions on how to use f2py and get this error when I try it (is this a known bug? It appears that there is bug in f2py):

C:\Python26\Scripts>python f2py.py
Traceback (most recent call last):
  File "f2py.py", line 3, in <module>
    import f2py2e
  File "C:\Python26\lib\site-packages\f2py2e\__init__.py", line 10, in <module>
    import f2py2e
  File "C:\Python26\lib\site-packages\f2py2e\f2py2e.py", line 26, in <module>
    import crackfortran
  File "C:\Python26\lib\site-packages\f2py2e\crackfortran.py", line 1586
    as=b['args']
     ^
SyntaxError: invalid syntax

I have also tried the example to create a fortran module for python and get this error:

C:\Python26\Scripts>python f2py.py -c --fcompiler=gnu95 --compiler=mingw32 -lmsvcr71 -m cep cep.for

Traceback (most recent call last):
  File "f2py.py", line 3, in <module>
    import f2py2e
  File "C:\Python26\lib\site-packages\f2py2e\__init__.py", line 10, in <module>
    import f2py2e
  File "C:\Python26\lib\site-packages\f2py2e\f2py2e.py", line 26, in <module>
    import crackfortran
  File "C:\Python26\lib\site-packages\f2py2e\crackfortran.py", line 1586
    as=b['args']
     ^
SyntaxError: invalid syntax

Additionally I use the Lahey/Fujitsu 95 compiler. Do I just replace the gnu95 with lahey? 
Also Is the msvrc71.dll file the correct one to use? I use MSVC VS 2009, which uses msvc90.dll. Should I use it instead?

----------
files: unnamed
messages: 100225
nosy: PeterJones
severity: normal
status: open
title: Can't get f2py to work at all
Added file: http://bugs.python.org/file16402/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8031>
_______________________________________
-------------- next part --------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.18882">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2 face=Arial>I am user 11943.&nbsp;OS is Windows Vista 
Ultimate.&nbsp;I have followed the instructions on how to use f2py and get this 
error when I try it (is this a known bug? It appears that there is bug in 
f2py):</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT>&nbsp;</DIV>
<DIV><FONT size=2 face=Arial>C:\Python26\Scripts&gt;python f2py.py<BR>Traceback 
(most recent call last):<BR>&nbsp; File "f2py.py", line 3, in 
&lt;module&gt;<BR>&nbsp;&nbsp;&nbsp; import f2py2e<BR>&nbsp; File 
"C:\Python26\lib\site-packages\f2py2e\__init__.py", line 10, in 
&lt;module&gt;<BR>&nbsp;&nbsp;&nbsp; import f2py2e<BR>&nbsp; File 
"C:\Python26\lib\site-packages\f2py2e\f2py2e.py", line 26, in 
&lt;module&gt;<BR>&nbsp;&nbsp;&nbsp; import crackfortran<BR>&nbsp; File 
"C:\Python26\lib\site-packages\f2py2e\crackfortran.py", line 
1586<BR>&nbsp;&nbsp;&nbsp; as=b['args']<BR>&nbsp;&nbsp;&nbsp;&nbsp; 
^<BR>SyntaxError: invalid syntax</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT>&nbsp;</DIV>
<DIV><FONT size=2 face=Arial></FONT>&nbsp;</DIV>
<DIV><FONT size=2 face=Arial></FONT>&nbsp;</DIV>
<DIV><FONT size=2 face=Arial>I have also tried the example to create a fortran 
module for python and get this error:</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT>&nbsp;</DIV>
<DIV><FONT size=2 face=Arial>C:\Python26\Scripts&gt;python f2py.py -c 
--fcompiler=gnu95 --compiler=mingw32 -lmsvcr71 -m cep cep.for</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT>&nbsp;</DIV>
<DIV><FONT size=2 face=Arial>Traceback (most recent call last):<BR>&nbsp; File 
"f2py.py", line 3, in &lt;module&gt;<BR>&nbsp;&nbsp;&nbsp; import 
f2py2e<BR>&nbsp; File "C:\Python26\lib\site-packages\f2py2e\__init__.py", line 
10, in &lt;module&gt;<BR>&nbsp;&nbsp;&nbsp; import f2py2e<BR>&nbsp; File 
"C:\Python26\lib\site-packages\f2py2e\f2py2e.py", line 26, in 
&lt;module&gt;<BR>&nbsp;&nbsp;&nbsp; import crackfortran<BR>&nbsp; File 
"C:\Python26\lib\site-packages\f2py2e\crackfortran.py", line 
1586<BR>&nbsp;&nbsp;&nbsp; as=b['args']<BR>&nbsp;&nbsp;&nbsp;&nbsp; 
^<BR>SyntaxError: invalid syntax</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT>&nbsp;</DIV>
<DIV><FONT size=2 face=Arial></FONT>&nbsp;</DIV>
<DIV><FONT size=2 face=Arial></FONT>&nbsp;</DIV>
<DIV><FONT size=2 face=Arial></FONT>&nbsp;</DIV>
<DIV><FONT size=2 face=Arial>Additionally I use the Lahey/Fujitsu 95 compiler. 
Do I just replace the gnu95 with lahey? </FONT></DIV>
<DIV><FONT size=2 face=Arial>Also Is the msvrc71.dll file the correct one to 
use? I use MSVC VS 2009, which uses msvc90.dll. Should I use it 
instead?</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT>&nbsp;</DIV></BODY></HTML>